[pulseaudio-discuss] module-device-restore: Volume save and restore for all ports?

[Tanu Kaskinen]

la, 2010-01-02 kello 14:40 +0000, Colin Guthrie kirjoitti:
> 'Twas brillig, and Tanu Kaskinen at 01/01/10 03:52 did gyre and gimble:
> > Hi Colin,
> > 
> > I got a bit confused about the term "port" in your mail. Apparently you
> > used it to mean something else than pulseaudio's own "device port"
> > concept. In this message I will use the word "port" only for the
> > pulseaudio concept.
> 
> It's certainly what I meant by "port"... /me worries that it wasn't clear.
> 
> > ke, 2009-12-30 kello 13:26 +0000, Colin Guthrie kirjoitti:
> >> As jack sensing will eventually be with us, it would make sense to save
> >> and restore the volume of all ports separately. Only saving the current
> >> port's volume would be a pain.
> > 
> > I agree, although I don't really see how jack sensing is important here.
> > AFAIK ports are currently only implemented by the alsa modules, and in
> > that case separate ports are created for two different purposes:
> > selecting the physical output or input, and selecting any options that
> > the alsa mixer offers (for example, extra amplification switch).
> > Regardless of jack sensing, volume should be saved and restored
> > independently for each output/input.
> 
> Well the reason I see jack sensing as important here is that the say the
> user is using the "Speaker" port and sets the volume to 99%. This volume
> is saved. Then later, they have headphones plugged in when PA starts and
> the "port" is automatically set to "Headphones". In this case the volume
> could be restored to the 99% that was appropriate for "Speaker" but
> totally incorrect for "Headphones" and turn your brain into a mushy goo :p

Ok, I think I see. So the difference is that when switching to
"Headphones", without jack sensing the user has the possibility
pre-emptively decrease the volume after plugging the headphones in. With
jack sensing the decreasing has to be done before plugging the
headphones in. That might not be a very big difference - I think "mushy
goo" is the probable outcome in both cases :)

> > Now the second purpose of ports causes problems: the volume shouldn't be
> > saved independently for the two cases of whether the extra amplification
> > is on or off.
> 
> Why not? With amplification you'd presumably set the volume lower... is
> it a massive problem that we would save those two volumes separately?

The option could be anything - the sound card might have selectable
equalization presets, for example... But no, I don't believe this would
be a massive problem in practice. Certainly just storing the volume
individually for each port would be a good start. But I still think that
the port option concept makes sense.

> > I may have not thought this completely through, but nevertheless I
> > propose the following:
> > 
> > - Track port volume and mute individually. That is, whenever the active
> > port is switched, the previous port's volume and mute state should be
> > saved to a database and the new port's volume and mute state should be
> > loaded from the database.
> 
> Ahh, I thought about that (didn't say it in the original mail) but there
> is a problem here. It's maybe too niche, but if we only save it on port
> switch then a volume change to "Headphones" levels via alsa mixers will
> not be saved. This will affect users who currently are able to take
> advantage of hardware jacksensing. e.g. The user I spoke to didn't
> actually change the PA port when he plugged his headphones in (it's too
> much hassle which I can sympathise with). When he does this, the general
> volume control infrastructure doesn't work (as expected) and changing
> volume doesn't actually affect the volume of the headphones.
> 
> So if we could detect and save the volume when it's changes, then the
> restoration would help this use case.
> 
> Of course if we could just get jack sensing working it would bypass the
> need for this, so it's likely a better focus.

Well, I fully agree that it does make sense to store the volume whenever
it changes (except for automatic changes by the flat volume logic) -
just like it's done now.

Regarding the use case you mentioned - it would require some
modifications to the logic that handles mixer change events that are
caused eg. by fiddling with alsamixer. Currently whenever something
happens, the sink receives a generic callback that basically says
"something happened" and then the sink just updates the current volume
and mute state, using the currently active port. This use case would
require that each port would store the current volume and mute of the
relevant mixer elements, and the mixer change events would be handled by
the ports instead of (or in addition to) the sinks. Device-restore would
need to listen to port state change events, which do not currently
exist.

As you say, the need for this will probably evaporate with jack sensing
support. It's still useful to think whether using alsamixer (or
something like it) should be supported as well as possible - it would be
nice if moving the "Headphones" slider would affect the device-restore
database even when the headphones aren't currently plugged in and the
active port is something else. But I don't think it's worth the effort
to implement that. The model that the user uses to interact with the
alsa volume elements often doesn't match the model that pulseaudio uses
(use one main slider, and keep other sliders mostly at 0db), so
pulseaudio would never be able to keep the settings exactly how the user
set them in alsamixer.

-- 
Tanu Kaskinen