[pulseaudio-discuss] RFC: Change the device-restore database to allow per-port volumes

Mon Aug 29 03:01:55 PDT 2011

'Twas brillig, and David Henningsson at 29/08/11 10:51 did gyre and gimble:
> On 08/29/2011 10:51 AM, Colin Guthrie wrote:
>> 'Twas brillig, and David Henningsson at 29/08/11 08:04 did gyre and
>> gimble:
>>> On 08/26/2011 03:05 PM, Colin Guthrie wrote:
>>>> 'Twas brillig, and Colin Guthrie at 25/08/11 17:17 did gyre and gimble:
>>>>> 'Twas brillig, and Arun Raghavan at 25/08/11 17:08 did gyre and
>>>>> gimble:
>>>>>> On Wed, 2011-08-24 at 22:58 +0100, Colin Guthrie wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> This is a patch set that will likely mostly interest David, but also
>>>>>>> solves one of the remaining niggles I have for 1.0 - the fact that
>>>>>>> volumes are not set properly on port changes.
>>>>>>>
>>>>>>> Now this only "solves" that niggle when the module-device-restore
>>>>>>> is used,
>>>>>>> but I'm happy enough to rely on that for now seeing as it's the
>>>>>>> default
>>>>>>> on 99.999% of desktop installs.
>>>>>>>
>>>>>>> The overall benefit of this patch is that it allows different
>>>>>>> volumes
>>>>>>> to be saved and restored for different ports. Combine this with
>>>>>>> David's
>>>>>>> work on making jack-detection work (which triggers port changes)
>>>>>>> and you
>>>>>>> automatically get different volumes on headphones vs. speakers.
>>>>>>
>>>>>> My main concern is the following scenario:
>>>>>>
>>>>>> 0. Say we start with built-in speaker and headphone port and equal
>>>>>> (maybe 70%) volume
>>>>>> 1. With headphones plugged in, I've got the volume turned up while
>>>>>> playing something that's naturally not very loud
>>>>>> 2. I pull out headphones, start playing something that's quite
>>>>>> loud, I
>>>>>> turn down the volume
>>>>>> 3. I put the headphones back, find the output too loud (since the
>>>>>> port
>>>>>> volume was turned up for the previous stream)
>>>>>>
>>>>>> While the current scenario isn't ideal, it's easy for users to wrap
>>>>>> their head around (different devices have different loudness
>>>>>> levels). If
>>>>>> we don't handle this sort of case in the per-port-volume case, IMO
>>>>>> the
>>>>>> behaviour is potentially confusing/frustrating to users.
>>>>>>
>>>>>> Maybe there's a simple way to handle this that I'm missing ...
>>>>>
>>>>> I'm not sure there is a way to handle this really. Either we want
>>>>> volumes per-port or we don't. IMO we do (this is how it works on my
>>>>> iPhone for example) and I think from the various mumblings I've heard
>>>>> over the years most people want this type of functionality.
>>>>>
>>>>> But perhaps there is indeed some magic solution that we are both
>>>>> missing :p
>>>>
>>>> Anyone else got any comments on this? I'd like to push it out if all is
>>>> well otherwise.
>>>>
>>>>
>>>> FWIW, to address Arun's concern somewhat, we could relatively easily
>>>> make a change here that kept the same volume for every port simply by
>>>> changing the key name used and then expose this as a module argument
>>>> should people really hate this behaviour.
>>>>
>>>> Any comments on the code would be appreciated too :)
>>>
>>> Well, I'm not that much into the database format, so can't really look
>>> for bugs there...I have a question though: What about loudness bumps? It
>>> looks like that could be the effect if you set the volume in such a
>>> reactive fashion?
>>
>> Well if you plug in a jack, you kinda expect the volume to change anyway
>> (it's a different physical thing outputting the sound.
>>
>> Not really sure what you're meaning by loudness bumps in this respect.
>> Sure it's possible that the user configures things such that things get
>> too loud when they unplug things, but I'm not convinced there is a way
>> around that while still supporting independent volumes for headphones
>> vs. speakers.
> 
> Assume we have a card with one ALSA kcontrol named "Master" that
> controls both headphone and speaker volume. User likes to have volume at
> -6 dB with headphones and -24 dB with speakers. When user unplugs
> headphones, he will have -6 dB in his speakers from the point when the
> kernel does the automute stuff until we have synced the volume, i e a
> "bump" in the volume. In that case, I'm not sure if there's anything we
> could do about it.

Ahh right of course.

Yeah until we have some info to go on, there is very little we can do to
mask this sadly.

At least in practice, I think headphones will be quieter than speakers
rather than the other way round (at least that's how I tend to use them!)

Incidentally, when you are adding your jack stuff, I think I'm right in
saying that you add fake ports to all alsa sinks to deal with
jack-plugged v.s jack-unplugged right?

At the moment I store the volume per-device with a special fake port
name of "null" but would it make more sense if I used the fake name
"jack-unplugged" (or whatever your fake profile name is) in preparation
for your patchs landing. That way users who have volumes saved won't get
them invalidated. Feel free to chat on IRC if this is unclear!

> But this also happens when you switch manually, in which case which
> *could* do something about it. My point is that a port switch
> essentially a change of ALSA kcontrols, and it seems like the proposed
> implementation would do the change in two steps, first in reaction to
> the port switch, then in reaction to module-device-restore. And there
> should be possible to do it in one step only and set the right volume at
> the same time as you set the port switch. Do you follow?

Ahh right, so some kind of notification that a port switch from a->b is
in progress and to react.

I guess the idea there would be to have a PORT_CHANGE_PRE hook and do
the necessary work, pushing the necessary values into the sink object's
volumes.

I think this is possible to make work (and would probably fix the
underlying problem more thoroughly too which is nice), but it's likely
something that will have to wait until after 1.0 (certainly if I'm going
to do it as I won't really have time).

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]