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

[John Utz]

On Sat, 24 Nov 2007 11:12:07 +0100
"Takashi Iwai" <tiwai at suse.de> wrote:

> 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:
> > > > 
> > > 
> > > 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.

could you flesh this out a teeny bit more? I am interested in this
alternative, but my experiences of the last year with also dont make me
feel super optimistic about it.


> 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.

I strongly favor this approach. I am interested in learning more about
Jaroslav's daemon idea, but at this time it would need to really
pleasantly surprise me for me to feel like it would be a better idea.

FWIW, i would be strongly opposed to making it a plugin.
While i am very impressed with the technology of the plugin
architecture, it's need to have all sound apps linked with alsalib for
it to work poses significant complexity for both developers and users.

just my $us 0.02;

johnu

> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>