• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

ALSA Volume Mapping

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
Hi,

I have very little knowledge of psychoacoustics, so I was wondering if those of you who did could explain to me if the ALSA (Advanced Linux Sound Architecture) volume mapping makes any sense and why?

In my limited exposure to discussion of loudness/volume/human perception I can't say I've ever come across a mention outside of the ALSA code of a volume (cubic) relationship to linear scale of the voltage of the DAC for human sound perception.

So does this make sense? The interval mentioned is the ALSA 0 to 100 volume scale.

From the alsamixer man page.
VOLUME MAPPING
In alsamixer, the volume is mapped to a value that is more natural for
a human ear. The mapping is designed so that the position in the in‐
terval is proportional to the volume as a human ear would perceive it,
i.e. the position is the cubic root of the linear sample multiplication
factor. For controls with a small range (24 dB or less), the mapping
is linear in the dB values so that each step has the same size vis‐
ually.

It tripped me as odd when looking at the reaction of a Topping D10s (0 to -127 dBfs volume control) to the ALSA volume. Just a few select points as examples.
ALSA Vol / Topping Vol
0 / -127 dB * Huge dB steps at beginning
1 / -105 dB
2 / - 93 dB

48 / -19 dB * At this point ALSA doesn't even use it's full 100 point resolution
50 / -18 dB * because the Topping has 1 dB resolution and 49 would be somewhere in between.
52 / -17 dB

89 / -3 dB
93 / -2 dB
96 / -1 dB
100 / 0 dB * And at the end it takes 4 ALSA steps to even make a 1 dB change.

Certainly it doesn't seem the most efficient use of the available steps.
 
OP
S

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
Possibly of interest to some, this same curve is incorporated into the music player daemon (mpd) which is the basis for a lot of the popular audio streamers such as Volumio, moOde, and RuneAudio.
 

pozz

Слава Україні
Forum Donor
Editor
Joined
May 21, 2019
Messages
4,036
Likes
6,827
I think it's based on the sone scale:
1601264495816.png

The ALSA volume control is partially arbitrary since loudness is frequency-specific (phons are anchored at 1kHz, and sones are based on phon) and can only be mapped to SPL, not dBFS or voltage.
 
OP
S

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
Thank you. I wasn't aware of that curve and it's at least close to a cube root relationship so maybe you're right the ALSA curve is only partially arbitrary. Are you perhaps aware of a better curve for normalizing volume into a 0-100 voltage or dBFS range?

A clarification on mpd, poking at their code a bit it seems only when mpd is directly calling ALSA does it use this normalization curve.

My impression is this was added to shorten the area of the 0-100 volume scale that represents volumes lower than are useful in a typical computer (and home) listening scenarios.
 

pozz

Слава Україні
Forum Donor
Editor
Joined
May 21, 2019
Messages
4,036
Likes
6,827
Are you perhaps aware of a better curve for normalizing volume into a 0-100 voltage or dBFS range?
No, I was speaking from a purely psychoacoustical perspective. The findings from psychoacoustical research are specific to certain SPL levels, which cannot be directly converted to electrical or digital quantities without calibration. In that sense the curve ALSA applies is somewhat arbitary.

I prefer using dB-based curves. Perhaps out of habit more than anything else. Familiarity with DAWs and mixing gear, and so on.
 
Last edited:
OP
S

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
I prefer dB curves too. Nice to have something with a defined relationship vs some voodoo curve or random dial that maybe goes to 11.

In ALSA's defense they are trying to solve the random dial problem for random hardware whose actual dynamic range varies widely. They have a special case for less than 24 dB of range, so obviously some hardware out there has that limited of a range.

I guess in the end it's less psychoacoustics and more the psychology of the slider bar. It would probably work better if they had never presented the 0-100 number and just had a slider or knob with no tick marks other than 0 and 100.
 

pozz

Слава Україні
Forum Donor
Editor
Joined
May 21, 2019
Messages
4,036
Likes
6,827
I don't see a problem with the ALSA curve apart from the description. It is useful, like you said.

From the consumer side, I think most aren't aware of different curves and treat the step progression and their hearing as linear. I'm not sure what I would do were I in the designer's role. Workarounds are tempting but make the most sense only when the user possesses all the facts.
 
OP
S

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
Well the one problem with the ALSA curve and what brought it to my attention is its use by mpd / mpd clients as a strictly feedforward system when it's not. I've attached a plot of volume set by command vs volume mpd actually ends up at. I labeled it %, but explicitly it's alsamixer's/mpd's 0 to 100 scale. This problem might exist in other music players based on ALSA as well. I don't know how many use this normalized curve and ignore the feedback aspect.

As you can see if you step the volume up at some points your volume actually goes down, which I think is a big no no. At worst it should remain unchanged if you have insufficient resolution, but never go down. alsamixer itself recognizes when the hardware doesn't have a point to hit on its curve and moves up multiple notches to skip over these oscillations. Since mpd is just using ALSA's code one can query mpd for the volume that actually got set and adjust the slider / readout in a GUI but most mpd clients don't. I don't know of any that do actually. Partly because there's nothing in the mpd documentation explaining that this happens and the setvol command doesn't return the actual volume set. It needs to be fetched in a separate query.

