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

[Lennart Poettering]

On Wed, 14.04.10 11:38, Colin Guthrie (gmane at colin.guthr.ie) wrote:

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

Hmm, one more addition to this. I find myself pulling up the volume
slider to the full 150% exposed in g-v-c from time to time when using
unamplified headphones on a USB sound card on a movie, and I am kinda
happy that I can do that. That's +10dB (amplitude) or so. So limiting
things to +6dB looks a bit too low for me.

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

Hmm, their dB scale is based on power, not amplitude. As it
seems. Interesting choice, but I am kinda sure that most vol controls
focus on amplitude, not power. And PA does too. And ALSA as well.

Choosing a linear mapping is a pretty bad choice, so much as definite.

http://www.robotplanet.dk/audio/audio_gui_design/
http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-May/thread.html#23151

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

Yepp, that is true. Though this is actually a double, not a float, the
'f' should go.

> 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' ;)

I am quite happy with the current mapping in g-v-c to be honest, and so
far I haven't heard any complaints that it was too little.

So to make things clean we could just say +11dB (amplitude) as max. And
claim this is the ultimate truth. ;-)

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

Yes, absolutely.

Lennart

-- 
Lennart Poettering                        Red Hat, Inc.
lennart [at] poettering [dot] net
http://0pointer.net/lennart/           GnuPG 0x1A015CC4