Re: [RFC] virtual master control for HD-audio

[Takashi Iwai <tiwai@suse.de>]

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