I'm pretty sure the author of mpd didn't know this happened. Someone opened a bug about it in April but there's been no helpful response. It also only works this way for an ALSA backend so it's inconsistent with mpd's volume control on other platforms.
 

Attachments

  • mpcvol.png
    mpcvol.png
    23.2 KB · Views: 179

pozz

Слава Україні
Forum Donor
Editor
Joined
May 21, 2019
Messages
4,036
Likes
6,827
Well the one problem with the ALSA curve and what brought it to my attention is its use by mpd / mpd clients as a strictly feedforward system when it's not. I've attached a plot of volume set by command vs volume mpd actually ends up at. I labeled it %, but explicitly it's alsamixer's/mpd's 0 to 100 scale. This problem might exist in other music players based on ALSA as well. I don't know how many use this normalized curve and ignore the feedback aspect.

As you can see if you step the volume up at some points your volume actually goes down, which I think is a big no no. At worst it should remain unchanged if you have insufficient resolution, but never go down. alsamixer itself recognizes when the hardware doesn't have a point to hit on its curve and moves up multiple notches to skip over these oscillations. Since mpd is just using ALSA's code one can query mpd for the volume that actually got set and adjust the slider / readout in a GUI but most mpd clients don't. I don't know of any that do actually. Partly because there's nothing in the mpd documentation explaining that this happens and the setvol command doesn't return the actual volume set. It needs to be fetched in a separate query.

I'm pretty sure the author of mpd didn't know this happened. Someone opened a bug about it in April but there's been no helpful response. It also only works this way for an ALSA backend so it's inconsistent with mpd's volume control on other platforms.
Poor linearity? That's unbelievable. Or maybe not.

One of the directions I'd love to see audio measurement take is of digital software, plug-ins and the like. ASR has definitely become the standard for playback gear, but the universe of digital tools has never really received the same comprehensive level of attention.
 
OP
S

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
Sadly poor implementations exist everywhere. Hardware/software, free/expensive, open/proprietary. Fortunately at least when it's free and open software problems can be fixed even when the most popular project lead can't or won't do it themselves. Hardware of course is far more annoying. Even if the person or company responsible wants to fix something it's often not practical to do so for the versions that already exist.

And then we have that middle ground called firmware. Yes it's really software, but manufacturer support for updating is often ridiculously bad and limited. Must use Windows and a special driver is the most common annoyance. I've also run into the we won't offer firmware updates because something could go wrong and we don't want to possibly have units shipped back to us so we'll just never fix any bugs. Nice.

Sorry, off-topic rant.
 

pozz

Слава Україні
Forum Donor
Editor
Joined
May 21, 2019
Messages
4,036
Likes
6,827
Sadly poor implementations exist everywhere. Hardware/software, free/expensive, open/proprietary. Fortunately at least when it's free and open software problems can be fixed even when the most popular project lead can't or won't do it themselves. Hardware of course is far more annoying. Even if the person or company responsible wants to fix something it's often not practical to do so for the versions that already exist.

And then we have that middle ground called firmware. Yes it's really software, but manufacturer support for updating is often ridiculously bad and limited. Must use Windows and a special driver is the most common annoyance. I've also run into the we won't offer firmware updates because something could go wrong and we don't want to possibly have units shipped back to us so we'll just never fix any bugs. Nice.

Sorry, off-topic rant.
Definitely fits the bill for products like AVRs and others that allow audio over ethernet. I'm sad I lack the signal processing expertise to do those assessments myself.
 
OP
S

seashell

Member
Joined
Aug 30, 2020
Messages
33
Likes
25
Yeah I don't trust AVRs or Smart TVs to be ethernet or internet streamers. I know they're going to be buggy and that the manufacturer is very unlikely to fix said bugs especially once next year's models come out. :( Better to leave those functions to something cheap and easily replaceable. Or go the software on SBC route for even more flexibility.

Long ago I actually didn't buy a particular brand of AVR because their firmware was not "user" upgradable. You had to ship it back to the manufacturer at your cost. I contacted said manufacturer and told them that was a bad idea and they gave me some song and dance about how user upgradeable was too hard and expensive and it could break etc. I told them I designed and sold products for much less cost than their products that were fully user upgradable with a fallback system so that if the upgrade went wrong it could be redone by the user no problem so clearly cost of such an implementation wasn't an issue. I even offered to fix their firmware upgrade issues as a consultant but they just went silent. :p I purchased a brand that was user upgradable instead.

I'm sad I lack the signal processing expertise to do those assessments myself.
Well that's the nice thing about places like this. People with different skills can provide help in different areas. Like you did for me on the psychoacoustics front. Thanks again.
 
Top Bottom