Don’t say dumb, say distracted 
1 Like
Hi,
First I’ve to say that I’ve a good old Rasberry Pi 3B with the latest Volumio 3 release since several years (was on Volumio 2 before) which play like a charm and boot in less than 50" 
.
Because the Bandcamp plugin now only works on Volumio 4, I’ve tried the latest Volumio 4 ( 4.073 ) on my Pi 3B, then on a Pi 3B+ and finally on a Pi4, all was configured (without issue) via the Volumio 4 Android app. All connected via Wifi.
Notwithstanding the fact that the Pi 3B booted in more than 2’30" ( more than 1’30" with an USB3 SSD Disk on the Pi 4 
!?!?), none of them was able to play my favourites radios (https://icecast.radiofrance.fr/francemusique-hifi.aac?id=radiofrance or https://icecast.radiofrance.fr/fip-hifi.aac?id=radiofrance) without this damned : “alsa_output: Decoder is too slow; playing silence to avoid xrun” more or less regularly. After several hours trying to reinstall, trying other sdCard, trying other power supply, I suspect a problem with the Wi-Fi driver. I haven’t tested Ethernet because I can’t use it with my configuration and preferred to go back to my good old Volumio 3. Sorry.
EDIT: I’ve just tested the 4.080 release and …
2025-12-13T22:50:23 player: played “http://icecast.radiofrance.fr/francemusique-hifi.aac”
2025-12-13T22:50:24 exception: No such playlist
2025-12-13T22:50:24 exception: Bad song index
2025-12-13T22:50:37 alsa_output: Decoder is too slow; playing silence to avoid xrun
2025-12-13T22:50:42 alsa_output: Decoder is too slow; playing silence to avoid xrun
2025-12-13T22:50:47 alsa_output: Decoder is too slow; playing silence to avoid xrun
Same issue here on my Rasberry PI 3. The output often stutters for me, especially at higher resolutions, and I didn’t have this problem with Volumio 3.
alsa_output: Decoder is too slow; playing silence to avoid xrun
I’m not sure if it has anything to do with the power supply, because I also get an undervoltage message (but this was never a problem with Volumio 3).
Hey @Axel,
I will say this one more time, because I have explained it in these forums more times than I care to count.
“Undervoltage was not a problem with Volumio 3 so it should not matter on Volumio 4” is not how any of this works.
What undervoltage actually does:
The Raspberry Pi firmware - not the kernel, not the operating system - monitors input voltage. When it drops below threshold, the firmware throttles your CPU from 1200MHz down to 600MHz. This is hardware-level protection. It happens regardless of what Linux distribution you run.
Why you “did not have this problem” on Volumio 3:
You did have this problem. You just did not see the symptoms as clearly because:
- Volumio 3 runs Node 14. Volumio 4 runs Node 20. Higher baseline CPU demand.
- Volumio 3 runs Debian Buster with lighter systemd overhead. Volumio 4 runs Bookworm.
- Volumio 3 kernel 5.x/6.6.x has different scheduler behavior than kernel 6.12.x.
- Your Pi 3B (not 3B+) has the old micro USB power input with polyfuse. Voltage drop under load is significant.
The CPU had more headroom before. Now it does not. When throttling kicks in and your CPU drops to half speed while trying to decode a Tidal FLAC stream in real time, you get exactly what your mpd.log shows:
alsa_output: Decoder is too slow; playing silence to avoid xrun
That is not a Volumio bug. That is your CPU being throttled mid-decode because your power supply cannot maintain stable voltage under load.
What your log actually shows:
Interestingly, your submitted log contains zero undervoltage kernel messages. Either the undervoltage events occurred before this log window, or the problem is intermittent. But the xrun errors cluster together in bursts - five errors in 20 seconds at 21:27, another burst at 21:45 - which is textbook throttling behavior.
What you need to do:
- Get a proper 5.1V 2.5A+ power supply with short, thick cables. Not a phone charger.
- If you already have one, your cables or connectors may have degraded.
- Consider that a Pi 3B from 2016 running 2025 software with streaming services was never going to be sustainable forever.
Regarding the Tidal errors:
The decoder slowness is happening specifically during Tidal FLAC streaming. If you want to report playback issues with the Tidal plugin, that belongs in the Tidal plugin thread - but fix your power situation first, because no amount of software tuning will compensate for a CPU running at half speed.
Kind Regards,
Personnaly I do not have power issue (nor on the Pi 3B, 3B+, 4)
bash-5.2# vcgencmd get_throttled
throttled=0x0
Hey @domcars0,
Thank you for confirming no power throttling with vcgencmd get_throttled showing 0x0. That eliminates one variable.
However, this is exactly the problem.
You are drip-feeding individual pieces of information instead of providing a complete report. One command output does not replace a full log submission. Investigation requires systematic data collection, not a scavenger hunt across multiple posts.
The help request template exists for a reason:
What you have now provided across multiple posts:
- Device models: Pi 3B, Pi 3B+, Pi 4 - still no revision codes
- Storage: SD cards, USB3 SSD - still no brands or models
- Connection: WiFi only - still no band, no signal strength
- Audio output: still not specified
- Power status: no throttling (good)
- Problem: “Decoder is too slow” errors with Radio France AAC streams
What is still missing:
- Log link from http://volumio.local/dev
- Exact Raspberry Pi revision codes
- DAC or audio output device
- WiFi band (2.4GHz or 5GHz) and signal strength
- SD card and SSD specifications
- Ethernet test results (even temporary)
The “Decoder is too slow” error indicates MPD buffer underruns during streaming. WiFi latency is a common cause, particularly with high-bitrate AAC streams like Radio France HiFi. Without logs showing the actual system state during playback failure, there is nothing to investigate.
Submit a log. Identify your hardware completely. Then we can help.
Kind Regards,
Volumio 4 is no more really compatible with the Raspberry Pi 3B and 3B + ?
But , anyway, my issue also exists on the Pi4 with USB3 SSD Disk.
For the audio output I’ve tried my HifiBerry Digi , and the HDMI audio output (same issue)
SD Card are all Sandisk Ultra HC 1 - Class 10
SSD is a Kodak X200
Wifi Band is 2.4Ghz on Pi3, 5Ghz on Pi4
bash-5.2# /sbin/iw dev wlan0 link | grep signal
signal: -60 dBm
Log report:
http://logs.volumio.org/volumio/cfCkoYn.html
For France musique, I used the same link , I found it on the web, and with raspberry pi 5 + iqaudio dac pro + volumio os 4.080, no issue at all.
I tried FIP, FIP jazz, France musique, France Inter… No issues with “icecast links”.
Hi Mrskyou, thank for your reply. How long have you tried it ? Sometime it could play well during 1 or 2 hours, sometime 1 minute 
. I, also tried the icecast links, same issue. If Volumio 4 need a Pi 5 to play smoothly, I will stay on Volumio 3 
1 Like
Hey @domcars0,
Thank you for the log. Now we have something to work with. Here is what I found:
Device confirmed:
Raspberry Pi 4 Model B Rev 1.1, Volumio 4.080, kernel 6.12.47-v7l+
Suspicious - Audio output misconfiguration:
You stated you tested with HiFiBerry Digi. The log shows otherwise.
From aplay -l:
card 0: b1 [bcm2835 HDMI 1]
card 1: Headphones [bcm2835 Headphones]
From /etc/asound.conf:
pcm.volumioHw {
type hw
card "b1"
}
From i2cdetect:
Empty - no devices detected on I2C bus
Your system is configured for HDMI audio output, not HiFiBerry Digi. The HiFiBerry Digi is not present in this configuration. Either it is not connected, not enabled in Volumio playback options, or requires a dtoverlay that is missing from /boot/config.txt.
Your userconfig.txt is also empty:
# Add your custom config.txt options to this file
If HiFiBerry Digi was configured, you would see the appropriate overlay and the DAC would appear in aplay -l and respond on I2C.
WiFi signal quality:
- Signal: -62 dBm
- Link Quality: 48/70 (68%)
- Band: 5GHz at 5.18 GHz
- Link speed: 390 Mb/s
This is marginal. For reliable high-bitrate streaming, you want -50 dBm or better. At -62 dBm you are in the zone where packet retransmissions become more frequent, causing latency spikes.
MPD log pattern analysis:
22:49:51 alsa_output: Decoder is too slow; playing silence to avoid xrun
22:49:56 alsa_output: Decoder is too slow; playing silence to avoid xrun
22:50:02 alsa_output: Decoder is too slow; playing silence to avoid xrun
...
22:50:18 ffmpeg/aac: Packet corrupt (stream = 0, dts = NOPTS)
22:50:18 ffmpeg/aac: Input buffer exhausted before END element found
22:50:18 exception: transfer closed with outstanding read data remaining
The xrun errors occur at consistent 5-second intervals. This is MPD’s ALSA output buffer draining completely because the decoder cannot refill it fast enough. The decoder cannot refill because the network is not delivering data fast enough. Then the AAC decoder reports corruption because the stream was interrupted mid-packet.
The final line confirms it: “transfer closed with outstanding read data remaining” - the HTTP connection delivering the Radio France stream was interrupted before completing.
This is network-induced decoder starvation.
wireless.js CPU anomaly:
root 703 1 22 22:48 ? 00:06:05 node /volumio/app/plugins/system_controller/network/wireless.js start
The wireless.js process consumed 6 minutes of CPU time and was running at 22% CPU at the time of log capture. This is abnormally high for a network management process and may contribute to overall system load.
SD card identification:
The log shows:
mmcblk0: mmc0:aaaa SC16G 14.8 GiB
“SC16G” is a generic identifier. Genuine Sandisk Ultra cards typically identify with more specific product strings. This card is running in DDR50 mode, which is correct for SDHC.
Summary:
- Audio output is HDMI, not HiFiBerry Digi as you stated
- WiFi signal is marginal at -62 dBm
- MPD buffer underruns are caused by network not delivering stream data fast enough
- Radio France HiFi AAC streams require consistent bandwidth that your current WiFi signal cannot reliably provide
Clarifications:
-
If you intend to use HiFiBerry Digi, configure it properly:
- Select it in Volumio playback options
- Verify the dtoverlay is applied
- Reboot and submit new log
-
Improve WiFi signal or test with Ethernet:
- Move device closer to access point
- Reduce interference sources
- Even temporary Ethernet test would confirm or exclude network as root cause
-
Test with a lower bitrate stream to isolate the variable:
- Radio France offers standard quality streams alongside HiFi
- If standard quality works reliably, the issue is bandwidth-related
The problem you are experiencing is not a Volumio 4 defect. It is a combination of marginal WiFi signal and high-bitrate stream requirements. Your Volumio 3 setup may have worked because you were using different audio output, different WiFi conditions, or different stream URLs.
Kind Regards,
Hi @nerd , thanks.
For your informations here is the logs for the Pi 3B+
http://logs.volumio.org/volumio/FMAW9Pd.html
I just have to say that the Radio France stream works very well on a Pi3B with Volumio 3 but not with Volumio 4 in exactly the same conditions (same place in the room, same Pi, same HifiDigi …) . That’s all. If you think this is normal, it’s ok, I agree.
Thanks @nerd,
and sorry if I missed your comment before, but it shows that it’s worth repeating. So thank you for that! I’ll try a different power supply and hopefully that will fix the problem.
But because you write: “Interestingly, your submitted log contains zero undervoltage kernel messages”: Is the message “Dec 12 23:47:51 volumio-4k kernel: hwmon hwmon1: Undervoltage detected!” in line 1,463 of my log not a kernel message?
The problem reported here has nothing to do with Tidal (which is why I didn’t mention Tidal here). I post my problems with Tidal (I also have the problem there that it stutters sometimes) in the forum you mentioned, but there it refers to an installation on a PI 5 with a 65 W USB C power supply.
Best regards
1 Like
Hey @domcars0,
I owe you a partial acknowledgment. The Pi 3B+ log reveals something significant.
The smoking gun - wireless.js runaway:
root 676 1 99 23:43 ? 00:05:33 node wireless.js start
This process is consuming 99% CPU. It accumulated 5 minutes 33 seconds of CPU time in approximately 4 minutes of wall-clock time. This means it is saturating more than one CPU core on your quad-core Pi 3B+.
On your Pi 4 log, the same process was at 22% CPU with 6 minutes accumulated - still abnormally high, but not completely runaway. The Pi 4 has faster Cortex-A72 cores that can absorb this overhead better than the Pi 3B+'s slower Cortex-A53 cores.
Network endpoint latency proves CPU starvation:
Pi 3B+ (this log):
https://google.com, 5252 ms: OK
Pi 4 (previous log):
https://google.com, 948 ms: OK
The Pi 3B+ shows 5x higher network latency despite BETTER WiFi signal strength (-57 dBm vs -62 dBm on Pi 4). The latency is caused by CPU starvation preventing timely network packet processing.
This explains the xrun errors:
When wireless.js consumes all available CPU cycles, MPD cannot process incoming stream data fast enough. The ALSA buffer drains, xrun occurs, decoder reports “too slow”. The problem is not WiFi signal quality or stream bitrate - it is a runaway Node.js process starving the system.
Why V3 works and V4 does not:
Your observation that the same setup works on V3 is now supported by evidence. Something in Volumio 4’s wireless.js implementation triggers this excessive CPU consumption.
However - your audio output is still misconfigured:
Both logs show HDMI audio output, not HiFiBerry Digi. i2cdetect shows no devices on the I2C bus. Whatever testing you did with HiFiBerry Digi, these logs do not reflect that configuration. This is a separate issue.
Current status:
I do not have a workaround to offer. The wireless.js CPU consumption pattern is noted and warrants further investigation.
Kind Regards,
I know, this is not the problem. I just said that the “Decoder is too slow” exist with or without the HifiBerry (my old Pi 3B is now in is very nice case with the HifiBerry and Volumio3 and I do not want to extract it again, sorry). All my logs was made with hdmi output.
Thank you very much for your work. I hope you will catch the bug (but you will!).
I was intrigued by this response. I used https://raw.githubusercontent.com/TheRemote/PiBenchmarks/master/Storage.sh to check this card on my PC and the response is
Drives:
Local Storage: total: 277.54 GiB used: 67.37 GiB (24.3%)
ID-1: /dev/mmcblk0 vendor: SanDisk model: SC16G size: 14.84 GiB type: Removable
ID-2: /dev/sda vendor: Samsung model: SSD 850 EVO 250GB size: 232.89 GiB
ID-3: /dev/sdb vendor: LITE-ON IT model: LSS-32L6G-HP size: 29.82 GiB
Message: No optical or floppy data found.
So it looks like this card is a true SanDisk … 
Is there already Version 4.080 for Raspberry Pi???
Kind regards
Uli MzO
Germany
Yes, it’s a test version. To try it you select the test channel in youripaddress/dev
Hey @uli_3,
You made me worry sick that search function in our forum is broken:
You know, you can use it in the same way as on your smartphone or social media - try and see if this works.
Kind Regards,
4.080 (OTA from 4.073) WiFi working, SQ very good (V4 for me sounds definitely better than V3). Some version of 4.07x were sounding different (worse), but they also had some strange wifi behaviour, many undervoltages in log, and some distortions (seems that 24/192 files from Tidal was worst scenario).
Good to know that someone else heard distortions. For me, it was with Qobuz on 4.073. After a day with 4.080, I am back to 3.874 as 4.080 still doesn’t sound quite right although maybe it’s better than 4.073.
My observations could be due to a specific streamer setup, using a JCAT Femto USB card for audio out (to a USB DAC). Perhaps, something in the underlying software/core of Volumio 4 manages the PCIe port differently, causing a digital glare and deteriorated imaging compared to v3.