Hello
I set up Balena Sound but I’m experiencing intermittent audio drops on my Rpi2 running latest version v2.1.9 when connecting via Bluetooth or Spotify Connect.
I have tried Ethernet and wifi dongle but experience is the same. From the logs I can see MiniBuffer error from the snapcast-client which correspond to sound dropouts (log extract below)
Any ideas? Is it possible to change the buffer size?
Really like the BalenaCloud environment so would like to get this working on couple of other legacy Rpi.
Many thanks for the assistance
Chris
25.04.20 14:53:01 (+0700) 2020-04-25 07-53-01 [Info] (Stream) Chunk: 0 0 0 0 500 89 0
25.04.20 14:53:01 (+0700) 2020-04-25 07-53-01 [Info] (onResync) onResync (default): 426 ms
25.04.20 14:53:02 (+0700) 2020-04-25 07-53-02 [Info] (Stream) Chunk: -4911 0 0 0 500 59 0
25.04.20 14:53:02 (+0700) 2020-04-25 07-53-02 [Info] (Stream) pMiniBuffer->full() && (abs(pMiniBuffer->mean()) > 50): -490480
25.04.20 14:53:03 (+0700) 2020-04-25 07-53-03 [Info] (Stream) Chunk: 0 0 0 0 1 59 0
25.04.20 14:53:04 (+0700) 2020-04-25 07-53-04 [Info] (Stream) Chunk: 0 0 0 0 19 59 0
25.04.20 14:53:05 (+0700) 2020-04-25 07-53-05 [Info] (Stream) Chunk: 0 0 0 0 39 59 0
25.04.20 14:53:06 (+0700) 2020-04-25 07-53-06 [Info] (Stream) Chunk: 0 0 0 0 58 59 0
25.04.20 14:53:07 (+0700) 2020-04-25 07-53-07 [Info] (Stream) Chunk: 0 0 0 0 80 89 0
25.04.20 14:53:08 (+0700) 2020-04-25 07-53-08 [Info] (Stream) Chunk: 0 0 0 0 101 59 0
25.04.20 14:53:09 (+0700) 2020-04-25 07-53-09 [Info] (Stream) Chunk: 0 0 0 0 122 59 0
25.04.20 14:53:10 (+0700) 2020-04-25 07-53-10 [Info] (Stream) Chunk: 6 0 0 0 140 60 0
25.04.20 14:53:09 (+0700) 2020-04-25 07-53-09 [Info] (onStateChanged) onStateChanged (default): 1
25.04.20 14:53:11 (+0700) 2020-04-25 07-53-11 [Info] (Stream) Chunk: 0 0 0 0 159 59 0
25.04.20 14:53:11 (+0700) 2020-04-25 07-53-11 [Info] (getPlayerChunk) Exception
25.04.20 14:53:11 (+0700) 2020-04-25 07-53-11 [Info] (Alsa) Failed to get chunk
25.04.20 14:53:16 (+0700) 2020-04-25 07-53-16 [Notice] (Alsa) No chunk received for 5000ms. Closing ALSA.
25.04.20 14:53:37 (+0700) 2020-04-25 07-53-37 [Info] (Alsa) frames: 1324
25.04.20 14:53:37 (+0700) 2020-04-25 07-53-37 [Info] (onStateChanged) onStateChanged (default): 2
25.04.20 14:53:38 (+0700) 2020-04-25 07-53-38 [Info] (Stream) Chunk: 0 0 0 0 1 59 0
25.04.20 14:53:39 (+0700) 2020-04-25 07-53-39 [Info] (Stream) Chunk: 0 0 0 0 20 59 0
25.04.20 14:53:40 (+0700) 2020-04-25 07-53-40 [Info] (Stream) Chunk: 0 0 0 0 39 59 0
25.04.20 14:53:41 (+0700) 2020-04-25 07-53-41 [Info] (Stream) Chunk: 0 0 0 0 57 60 0
25.04.20 14:53:42 (+0700) 2020-04-25 07-53-42 [Info] (Stream) Chunk: 0 0 0 0 77 60 0
25.04.20 14:53:43 (+0700) 2020-04-25 07-53-43 [Info] (Stream) Chunk: 0 0 0 0 98 89 0
25.04.20 14:53:43 (+0700) 2020-04-25 07-53-43 [Info] (onResync) onResync (default): 136 ms
25.04.20 14:53:44 (+0700) 2020-04-25 07-53-44 [Info] (Stream) Chunk: -2054 0 0 0 120 60 0
25.04.20 14:53:44 (+0700) 2020-04-25 07-53-44 [Info] (Stream) pMiniBuffer->full() && (abs(pMiniBuffer->mean()) > 50): -205373
25.04.20 14:53:45 (+0700) 2020-04-25 07-53-45 [Info] (Stream) Chunk: 0 0 0 0 5 60 0
25.04.20 14:53:46 (+0700) 2020-04-25 07-53-46 [Info] (Stream) Chunk: 0 0 0 0 27 89 0
25.04.20 14:53:47 (+0700) 2020-04-25 07-53-47 [Info] (Stream) Chunk: 1 0 0 0 50 60 0
25.04.20 14:53:48 (+0700) 2020-04-25 07-53-48 [Info] (Stream) Chunk: 7 0 0 0 70 60 0
25.04.20 14:53:49 (+0700) 2020-04-25 07-53-49 [Info] (Stream) Chunk: 0 0 0 0 92 89 0
25.04.20 14:53:50 (+0700) 2020-04-25 07-53-50 [Info] (Stream) Chunk: 0 0 0 0 115 60 0
Hello
Thanksfor the reply.
I have run diagnostic healthcheck a couple of times and no undervoltage events occurred.
I did read through the Github issue you suggested but the error I’m receiving doesn’t match also my issue occurs with both bluetooth and Spotify Connect.
Note I am using an rpi 2 so there is no onboard bluetooth or wifi. I’m already using USB dongles for both. To isolate issue I have removed wifi dongle and am using onboard LAN but still same problem with audio.
Is there a way to adjust the Minibuffer in my error logs as I would like to try an adjust settings to see if it makes a difference
Hi there – if I understand this right, you’re asking about buffer settings in the Snapcast server or client. Is that correct?
If so, it looks like snapserver.conf has a “buffer” setting (https://github.com/badaix/snapcast/blob/master/server/etc/snapserver.conf#L136-L137), which would be worth testing. The corresponding file in Balena Sound is at https://github.com/balenalabs/balena-sound/blob/master/snapcast-server/snapserver.conf.
All the best,
Hugh
Hi @chris_farley, thanks for trying out balenaSound! Project maintainer here, so let me chime in with some more context.
When using multi-room your device can basically be in two different “modes”: client or master. There is only one snapcast master server at a time really, which is the one streaming audio to all other client connected devices. When we developed the multi-room feature a few months ago we created this Device support matrix where you can see what works on what device type.
Raspberry Pi Zeros for example can’t really work as servers due to resource constraints (it’s too much stuff for the little board). I imagine you might be seeing the same problem with the Pi 2. As you can see, we haven’t really tested the Pi 2 as a multi-room server (mainly because I don’t have one).
There is a quick way of confirming this, you can disable multi-room and see if the audio playback is fine after that. Multi room can be disabled by creating a device variable called DISABLE_MULTI_ROOM, more on that here: https://github.com/balenalabs/balena-sound#multi-room
Before you do test that however, if you are up to it I’d like to gather some logs from your device to actually figure out if this is the case and if there is something that can be done. If so, can you please grant support access to the device and send me your device UUID privately via DM?
Hi
DM with UUID sent. Let me know if I need to do anything further before I try your suggestion of adding device variable.
Many thanks
Chris
So I added the Disable Multiroom device variable which completely killed all services Dead. Device would not recover even after hard reboot.
So I reflashed SD then added ‘Disable Multiroom’ variable and this does improve dropouts Bluetooth however Spotify Connect and Airplay no longer work.
In Spotify balena device is no longer visible in list of available devices. Airplay balena device is visible but will not connect. Both Airplay and Spotify Connect services are running, only Fleet-Server and snapcast client and snapcast server which are ended by adding the Disable Multiroom variable. Removing the device variable enabled Spotify Connect and Airplay to work but sound dropouts return
Should Spotify and airplay work with Device Multiroom variable disabled?
Many thanks
Chris
Hello, Spotify and Airplay should work with multiroom disabled yes. It’s very strange that it initially killed your services, might be an indication that something else is at fault here.
Did you notice any errors on the spotify or airplay service logs or was it just failing silently? I’ll try to get ahold of a Pi 2 to make sure we haven’t broken functionality for it.
Unfortunately they failed silently nothing from either service present in the logs.
Out of interest have you pushed any updates out in the last 24 hours?
The reason I ask is I have reapplied the Disable Multiroom variable today and Spotify Connect is now broadcasting again. I will do so more testing tomorrow but want to establish if any changes have been made.
Many thanks
@chris_farley no we’ve not made any updates to balenaSound in the past 24 hours, but they wouldn’t apply to your device unless you were to push them or deploy again anyhow. The ‘releases’ tab in the dashboard is quite useful for this as you can track when deploys were made and which devices are running which version. 
Let us know you you get on with further testing.