Volume control; Linear or logarithmic?

thommy

Have just installed rune onto an SD as it was quicker than trying to duplicate my existing raspbian/MPD 'nuts & bolts' installation.

The first thing that I notice is that the volume control seems linear. Anything below 50% is inaudible, and all the action occurs between about 70 & 100. Decibels and of course human hearing work on a logarithmic scale so this volume control just doesn't seem to be working as expected. If I put a linear potentiometer on my preamp it would exhibit the same behaviour.

Thoughts?

ACX

Hi thommy,
are you using hardware mixer, right? If yes, I confirm you that the issue is caused by the different way to control the volume: MPD uses a linear one, instead the hardware volume usually use a logarithmic one. I say usually because all the interfaces I tried have logarithmic volume control, but I can't say if some others work with linear one. You can see this behaviour throttling the volume knob the UI and in the meanwhile seeing how it behaves in alsamixer.

Fin

I'm loving RuneAudio, sounds great via my IQaudIO Pi-DAC! If there was one thing bugging me though, it would be the mapping of the hardware volume control.

What actually happens "behind the scenes" to set the volume once the dial has been adjusted in the UI? Is the UI using the amixer command to set the volume? (Sorry my knowledge of coding and of linux is very limited!)

The reason I ask is that the amixer command has a -M option for a more natural volume curve. I found this in the help for amixer: "-M Use the mapped volume for evaluating the percentage representation like alsamixer, to be more natural for human ear."

For example when setting a 50% volume level, the following:

amixer -c 1 "Playback Digital" 50%

Sets the volume exactly the same as setting the RuneUI volume dial to 50%, and is barely audible at all:

[root@runeaudio ~]# amixer -c 1 sget "Playback Digital"
Simple mixer control 'Playback Digital',0
  Capabilities: volume pswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 40 - 255
  Front Left: 148 [50%] [-49.50dB] Playback [on]
  Front Right: 148 [50%] [-49.50dB] Playback [on]

But using -M instead:

[root@runeaudio ~]# amixer -c 1 set "Playback Digital" 50% -M

Gives this result, which matches very closely to the 50% volume level of alsamixer:

[root@runeaudio ~]# amixer -c 1 sget "Playback Digital"
Simple mixer control 'Playback Digital',0
  Capabilities: volume pswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 40 - 255
  Front Left: 218 [83%] [-14.50dB] Playback [on]
  Front Right: 218 [83%] [-14.50dB] Playback [on]

I hope this helps in some way!

ACX

Hi Fin,
we were thinking about binding the volume knob in the RuneUI to the real volume range (and its integer steps) when using the hardware mixer. I think it's the only way to have a real and accurate control of the volume using all the 216 steps available by I2C control (40-255). To do that we have to bypass MPD volume control and implement a parallel one via amixer commands. 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.

Now I'm out of home but tonight I will try the -M option in person. Thank you for the suggestion!

ACX

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.
A quick example:

[root@runeaudio ~]# amixer -c 1 set "Playback Digital" 75% -M
Simple mixer control 'Playback Digital',0
  Capabilities: volume pswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 40 - 255
  Front Left: 240 [75%] [-3.50dB] Playback [on]
  Front Right: 240 [75%] [-3.50dB] Playback [on]
[root@runeaudio ~]# amixer -c 1 set "Playback Digital" 76% -M
Simple mixer control 'Playback Digital',0
  Capabilities: volume pswitch
  Playback channels: Front Left - Front Right
  Capture channels: Front Left - Front Right
  Limits: 40 - 255
  Front Left: 240 [75%] [-3.50dB] Playback [on]
  Front Right: 240 [75%] [-3.50dB] Playback [on]

You'll see that 75% and 76% give the same result: 240.

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?

Fin

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 wroteI 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 wroteWe 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.

gswg

My understanding is that applications (MPD included) should ask for the audio card's range, max and min. Then based on this should damp any volume scale to the specific hardware's range.

