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

[Lennart Poettering]

On Fri, 01.01.10 05:52, Tanu Kaskinen (tanuk at iki.fi) wrote:

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

Makes sense.

An easy fix could be to reuse the current m-d-r database but always
store two entries each time we want to save the device settings: one
for $SINKNAME and one for $SINKNAME@$PORTNAME or suchlike. And when
reading from the database we'd first look for $SINKNAME@$PORTNAME in
the db and fall back to $SINKNAME if we dont find that.

> - Don't treat the options as separate ports, but create a new concept
> for them: port options.

Hmm, should those really be _port_ options? Not _device_ options?

> - Thereby a port equals a physical route ("port" might be renamed to
> "route", although I think "port" is a good enough name for the
> concept).

Kinda makes sense.

> - Port options are things that you can switch on and off, or choose from
> an enumeration.

This dangerously sounds like the complex ALSA mixer which I'd rather
avoid. Before we approach this, could we get a more complete list of
options that would be covered with this, in addition to the amplifier
settings?

> Lennart, any comments? Would you accept a patch that made these changes?

Yes, but let's discuss this more first ;-)

Lennart

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