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

[Colin Guthrie]

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

There could be some kind of heuristics applied  - e.g. if there are some
active streams, perhaps we should ramp up the volume to it's previous
value over a couple seconds giving some time for the user to hit the
volume down buttons. That said, I'm not convinced this would really help
(and we've not yet got nice volume ramping anyway!).

Other methods such as erring on the side of caution and keeping the
volume low, but giving the user an option to restore the previous volume
via some UI feedback. But I don't think the infrastructure is quite
there yet (nor am I convinced this is a good idea generally).

Other thoughts on the issue are welcome tho'.

> However - it might be that there is no true way around that anyway, as
> in the case of jack detection as we're only reactive to what the kernel
> does.

That's my gut feeling but I'd be happy to consider anything that makes
for a better user experience overall.

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/]