I threw the integer values that alsamixer and amixer -M uses into excel, and found the curve that matches it.
integer=rounddown(120*log(volume)+15)This gives exactly the same integers, except for volume = 0 and volume =1, they both fall below 40 so the minimum integer of 40 is used instead. If you mapped the 0-100 volume values to this algorithm, it would be close to perfect in my opinion.
edit: if using volume as a pure percentage, from 0 to 1, the algorithm is
integer=rounddown(120*log(volume)+255)ACX wrote:I just tested the -M option and it works as you described, and it's much more natural indeed. But it does not provide an absolute precision on the volume control, because the hardware and the percent ranges differ (216 steps the first, 100 steps the second), not allowing a 1:1 matching of values.
You'll see that 75% and 76% give the same result: 240.
This is purely due to rounding down to the nearest integer I think.
ACX wrote:Anyway, I'm thinking that an absolute precision in this particular case does not make much sense, because at 10% (corresponding at a 135 hardware value) the volume is barely audible. This means that the 40-135 range (almost the half of the total range) would be rarely used, sacrifying almost half of the knob's stroke for that zone. It could be better to use the -M option, although not absolutely accurate on every step change of the knob.
What do you think about it?
I agree, using every last integer is pointless. This mapping would give you meaningful adjustment on the whole volume dial much like the software volume scale.
ACX wrote:We also should display the knob with the new range (not 0-100 anymore, but 40-255, or 0-216), although this could be counterintuitive at the beginning.
I feel it would be much nicer leaving the dial values as 0 to 100, much more user friendly and intuitive. The mapping can happen behind the scenes.