At Sat, 22 Dec 2007 15:55:19 +0100, I wrote: > > At Fri, 21 Dec 2007 20:37:09 +0100 (CET), > Jaroslav Kysela wrote: > > > > On Thu, 20 Dec 2007, Takashi Iwai wrote: > > > > > Hi, > > > > > > another thing I'd like to push into the next kernel is the virtual > > > master volume control. As I posted in earlier posts, it adds virtual > > > controls that have several slave controls with the same types, > > > e.g. Front, Surround, Center, LFE, etc. Then these are adjusted > > > simultaneously via the master control. > > > > > > It'd be appreciated if some one can test the patches with HD-audio h/w > > > that has no master control yet (e.g. some STAC codecs). > > > > > > Note that this won't add the master volumes if there are no real > > > volume controls. Some codecs have really no volume control, and this > > > won't help for such devices. > > > > > > Two (and one for driver) patches will follow after this. > > > > NAK from my side. I am convinced that this code can be implemented in the > > user space even without any daemon just in the mixer abstract layer using > > standard control elements and using eventually new user controls to store > > data for virtual mixer controls. > > A user-space implementation of virtual mixer elements would be far > more complicated than the simplistic kernel-space patch. I've > considered it many times, even tried to implement it, but got that > conclusion. You'll see obviously the following difficulties: > > 1. Many user-space virtual elements > > Each slave control element needs a virtual element (eventually a > user-space one) because we need to keep both raw and virtual values to > handle saturation. That is, the same number of additional controls > would be added. Significant for 7.1 outputs. > > 2. Easy incosistency between virtual and raw elements > > Even if the mixer abstraction hides the virtual elements, both > virtual and raw elements are exposed on control API. This can cause > the value-inconsistency between them quite easily, because many apps > access directly via control API (even some mixer apps), and they > likely change only raw values. The similar situation is for kernel > OSS emulation. > > 3. Complicated configuration > > The requirement of virtual master controls is very much dependent on > the hardware. In the case of HD-audio, it depends on codec chip > types, and even on the preset model chosen via PCI SSID or a module > option. Implementing such a complex conditional in alsa-lib > configuration is a clear overhead. > > 4. More resource requirement > > Clearly a user-space solution requires more layers in alsa-lib, which > is invoked by each process, and even more memory footprint than the > kernel solution, not only the additional complexity. > > > ... and think again what is the benifit of the user-space solution in > this case, in comparison with the demerits above. > > If you could implement the same feature on user-space with less amount > of codes, I'd happily take it. But, I'm sure it's very hard. The master control is really important feature. Unless you have really a better patch, I'd like to commit the vmaster patch soon, so that more people can test. thanks, Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
