Hi, when I play spotify through balenaSound on my RPi4 I hear tiny gaps/pauses in the sound approximately every 10-20 seconds. Looking in the log they’re matching these warnings:
W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 340.00 ms
and the number of ms is always increasing.
Output is the built-in audio jack.
Is there a way to fix it? Thank you.
Hi
So we have a troubleshooting guide here - https://sound.balenalabs.io/docs/support/#troubleshooting
And it has some stuff that we can try before diving deeper (in the guide it’s for bluetooth, but these are some good to check things regardless)
If this still doesn’t resolve, I think there’s a realtime flag for pulseaudio we could try - I am looking at this issue and solution here - https://raspberrypi.stackexchange.com/questions/9795/pulseaudio-sink-stuttering which feels similar to yours
Actually, on further inspection, we are using the realtime flag - see https://github.com/balenablocks/audio/blob/a865d02e7be13a66000cb7eb95c5f63389d54991/pulseaudio/daemon.conf
Can I ask you what version of balenaSound are you using? Can you make sure you are on the latest one?
Thank you for looking into it. I’ve tried to disable multi room (byt setting SOUND_MODE to STANDALONE) and looks like it helped. I will try it again with multiroom enabled soon just to confirm it was the reason.
By the way - I’m using latest version of balenaSound development build (balenaOS 2.58.6+rev1) and I’m also using certified power supply (https://www.raspberrypi.org/products/type-c-power-supply/).
Thanks for the additional info. Let us know if you’re able to confirm that enabling multiroom again brings the symptoms back.
One thing you may want to check: the version of balenaOS you have reports CPU and temperature information back to the dashboard. It would be worth seeing if either are particularly high; high temperatures in particular can lead to cpu throttling, which may exacerbate this problem. Another way to check this would be to run device checks from the Diagnostics tab on the dashboard, as we check for CPU throttling there. If you see high temperatures or CPU throttling, pointing a fan at your Pi would be one way of testing this.
Let us know how it goes for you!
All the best,
Hugh
So I’ve tested it again with multiroom enabled and the issue was there! Switched back to STANDALONE and all is fine. CPU, temp, memory all green.
Hi there, thanks for the report, I’ll notify the maintainer. The other thing I am curious about is the type of SD Card being used, if it’s perhaps not quick enough to keep up with the read/write. We recommend Sandisk Extreme Pro, with a UHS 1 or A1 rating.
Hi All, long time experimenter first time poster.
Can confirm I had similar issues today when testing this out, often stuttering with pulse audio having to increase the latency.
([pulseaudio] module-loopback.c: Too many underruns, increasing latency)
Have also tried converting to standalone and has resolved the issue so far with about 35 minutes of constant playback testing.
Tested with RPi3, 16GB factory class 10 card, Samsung Evo card with same results.
Genuine RPi PSU used to ensure enough amps.
Happy to supply more information if it is of any use.
Hope this helps, and keep up the good work!
Hello, balenaSound maintainer here. Switching to STANDALONE mode shouldn’t have this type of impact with regards to the underruns, at least in theory. Since we have two data points indicating the contrary in this thread I think I need to go back and take a deeper look to see what’s going on.
There is an ongoing GitHub issue where this was initially reported (see here). I’ll keep the discussion and results of my investigation over there, so feel free to drop by or subscribe to the issue if you are interested in it’s resolution.
Hi Tomas,
Just as in FYI, you’ll find a third data point (though with RPi3+) here.
Steve
I have the same issue, I have two devices RPi 3. I have disabled every feature plugin, besides spotify-connect on the multiroom-master Pi (the other is running as multiroom-client), and pi3-disable-bt on both. I did this thinking it’d be good to run as lean as possible.
Only the Pi running as multiroom-master reports these underruns, the client does not.
I have no idea what it means, and I probably don’t help much with this post.
12.11.20 15:41:26 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 245.00 ms
12.11.20 15:41:36 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 250.00 ms
12.11.20 15:42:06 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 255.00 ms
12.11.20 15:42:36 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 260.00 ms
12.11.20 15:42:56 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 265.00 ms
12.11.20 15:43:36 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 270.00 ms
12.11.20 15:44:06 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 275.00 ms
12.11.20 15:44:46 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 280.00 msHi Calle, thanks for sharing this. Every bit of information helps! I’ll see if I can prioritize this and get to the bottom in the next couple days/weeks.
For anyone else finding this thread, use https://github.com/balenalabs/balena-sound/issues/294 to keep track of progress.
I have noticed that there are periodic glitches that affect all speakers at the same time. In my case, only my RPi Zero W devices have individual glitches, which I sort of understand the source of. But the fleet will have tiny glitches on a regular cycle that seems to fluctuate between about 15 seconds to a minute or so. The glitches are usually a very brief time jump, and then a few seconds later a very brief time delay, as if something shifted and then returned to normal.
I have the same issue as reported above — and it’s driving me nuts 
In my case though, the problem is way worse when using the spotify service. Playing via Airplay or Bluetooth renders with fewer gaps/crackling episodes.
One other interesting thing: if I mess around with the volume control in Spotify, I notice the crackling sound appearing right after. I’ve tried it with the Spotify player on both my Android phone and my Mac.
Also tested using different speakers and different cables.
Tried, with no success:
Using:
Thanks Marcos
As Tomas mentioned, we would be grateful if you could follow up on the github issues here https://github.com/balenalabs/balena-sound/issues/294
Cheers
@speedy, @mcgee, @garciasteve, @superapan, @koyaanisqatsi, @portomarcos
Hi guys, I’m looking for some help in order to troubleshoot this issue.
If you can help me out here I could use some logs with extra verbosity. You’ll need to set environment variable AUDIO_LOG_LEVEL to DEBUG and then share with me the logs. You’ll know it’s on DEBUG mode because logs will show the following:
19.11.20 18:34:42 (-0300) audio --- Audio ---
19.11.20 18:34:42 (-0300) audio Starting audio service with settings:
19.11.20 18:34:42 (-0300) audio - Pulse log level: DEBUG
What I’m looking for in the logs is instances of this error occurring, so make sure you get a few:
W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 320.00 ms
Feel free to upload logs here, using pastebin or you can also use this GitHub issue.
Thanks!
Hi Tomas,
Is the following of interest? Or are you looking specifically for “Too many underruns, increasing latency to 320.00 ms”
19.11.20 14:19:06 (-0800) audio D: [pulseaudio] module-loopback.c: Underrun detected, counter incremented to 2
Steve
Hi
Brand new user here.
Fresh install of balena sound on rpi3 model B.
I haven’t tested anything but first thing I see in logs is that.
19.11.20 23:23:16 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 255.00 ms
19.11.20 23:23:56 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 260.00 ms
19.11.20 23:24:16 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 265.00 ms
19.11.20 23:24:36 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 270.00 ms
19.11.20 23:24:56 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 275.00 ms
19.11.20 23:25:06 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 280.00 ms
19.11.20 23:25:46 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 285.00 ms
19.11.20 23:26:06 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 290.00 ms
19.11.20 23:26:11 (+0100) multiroom-server 2020-11-19 22-26-11 [Info] (do_read) next read < 0 (balenaSound): -1.982 ms
19.11.20 23:26:26 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 295.00 ms
19.11.20 23:27:06 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 300.00 ms
19.11.20 23:27:46 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 305.00 ms
19.11.20 23:28:06 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 310.00 ms
19.11.20 23:28:26 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 315.00 ms
19.11.20 23:29:16 (+0100) multiroom-server 2020-11-19 22-29-16 [Info] (do_read) next read < 0 (balenaSound): -30.582 ms
19.11.20 23:29:16 (+0100) multiroom-server 2020-11-19 22-29-16 [Info] (do_read) next read < 0 (balenaSound): -12.065 ms
19.11.20 23:29:16 (+0100) audio W: [pulseaudio] module-loopback.c: Too many underruns, increasing latency to 320.00 ms
19.11.20 23:29:18 (+0100) multiroom-server 2020-11-19 22-29-18 [Info] (onResync) onResync (balenaSound): 79 ms
19.11.20 23:29:19 (+0100) multiroom-server 2020-11-19 22-29-19 [Info] (do_read) next read < 0 (balenaSound): -16.951 ms
19.11.20 23:29:19 (+0100) multiroom-client 2020-11-19 22-29-19 [Info] (Stream) pMiniBuffer->full() && (abs(pMiniBuffer->mean()) > 50): -106758
19.11.20 23:30:23 (+0100) multiroom-server 2020-11-19 22-30-23 [Info] (do_read) next read < 0 (balenaSound): -1.207 ms
19.11.20 23:31:38 (+0100) multiroom-server 2020-11-19 22-31-38 [Info] (do_read) next read < 0 (balenaSound): -0.683 ms
19.11.20 23:32:59 (+0100) multiroom-server 2020-11-19 22-32-59 [Info] (onResync) onResync (balenaSound): 97 ms
19.11.20 23:33:00 (+0100) multiroom-client 2020-11-19 22-33-00 [Info] (Stream) pMiniBuffer->full() && (abs(pMiniBuffer->mean()) > 50): -178289
19.11.20 23:35:25 (+0100) multiroom-server 202
Just in case it could help.
@tmigone : I haven’t found how to turn AUDIO_LOG_LEVEL to DEBUG but if you drive me i’ll be glad to help.
I’m installing it on another identical device it’s currently updating, i’ll be back here once it’s finished.
Hi @tmigone,
Here are three logs, one froma RPi 4B, which is my mr-server, one from a MR client-only RPi Zero W that is running nothing but the audio and mr-client containers (a custom build). And the third is from a RPi 4B, running as a regular mr-client, using env vars to set the mode. I have not yet played any music. This is just what was logged shortly after setting the logging to DEBUG. I’ll get logs while playing later tonight.
MR-server:
Custom MR-client:
Regular MR-client:
Cheers!
Mark-