[alsa-devel] [RFC] virtual master control (1/3)
maximlevitsky at gmail.com
Fri Nov 23 21:48:02 CET 2007
On Friday 23 November 2007 20:36:32 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.
Well, first big thanks for those patches.
Secondary I strongly disagree that the above can be implemented in userspace easily.
Sure you can have a program that adjusts the volume of all outputs, and creates a virtual
userspace control, but the change in volume of outputs will be visible to userspace.
For example moving the master volume will move the front/surround/LFE/.... sliders,
and it is no good.
What this patch does, it actually modifies the code for those 'slave' amps, so the master volume is
taken in account.
I will test it now on my system.
I hope this gets merged,
More information about the Alsa-devel