[pulseaudio-discuss] Stream volumes as the universal volume adjustment method

[Lennart Poettering]

On Fri, 15.01.10 07:34, Tanu Kaskinen (tanuk at iki.fi) wrote:

> 
> to, 2010-01-14 kello 23:08 +0100, Lennart Poettering kirjoitti:
> > On Thu, 07.01.10 18:30, Tanu Kaskinen (tanuk at iki.fi) wrote:
> > > The logic for ToggleMute:
> > > 
> > > - If all sinks are unmuted, mute all sinks.
> > > 
> > > - If all sinks are muted, unmute all sinks.
> > >
> > > - If only some sinks are muted, then
> > >   A) if there are no active streams, mute all sinks.
> > >   B) if there are active streams, of which at least some output to
> > > unmuted sinks, mute all sinks.
> > >   C) otherwise unmute all sinks.
> > 
[...]
> 
> Ok, maybe the proposed logic isn't perfect. Wouldn't it be a good idea
> to have module-dwim anyway, regardless of the actual logic? I guess
> currently the software that handles the hardware volume/mute events
> adjusts just the fallback sink (assumedly via the alsa plugin), which is
> quite stupid. Since there are probably multiple hardware event handler
> software implementations for different desktop environments, the logic
> should be in a central place, i.e. pulseaudio. The module could even
> start with the silly logic of just controlling the fallback sink, until
> someone comes up with something better.

Yes, currently g-v-c-a and g-s-d control the fallback device's
volume. 

I believe that we cannot really pull this into PA any further. When
XInput becomes available in gtk we will be able to figure out the
source of a keypress, i.e. whether it came from the bt headset keys or
from the usb hid keys on my usb speakers. If we have that information
then we can make sure that the keypresses are properly forwarded to
the right device, so that bt hid keypresses change the bt headset
volume while those usb hid keypresses actually change the usb speaker
volume. This matching logic belongs as much into PA as into g-s-d as
into X11. I'd probably leave it for g-s-d.

Of course some keypresses are not really attached to a specific audio
device. For those we could probably come up with something inside of
PA that picks the right device to change the volume of, if the user
has not selected a particular device in the UI to change the volume
of. Something like this:

0a) if the keypress comes from a particular input device that has a
    particular audio device attached to it change its volume and end

0b) if the user selected a particular device in the UI to change the
    volume of, use it and end

1)  determine the set of sinks which have a stream active. If the set
    is not empty pick the sink in the set with the highest priority
    value and change its volume and end.

2)  change the fallback sink's volume

I think this is the best alg we could come up. I don't think adjusting
more than one sink at once makes sense (for the reasons pointed out in
my earlier mail). Of course, this alg is not perfect either, but it's
as good as it gets i think.

0a and 0b should be implemented in g-s-d I think. Also 2 currently is
too. we could implement 1 and 2 in a nice module I think. but it is
not that easy because there needs to be a nice two way protocol so
that for the OSD UI it is easy to figure out what volume is currently
picked.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4