'Twas brillig, and Raymond Yau at 08/06/10 05:01 did gyre and gimble:
According to your email , you mention than your hardware has a cutoff at 14% in PA
It's actually closer to about 16%... but in that area yes.
the mixer application programmer can select any kind of scaling in the slider
Indeed, but pulseaudio exposes a pa_volume_t which is basically a linear scale. This upper bound is exposed via a constant: PA_VOLUME_MAX
pulse/volume.h:113:#define PA_VOLUME_MAX ((pa_volume_t) UINT32_MAX-1)
And the "100%" aka 0dB point is represented by another constant, PA_VOLUME_NORM:
pulse/volume.h:107:#define PA_VOLUME_NORM ((pa_volume_t) 0x10000U)
The scale between 0 and PA_VOLUME_NORM is linear via pa_volume_t but this is mapped via the cubic mapping internally when controling the volume of the alsa device.
So volume control GUIs and the ALSA plugin use this scale in a linear fashon to represent the rand 0% (pa_volume_t = 0) to 100% (pa_volume_t = PA_VOLUME_NORM).
do you mean 14% in pavucontrol or Master volume control of "pulse" device ?
Both. They both use the range 0 ... PA_VOLUME_NORM to represent 0% - 100% and thus they correspond with each other fine[1]
but pavucontrol did not provide any dB value at any point
It doesn't display the dB value, but perhaps it should? It's more of a developer tool anyway (tho' used by a lot of users until desktop provided tools catch up) so exposing dB here would make sense IMO. I'll cook up a patch.
Col
1. Note that this may change at some point in the future as we define how much to show the user as an "overdrive" of volume. As you may know, gnome-volume-control allows a setting up to 150%, but this isn't refelected in the alsa plugin. Ultimately we decided to define a new constant "PA_VOLUME_OVERDRIVE" (or similar, I can't remember the exact name) and set this to be +11dB (via the current cubic mapping function). This approximates to the 150% offered in g-v-c.