[pulseaudio-discuss] Standardising on the amount of software amplification is presented to the user

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 13/04/10 22:04 did gyre and gimble:
> On Tue, 13.04.10 15:10, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> 
>> Hi,
>>
>> I'm trying to solve a bug where by mplayer is clamping the volume at
>> 100%. If someone turns up the volume to >100% using e.g.
>> gnome-volume-control, hitting volume up or down in mplayer will reset it
>> to 100% again.
>>
>> For a quick straw poll:
>>
>>  g-v-c: 150%
> 
> Unfortunately g-v-c-a limits to 100%. Which is kinda weird.
> 
>>  pavucontrol: 100%
>>  kmix & phonon: 100% (I wrote this so only me to blame!)
>>
>>  vlc: 400% (but does not yet use PA per-application volume control).
>>  mplayer: 100%
>>
>> + numerous others.
> 
> Well, and for all of those the meaning of 150% probably differs. And it
> probably makes more sense to speak about dB here.
> 
>> Now I believe we need some kind of standard amount of overdrive.
>> Obviously we want to push the applications into using per-stream
>> volumes, but this only really works if they all use the same range.
>>
>> What is the best way to do this? Should we just decide on it now and
>> then push this out to the apps? Should we have a constant? e.g.
>> PA_VOLUME_OVERDRIVE == +3dB or something?
> 
> Hmm, this is purely a UI decision, not sure this belongs in PA. And
> also, this all depends on whether the device does decibel volume scaling
> at all. If it doesn't you need to end things at 100%.
> 
>> In VLC the 400% relates to a +6dB overdrive so a +3dB for them is 200%
>> (and one of their devs said to me that he didn't think that anything
>> over +3dB should be shown to the user). Perhaps even this is too far?
> 
> In PA +6dB is at 125% or so (with the current mapping algorithm).

Ahh good. I figured it wouldn't be 400% in PA, but hadn't done the
actual sums :)

> We currently use the same cubic mapping both below and above 100%. I am
> not sure that is even a good choice, and if we shouldn't change that one
> of those days.

>From what I've discussed with the VLC guys this morning (and I wont
pretend to fully grok all the mappings involved) they seem to suggest a
+3dB = 200% and a +6dB = 400%. This seems to me like they've used a
linear mapping and that they use 10log(x) rather than 20log(x) which is
normally used for sound pressure (as far as I understand it - which is
admittedly limited).

I'm pretty sure that their representation is not optimal.

If my sums are correct their 200% (+3dB) is our 112% and their 400%
(+6dB) is our 126%.

> We probably should say that applications should end their scale at +6dB
> and in the PA case they should map that back via pa_sw_volume_from_dB() to a
> percentage, so that we have the freedom to change the mapping later on,
> without changing the meaning of the overdrive setting.
> 
> So, we could do this:
> 
> #define PA_VOLUME_OVERDRIVE (pa_sw_volume_from_dB(+3.0f))
> 
> instead of this:
> 
> #define PA_VOLUME_OVERDRIVE (PA_VOLUME_NORM+PA_VOLUME_NORM/2)

OK, so if I've done my sums right (150% = 1.5 relative to PA_VOLUME_NORM
= linear[1.5^3] = linear[3.375] = dB[20*log(3.375)] = db[20*0.528] =
db[10.57]) we could actually do:

#define PA_VOLUME_OVERDRIVE (pa_sw_volume_from_dB(+10.57f))

This will map to the current 150% used by g-v-c. e.g. this is the amount
by which it currently allows overdrive.

But, doing that would mean that if we change the mapping method >0dB in
than future it may turn out to be 200% or 342% or whatever (which is
going to happen anyway regardless of the actual dB value).

So the real question is, what should the overdrive dB value be? The 3dB
or 6dB currently supported in vlc's UI or something we define ourselves.
I agree that making it a dB value is sensible tho' ;)

> And then have the freedom of changing our mapping. OTOH that would mean
> that volume scales would end at a weird 112%. 
> 
> But yes, I guess I am not opposed in adding something like this.


Nice, once we decide on the values, the client code will likely get the
following code added:

#ifndef PA_VOLUME_OVERDRIVE
# define PA_VOLUME_OVERDRIVE (pa_sw_volume_from_dB(+10.57f))
#endif

So that I can use the new constant in the code to replace any hardcoded
(1.5*PA_VOLUME_NORM)s or just PA_VOLUME_NORMs on their own depending on app.

Does that seem sensible?

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