Well after all that, it did indeed turn out to be the WIFI at fault. My router - the NetGear R7000 / AC1950 has apparently had buggy firmware for years, and general consensus says the 1.0.9.42 firmware from 2018 was the last stable build. I rolled back to that, and my system is now running at ~90% stability! There are still occasional stutters & dropouts, so I’ll keep tinkering, but it feels much better now.
Thank you to everyone who contributed to this incredible project, and for helping me debug - it’s been cool learning a little bit more about its inner workings, and has given me some more customization ideas for my setup.
OK! I’ve reconfigured my setup, but now unfortunately can’t get any sound output at all, even though the logs look like audio is playing. I’ve been racking my brain to see what silly mistake I’m making, but I can’t figure it out.
Because it seemed like poor WIFI quality was an issue before, I moved my router into the room that contains the master Pi 4, and connected the master directly to the router via ethernet. This also means that the clients are closer to the router than they were before, so they should be getting a more stable WIFI signal.
I’ve created the application from scratch & re-flashed the SD cards a few times to make sure I was starting from a clean slate, but still no luck. I’ve used both the “Deploy with Balena” button as well as cloning the project and pushing with balena push on the CLI. I know the Balenasound project and BalenaOS have had a couple of updates since I initially had this setup working, so I’ve also tried creating the application / devices using older versions of the project & OS, but nothing’s done it yet.
I’ll keep messing with it, but any pointers are appreciated!
As a small update, I flashed Volumio to my Pi 4 to rule out any problems in the signal chain, and audio outputted successfully, so I think I can rule out faulty hardware.
What do you mean by this exactly? In your previous message, you said everything was working properly. Did anything change between now and then? Which parts did you reconfigure? Is there anything suspicious in dmesg?
Hey @zwhitchcox - by reconfiguration I just meant moving my router into the living room and connecting the master Pi 4 directly to the router via Ethernet, whereas before all of the devices were on WIFI. Moving the router also had the side effect of giving a stronger WiFi signal to the other Pis.
I’ve seen a bunch of posts on here in the last few days with the same issue (no sound output), so I’m following those in case we’re all experiencing the same issue from something that might have changed upstream. I’ll run dmesg tonight and see if it gives any more clues. Thank you!
The first thing to check would be to make sure that audio=off is not set on the DT parameters.
The next thing to do would be to share the support logs from the device here for us to review. You can obtain these by visiting the local IP address in a web browser like so: http://<DEVICE_IP>:3000/support. Share everything from this page on the forum here.
You can also share the audio block startup logs by filtering by the audio service in the dashboard.
One last thing is using the dashboard to open a terminal to the audio service. From within this terminal run paplay /usr/share/sounds/alsa/Front_Center.wav. This should output a spoken voice saying ‘Front center’ through the 3.5mm jack.
Hi there, last week we indeed found a bug that resulted in balenaSound installations with no audio (which admittedly is not a very useful thing :D). This has been fixed already (multiroom: no sound · Issue #423 · balenalabs/balena-sound · GitHub). Can you deploy the latest version (v3.5.2) and see if you are still experiencing trouble?
Hi all, thank you for keeping me updated on the changes made in 3.5.2. I’ve since pushed that release to my devices, and have one device (the multiroom master Pi 4) working again. The multiroom clients are not yet working. I posted in the original “Raspberry pi 4 - no audio” thread that included the PR that led to 3.5.2, so I’ll link that comment below. Happy to help test as needed - thank you for all you do!
Thanks for your patience here. Stringing together context and timestamps from the other thread you’ve mentioned, have you done a fresh push of balenaSound to your devices since @tmigone merged the fix? From the other thread, I get the context that you were testing it from the PR being worked on.
It never hurts to push the latest merged stuff. We had confirmations from other users that they’re up and running again and wanted to see if a fresh push works in your case. Just want to confirm here before we replicate and see if this is an ongoing issue.
Although I posted that message after testing on PR424, I did subsequently push the 3.5.2 release and confirmed the same behavior. I haven’t tried re-flashing the cards with 3.5.2 and building a new application from scratch, so I’ll try that now.
Okay, I pushed 3.5.2 to a new application using the “Deploy with Balena” method and flashed all the devices from scratch, and I’m still getting no sound output from the clients, with the same error logs from the multiroom-client service on the clients. The clients started in STANDALONE mode, so I did have to force the SOUND_MODE = multi_room_client variable on them, but that’s the only variable I’ve added for the entire application/devices/services.