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
