Internet drop killed audio on balena-sound


I’ve read here [1] that balena-sound does not require an Internet connection to operate. Obviously, if you’re streaming FROM the Internet, you would need it. But for local devices streaming to balena-sound devices, it’s not supposed to be necessary.

However, yesterday, my ISP dropped for about 5 minutes, and all audio quit immediately. In fact it’s how we found out the Internet dropped, because no one was doing anything at the time that would have shown it to be down. I have network monitoring and verified that it was not my router or some other issue on our network

I’m more interested in understanding possible reasons for the drop, so that I can dig in and see what I can find. If anyone can give some ideas, that would be useful. Or if someone knows the full reason and can explain, even better!

[1] belena Sound and belena Cloud


Hi Mark, if all sources of audio are local and devices can still comunicate using local network balenaSound should keep working normally.

Can you tell us more about your balenaSound setup? What are you using as audio source? How are your devices comunicating? Bluetooth, WiFi? Are you using multi-room features?

When your Internet went down, could you still communicate using local network?

Hi pipex,

I have four balena-sound devices, set up with multi-room. Two are RPi 4Bs (connected via 3.5mm wire), one is a RPi B+ (3.5mm wire), and the last is a RPi Zero W (connected via HDMI). The B+ and the ZeroW are both auto-configured as client-only devices, as you would expect. I also have installed the snapcast client onto three of our desktop computers, and they were joined into the playback system as well. So there were two servers and 5 clients running. I was sending audio from iTunes on my Windows 10 Home desktop to one of the master units over airplay. The other server had nothing attached. Nothing was streaming from the Internet.

When the outage hit, playback stopped on all devices at once. Even iTunes detected a problem, because it was paused when I checked it. That tells me either the airplay protocol sent back a failure to iTunes when the server RPi was affected by the outage, or the outage caused the RPi server to have an issue, and iTunes was not able to send to it any longer.

The ISP outage did not last long enough for me to find out whether I could just restart playback. By the time we figured out what was going on, ISP was back up, and the balena-sound system stabilized and was usable again.


Hi Mark – I wonder if your wireless router came from your ISP? If so, then depending on the nature of the outage and how the router is managed, you could imagine its WiFi functionality being affected. If so, perhaps the various devices were unable to connect to each other.

While WiFi Direct appears to be supported by iOS, I’m not sure about iTunes on Windows. Additionally, Shairport-sync (used by BalenaSound) does not currently support WiFi Direct.


Hi Hugh,

WiFi on my network is built on three Ubiquity UniFi AP-lites and an EdgeRouter PoE. I don’t think WiFi Direct is in action here, but honestly I’m not certain. I would expect the balena-sound stuff and iTunes to be explicit if it were using that. My iTunes didn’t indicate anything specific about how it is connecting to Shairport-sync. Also, the RPi server is physically pretty far from my desktop, so it would be a weak signal if it was direct between the two, and there weren’t any playback quality issues at the time.

This is what iTunes looks like:
Airplay in iTunes

EDIT: Is there any dependency on DNS that may have interrupted something? Obviously, when my ISP dropped, DNS stopped resolving.

EDIT 2: Well, heck. I can’t seem to reproduce the issue at all. I pulled my WAN interface and left it for a few minutes. That didn’t trip anything up. Then I pulled the power cord on my cable modem and let that sit for about 10 minutes before plugging it back in. And that didn’t cause anything to drop either. So I’m just going to have to call this a spurious issue. If it happens again, I’ll see what I can find in logs to see if maybe one of the RPIs was re-configuring coincidentally or something.


Hi Mark

That is strange indeed. And yeah you are right - it will be hard to debug this if it’s not reproducible.
I’d suggest that you enable persistent logging if you haven’t already. That way if this happens again we will have some lops tthat are save to disk that we can check.
Do keep us posted!