[alsa-devel] [RFC] virtual master control for HD-audio
tiwai at suse.de
Wed Jan 9 18:06:56 CET 2008
At Sat, 22 Dec 2007 15:55:19 +0100,
> 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.
More information about the Alsa-devel