[alsa-devel] [RFC] virtual master control (1/3)

[Takashi Iwai]

At Fri, 23 Nov 2007 19:36:32 +0100 (CET),
Jaroslav Kysela wrote:
> 
> On Fri, 23 Nov 2007, Takashi Iwai wrote:
> 
> > At Mon, 19 Nov 2007 12:13:28 +0100,
> > I wrote:
> > > 
> > > > > > If not, then it is better  to remove it/remame to VolumeKnob
> > > > >
> > > > > Agreed.  I'd like to take a safer way if you don't insist...
> > > > Great, it is probably the best to have a virtual master volume.
> > > > Just one question, it will be probably enabled for devices that don't have a 
> > > > master volume (or have it broken like the STAC), right?,
> > > > And when you expect it to be merged?
> > > 
> > > Hopefully will be posted in this week after a small brush up.
> > 
> > OK, here is a series of the patch I promised.
> > 
> > The first one is the patch to add virtual master controls.
> > 
> > ===
> > 
> > [PATCH] Add virtual master control
> > 
> > This patch adds the routines to create virtual master controls.
> > A virtual master control can have multiple slave controls that
> > are supposed to be identical type.  The master volume will add the
> > master attenuation and the master switch will add the master mute
> > switch.
> > 
> > ---
> 
> I'm really not sure if I like to see such extensions in kernel. We have 
> now user control elements and a small daemon written in C or python will 
> do exactly same job and will be more flexible.

I've thought that a user-space solution would be appropriate, too.
But, a requirement of a daemon is a very big disadvantage (I believe
many people would dislike).  A plugin-based solution is another idea,
but it's also complex and hard to implement consistently (because many
mixer apps open "hw" device as default).

What I suggested is the implementation of a quite trivial master
control.  Of course, it's not so flexible but it covers most of
hardwares.   So much flexibility isn't needed in reality.  The
convenience (for user and developer) is more important.


Takashi