The PCM5122 (as used on the Pi-DAC) can go from -103.5db to 23db. We have limited it to +4db at 100% on Alsa but not sure what other cards will do here - that all makes it very difficult for apps like RuneAudio.

Maybe it's worth bypassing MPD for volume completely and just doing the right thing via ALSA calls?

Happy to help with whatever I can do here as it will benefit all of us in the long term.

Gordon@iqaudio.com

ACX

gswg wroteMaybe it's worth bypassing MPD for volume completely and just doing the right thing via ALSA calls?

That's the approach we are talking about, both ways (-M option or accurate hw values) need direct amixer control. No problem to code that (and also adapt the range to different DACs), but it will work only using RuneUI (and not with other MPD clients).

Fin

It's a shame that it seems to be either a bug or at the least a shortcoming of the volume control baked into MPD. When googling I came across a bug tracking page for MPD, and I didn't see anything listed to indicate it was even on the radar unfortunately. It would be unwise to hold your breath, waiting for an improvement!

I feel it would still be worth remapping the volume control in the RuneUI interface, as for the majority of users this is what they will be using to control RuneAudio with. I know in my case I haven't used a MPD client, I just have a shortcut to the web interface on the iPad, android phone, and my desktop PC.

I think in the long term, I'm going to add a rotary encoder and control the volume that way as well. Gordon, I saw the code you've shared to do so, hopefully my ebay buys come in soon and I can get it working OK. Thank you for sharing the code!

gearhead

Is there any update on this? I have a 5122 and am in the same boat. Is there a workaround for this?

Keith

Muffinman

I've written an application that might be of use. It's a.o. designed to synchronize Linux/Alsa volume levels with that of e.g. amplifiers using different interfaces (serial/tcp/i2c) and vice versa in configurable command structures. It reads out Alsa volume levels in a linear fashion but can convert it to a log scale. If necessary different curves can easily be added. While I only added the log functionality quite recently, it does seem to work well (although I don't use the log functionality myself). This method works well for any application that can send audio and mixer data to different interfaces (e.g. MPD, Shairport, uPMPD). You're welcome to give it a try, see if it works for your purpose, give comments and/or suggestions, and report any bugs you may encounter.

https://github.com/therealmuffin/synchronator

Orion

Hi Muffinman,
wellcome to RuneAudio forum. Thank you for this software, I think that Syncronator is a great idea! Surely we are interested to integrate it into RuneAudio. You arrive here in perfect timing, because we are working hard to complete the refactory of our backend with a lot of interesting new features. Are you available to collaborate for a deeper integration of Syncronator with the upcoming RuneAudio new stack? PM me if you are interested.

Bye.
Simone

jcoman

ACX wroteThat's the approach we are talking about, both ways (-M option or accurate hw values) need direct amixer control. No problem to code that (and also adapt the range to different DACs), but it will work only using RuneUI (and not with other MPD clients).

I know this is a year old, but I just wanted to add my two cents here.

I currently have 0.3 beta running on 4 raspberry pi model B's, playing to 4 different zones in the house. I have a 5th pi running a Flask webserver to control the zone amplifiers, as well as serve a 'remote control' of sorts. Basically, it just has volume, skip and play/pause buttons that are really easy to push quickly (like if the phone rings and you want to pause the music, you don't have to go hunting around the the RuneUI page for the pause button). It currently uses CORS requests to control the MPD on the corresponding pi.

If you bypass the MPD for the volume control, it might be good to still expose the functionality to MPD clients (or the like) by redirecting the volume requests to the Rune back-end, or something like that.

ACX

jcoman wroteIf you bypass the MPD for the volume control, it might be good to still expose the functionality to MPD clients (or the like) by redirecting the volume requests to the Rune back-end, or something like that.

Yes, that's the approach we are taking for it.

bloodnok

I have just released a hack for this. There is an executable for the Pi model 1 with a DAC+ which you can try.

https://github.com/marcmunro/MPD

The REAME file should give you enough details to get going.

taravasya

I have XMOS+PCM5102, and I have same issue. All volume under 50% its just a silence )))
By the way, on Volumio everything normal with this...