'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
Now the current code can restore the port along with the volume so this
is unlikely to happen, but certainly if I switch between Speaker and
Headphone ports automatically (with working jack sensing) and control
the two volumes independently, then I'd certainly like to have both
those two independent volumes saved and restored across reboots.
> 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?
> 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.
Sorry if the above makes no sense.... :p
> - Don't treat the options as separate ports, but create a new concept
> for them: port 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).
> - Port options are things that you can switch on and off, or choose from
> an enumeration.
> - Obviously "port options" are specific to ports. module-device-restore
> tracks the option states along with port volume and mute.
I'm not really sure it's needed. Like I said above I'm not really sure
it's a massive problem storing separate volumes for each of the ports as
defined currently. I can't really think of a use case where this is
problematic.
AFAICT the only change that is needed is to include the port name in the
key used for the module-device-restore database with a special key for
storing the currently "active" port. There will have to be some smarts
added when automatic port selection via jack sensing works so that
changes triggered when plugging in head phones are not actually saved as
the "active" port for restoration later when the headphones are not
plugged in but that should be easy enough to cope with - e.g. API based
port changes are saved, but automatic (i.e. from alsa) port changes are
not saved - much like how current stream moves are saved or not.
Col
Col
--
Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/
Day Job:
Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
Mandriva Linux Contributor [http://www.mandriva.com/]
PulseAudio Hacker [http://www.pulseaudio.org/]
Trac Hacker [http://trac.edgewall.org/]
