Reduce delay changing software volume?

[smartroad]

I am using a basic DAC with no hardware volume control so I am relying on the software volume. One thing I have noticed is that there is a significant delay between changing the volume (especially in large steps) and the volume actually going up or down. I say significant, its about half a second, but it causes people to think nothing has happened who don't know and will then over adjust. I was wondering is there any way to reduce that delay down?

[Tim Curtis]

I'm not able to repro such a large delay using Pi4 + Allo Boss DAC. I did notice a very slight delay though compared to Hardware volume which is instant.

Whats your platform: Pi, DAC, etc.

There is this newly discovered issue with MPD Software volume being much louder at a given level as compared to Hardware volume. They should be almost identical loudness at a given level. Possibly there are some bugs in Software volume routine ??

Someone will need to reproduce this level difference using a DAC that supports Hardware volume, Stock Raspbian Buster or Raspberry Pi OS and stock MPD 0.21.24, then submit an issue to MPD maintainer.

-Tim

[AlexTee]

Probably, that depends on the DAC and its driver. As I said before in the other thread, I don't have any volume level difference between Software and Hardware volume levels on 0dB point, and there is no distortion, when EQ is off. So, this is applicable to your setup, not to all.

[mtnbrit]

I always put the lag down to the 4MB mpd buffer. Theres a distinct 1-2 sec delay between making a volume control change on the GUI or USB knob, and hearing the effect of the change in volume. Is it possible the delay gets worse with lower bitrates as 4MB corresponds to more time at 44.1k than 384k for example?

[Tim Curtis]

Volume changes are communicated to the audio device using MPD setvol command. These protocol commands are processed separately and in parallel with audio data being received into the MPD audio buffer.

Client -> change volume knob -> send MPD setvol command ------> NETWORK ------> MPD on Pi (Server) -> Audio device.

Lag in processing protocol commands would suggest performance issues in Client, Network or Server.

[mtnbrit]

Everything else works instantaneously. The GUI updates the instant the change is made, it just takes a bit to hear the volume change in the audio.

Isn't it the case that software volume is applied by mpd as the data is filling the input side of the FIFO, but we hear the output side of the FIFO some time later in the DAC, the time depending on buffer size and bit rate? This would explain the lag, no? I might try setting the buffer larger, see if it affects the lag. I guess it cant be set below 4MB, which would be interesting to see if reduced the lag issue.

If however you are saying that mpd applies software volume to the output side of the buffer, right before the DAC, then we have a different issue I guess.

Edit: just tested and found that bitrate and buffer size apparently have no effect on the lag.

[mtnbrit]

Heres a screen grab showing the lag. 

https://www.dropbox.com/s/g2rzj916nzrnje...g.mp4?dl=0

[Tim Curtis]

Everything else works instantaneously. The GUI updates the instant the change is made, it just takes a bit to hear the volume change in the audio.

Isn't it the case that software volume is applied by mpd as the data is filling the input side of the FIFO, but we hear the output side of the FIFO some time later in the DAC, the time depending on buffer size and bit rate? This would explain the lag, no? I might try setting the buffer larger, see if it affects the lag. I guess it cant be set below 4MB, which would be interesting to see if reduced the lag issue.

If however you are saying that mpd applies software volume to the output side of the buffer, right before the DAC, then we have a different issue I guess.

Edit: just tested and found that bitrate and buffer size apparently have no effect on the lag.

The audio buffer exists in RAM and like any other buffer operates at CPU/RAM speeds. The only delays that could occur would be in an upstream process thats slow to deliver data to the buffer or in some down stream process thats slow in  doing something with the data after it's been read.

The audio buffer has nothing to do with laggy software volume.

[rix81]

hello, I'm very new with MoodeAudio, Everything seems to work fine, but I also have big delay on software volume change, 1..2 seconds.  Also tried to change volume via USB remote control, delay is the same. Moreover, If press and hold volume key, software seem to hang up for  some time (e.g 10 secs),  and remote control indicates that it loses connection. Pls help, 

My hardware rpi4 2 gb,  USB Dac -  Asus Xonar Essence STU
Also tried to run 2 different OS on rpi4  :   libreelec and volumio,  there are no delay, don't know if it helps though.
Tried to change buffer size, enable/disable resampling,   seems no affect
Checked cpu load,  it's about 4%
Pls let me know what more details to provide. Really like moode
sorry for my english

[Tim Curtis]

No issues on my end.

Long delays of any kind suggest something external to moOde software for example network issues, hardware issues, installation of 3rd party software, modified or hacked moOde image, etc.

In your case the log entry below indicates you are using a modified or hacked moOde 7.1.0 image. Stock moOde 7.1.0 uses 5.4.77 kernel.

Code:

Linux kernel = 5.10.17-v7l+ #1403

No dev support is provided for modified or hacked images, 3rd party software installs etc.