You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
first, I really appreciate your work here. I completely dropped my old Multi-Room system and build a new one around Music Assistant and Sendspin. Love it!
But I have problems with one of my sendspin clients.
This is running on a Raspi Zero 2W, With Raspi OS Lite on Debian 13.4 and Sendspin 5.9.0.
I constantly get Audio underflows. Every 1-2 minutes, sometimes more.
First I thougt this is a weak wifi connection. I disabled wifi-sleep, disable cpu throttling echo "performance" | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
disabled bluetooth, made a firmware upgrade. But nothing improved the situation.
I also moved the PI directly next to the Wifi-AP. The number of underflows dropped down to every 5min, but they are still there.
So from my point of view, this is the best wifi situation I can give to the PI. Therefore the underflows must also be caused by another issue. But I dont know how to proceed. Any ideas from your site?
Or is the wifi from the PI that bad, that even the best connection is not fast enough?
All other clients in the wifi are working fine. The wifi itself is very stable. Even my HA Voice PE, which is placed farther away from the Wifi-AP is working fine with sendspin.
In the past it feels like, the situation was better. I was around sendspin 1.x and then updated to 5.x. Not fully sure, but I think the problems started getting worse with the update. Before I had a dropout every 30-60min.
top gives me around 3-6% CPU and 24% mem in idle for sendspin. If I stream music, CPU is up to 12%, Mem goes to 25-28%.
I enabled hardware_volume via settings-daemon.json, no difference.
I tried also different audio format settings in MA. But only 16/24bit. There is no 32bit quality. Also no difference.
I disabled avahi-daemon, no improvement on my problem.
I tried a external USB-wifi antenna, which gives me 5GHz wifi, better signal etc. But also no improvement.
I found this in the logs: sendspin[1435]: WARNING:sendspin.cli:No volume control available for device 'default' (no ALSA mixer controls and PulseAudio/PipeWire not reachable), falling back to software volume control
How can I get rid of this? I use this Pimoroni Audio DAC Shim which sends a fixed line-level output. I control the volume on my amplified speakers. So I dont need volume control at all.
I think I found the problem.
I tried sendspin with a esp32, thinking that this must work, surprisingly it does not.
Then I started investigating further my wifi. initially I thought the Wifi and therefore my whole network isnt the problem, because a hardwired Raspi showed the same problems.
But then I discovered that one of my Access Points hab nearly 100% use of airtime. First I thought my printer was flooding my network with mDNS announcements. But the real reason was my Homebridge. This flooded the network with mDNS announcements. The printer just tried to answer all these announcements and used all the airtime.
But the mDNS flood seems to be the reason that also the wired Raspi had problems.
I changed the mDNS advertiser in Homebridge to Avahi, prior it was Bonjour.
At the moment it is running for nearly 1h without a single audio underflow...
Activity
balloob commentedon Apr 10, 2026
Can you run
topto see your CPU usage. Also make sure hardware volume is enabled. If that still happens, try setting it to 16 or 32 bit quality.If certain Python dependencies fail to compile or are missing, we fall back to software-based calculations in Python, which are slow.
Se7enair commentedon Apr 10, 2026
topgives me around 3-6% CPU and 24% mem in idle for sendspin. If I stream music, CPU is up to 12%, Mem goes to 25-28%.I enabled hardware_volume via
settings-daemon.json, no difference.I tried also different audio format settings in MA. But only 16/24bit. There is no 32bit quality. Also no difference.
How can I check the Python dependencies?
Avahi-daemon is eating a lot of cpu...
Se7enair commentedon Apr 10, 2026
I disabled avahi-daemon, no improvement on my problem.
I tried a external USB-wifi antenna, which gives me 5GHz wifi, better signal etc. But also no improvement.
I found this in the logs:
sendspin[1435]: WARNING:sendspin.cli:No volume control available for device 'default' (no ALSA mixer controls and PulseAudio/PipeWire not reachable), falling back to software volume controlballoob commentedon Apr 29, 2026
#238 should have fixed this. Can you update and try again?
Se7enair commentedon Apr 29, 2026
Unfortunately the problem persists. I am on sendspin-cli 7.1.0
Raspi Zero with Wifi and Hardwired Raspi 3 shows the same problem.
10:51:48 Stream STARTED: 3 chunks, 0.29 second buffered10:51:51 Audio underflow deected; requesting re-anchor10:51:52 Cleared audio queue after underflow (deferred from audio thread)Logs are written off. Cannot copy at the moment. But should be enough?
balloob commentedon Apr 29, 2026
Software volume control is the thing here that messes with things. It's very CPU intensive.
Se7enair commentedon Apr 29, 2026
How can I get rid of this? I use this Pimoroni Audio DAC Shim which sends a fixed line-level output. I control the volume on my amplified speakers. So I dont need volume control at all.
If I use this
I still get the log that there is no volume control available and he is falling back to software volume.
Se7enair commentedon Apr 29, 2026
I created a file
and used this as a hook for volume.
Sendspin seems to use now hardware volume. But still no improvement.
The wired raspi has also the problem.
I some kind I have an improvement. It seems that it happens less often, but it still happens :(
Se7enair commentedon Apr 29, 2026
I tried also another way:
gave me this
Se7enair commentedon May 13, 2026
I think I found the problem.
I tried sendspin with a esp32, thinking that this must work, surprisingly it does not.
Then I started investigating further my wifi. initially I thought the Wifi and therefore my whole network isnt the problem, because a hardwired Raspi showed the same problems.
But then I discovered that one of my Access Points hab nearly 100% use of airtime. First I thought my printer was flooding my network with mDNS announcements. But the real reason was my Homebridge. This flooded the network with mDNS announcements. The printer just tried to answer all these announcements and used all the airtime.
But the mDNS flood seems to be the reason that also the wired Raspi had problems.
I changed the mDNS advertiser in Homebridge to Avahi, prior it was Bonjour.
At the moment it is running for nearly 1h without a single audio underflow...
balloob commentedon May 14, 2026
Excellent that it works. Thanks for sharing the problem, that will help us in the future.