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

[David Henningsson]

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.

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?


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



-- 
David Henningsson, Canonical Ltd.
http://launchpad.net/~diwic