Spotify - tiny gaps/pauses in the sound

@Loki welcome! Thanks for chipping in with your log outputs. I’ll leave the balenaSound details to @tmigone but with regards to setting the AUDIO_LOG_LEVEL environment variable to DEBUG you can follow the instructions here to set this env var on your device via the Balena Cloud dashboard.

Not seeing much in the logs during playback either. But here is what that looks like…

MR client only, on custom build that includes only the audio and multiroom-client containers. RPi Zero W with DAC+.

MR server while playing. RPi 4B

MR client while playing, RPi 4B.

Let me know if you need me to change log settingis or grab them directly off the devices. These log snips are just downloaded form balenaCloud.

Cheers!
Mark-

Here is the log:

Thanks everyone! For new folks that might be reading this, keep’em coming :smiley:

@portomarcos in your case, you were streaming via bluetooth to a device with Multi Room disabled, is that correct?

Actually, I switched from Airplay to Bluetooth and back to Airplay in that session.
Multiroom was disabled.
I can provide logs for separate blocs if it helps.

No, that’s fine. Thanks again!

If it helps, I had these same issues and have discovered a workaround.

I’m running a rpi4 as the server and two rpi3s as clients.

From the Balena dashboard I hit the stop button on the following services on the rpi3s (I wasn’t using them since the 4 is the server): Multiroom server, airplay, Spotify, bluetooth, uPNP. I also turned off Bluetooth on the rpi4, as Airplay and Spotify connect are enough for my uses.

Since then I have not had the “too many under runs” error with the corresponding pops/glitches. I do very rarely have a “ALSA failed to get chunk” error but I suspect that is non related and may be caused by a networking error (old router).

Hi Brett, yes that would work as you are likely lightening the load on the device. You can also remove the services from the docker-compose.yml file if you don’t need the services, that way they don’t even show up!

Regarding the issue, I’ve made great progress, it will probably take a couple days but i’ll get a new version out soon that should eliminate most if not all instances of this problem.

1 Like

@speedy, @mcgee, @garciasteve, @superapan, @koyaanisqatsi, @portomarcos

I just opened PR #356 which contains changes that should fix or at the very least drastically improve the audio stuttering related to the message:

Too many underruns, increasing latency to xxx.00 ms

Changes made are the following:

  1. Significantly reduce the CPU and I/O usage which were the biggest contributors to this problem, specially for multiroom scenarios. This probably improves performance on lesser devices too (Pi0 for instance). In my case, running multiroom on Pi 4’s would always start with the initial latency value of 200msec and increase it all the way up to 270msec, but with this update it has never complained and is also smoother.

  2. Introduced a new environment variable SOUND_INPUT_LATENCY that allows you to directly set the latency that’s causing the problem. If you are still having problems you can increase the base latency with this variable. You should let it run for a while until it stabilises and use whatever end value you found. This way the audio server won’t go from 200msec all the way up to whatever value in 5msec increments but rather start at the end value. Downside is that you are adding a latency to the pipeline ofc.

As you can see, 1) is the actual fix while 2) is just an additional workaround. My hope is, and the limited testing I’ve done is in line with it, that you shouldn’t need to set the SOUND_INPUT_LATENCY at all.

If you are interested in more details about this you can check the following:

Now the big ask :smiley: I’d love it if you could try it and let me know how it goes! You’ll need to deploy the application using the balena CLI or use this handy dandy DWB I created just for this purpose:

deploy button

Thanks!

1 Like

Hi Tomas,

I burned the image using betcher and started up my Pi 3. It showed up in my cloud, as expected, but I don’t see that it ever started downloading. It’s just sitting in the cloud, with no services showing in the usual place in the bottom of the device summary screen.

I rebooted and that didn’t help.

Not sure what I missed…

Steve

Hi @garciasteve, what’s the status of the device? Also, can you check for the supervisor logs ? journalctl -f -a -u resin-supervisor --no-pager

Thank you, @tmigone! Looking forward to seeing how this improves things.

I got the new code up and running last night, from building the branch (didn’t use DWB because I have some customizations I wanted to keep). Will blast it all day today and see how it holds up.

Immediate notes:

  • There is some settle time for the first several minutes after deployment or boot-up, where even the RPi 4Bs may glitch.
  • Possibly my own environment, but I had to reboot all of the devices after deploying the new builds, in order for things to finally settle.
  • I had to shut down logs and VPN in balenaCloud for the Zero Ws to run at a usable level of stability, and they still get regular issues. (I’m still verifying whether this is WiFi related.)

Cheers!
Mark-

Status is “Online”

root@3bdb65e:~# journalctl -f -a -u resin-supervisor --no-pager
– Logs begin at Tue 2020-11-24 07:00:00 UTC. –
Nov 24 18:22:05 3bdb65e resin-supervisor[1811]: [debug] Container log timestamp flush complete
Nov 24 18:24:09 3bdb65e resin-supervisor[1811]: [api] GET /v1/healthy 200 - 7.214 ms
Nov 24 18:29:10 3bdb65e resin-supervisor[1811]: [api] GET /v1/healthy 200 - 5.131 ms
Nov 24 18:32:05 3bdb65e resin-supervisor[1811]: [debug] Attempting container log timestamp flush…
Nov 24 18:32:05 3bdb65e resin-supervisor[1811]: [debug] Container log timestamp flush complete
Nov 24 18:34:11 3bdb65e resin-supervisor[1811]: [api] GET /v1/healthy 200 - 8.346 ms
Nov 24 18:39:12 3bdb65e resin-supervisor[1811]: [api] GET /v1/healthy 200 - 5.592 ms
Nov 24 18:42:05 3bdb65e resin-supervisor[1811]: [debug] Attempting container log timestamp flush…
Nov 24 18:42:05 3bdb65e resin-supervisor[1811]: [debug] Container log timestamp flush complete
Nov 24 18:44:13 3bdb65e resin-supervisor[1811]: [api] GET /v1/healthy 200 - 6.819 ms

Hi Steve,

Thanks for the update. Looks like it’s running properly. Good tips on tweaks to improve performance on the Pi Zero W.

John

So, after playing most of the day, I didn’t notice any gaps or skips on my RPi 4Bs. The Zero Ws have some skipping that looks like it could be my WiFi.

A weird thing just happened. I hadn’t been playing music for a couple hours, and when I started a new song, the latency to output was about 25 seconds. It’s playing fine, but has a 25 second delay, which is pretty odd.

But no sonic playback issues detected throughout the day.

EDIT: The 25 second thing worked itself out without me hearing it.

Cheers!
Mark-

It is not running properly. It is not running at all. Yes, some code is executing and the unit is online, but balenaSound never downloaded as it was supposed to do after the unit came online.

Has anyone checked that the DWB that Tomas kindly provided does not have some flaw? Has anyone successfully switched to Tomas’ new release via the DWB?

Hi Steve,
I just tested the DWB button that Tomas provided above and it did not build for me. (I’ll let him know.) I did however download the file it points to: https://github.com/balenalabs/balena-sound/archive/294-snapcast-improvements.tar.gz - unzipped that, and was able to build it successfully using the CLI.

Hi Alan,
Good to know. Thanks.
I’m interested in trying Tomas’ new version, but being new at this I could use a “how to” on building via the CLI. If you could point me to directions, I’m happy to try it out.
Thanks again.
Steve

Hey Steve, download the tarball mention above and then extract the files. On my Linux machine I do that like so: tar -xf file.tar.gz. Then the build part prefers to using the balena deploy command to push this project to the cloud builders which will allow your device to download and run these new images. Just go into the newly extracted folder where the source code is and then run balena deploy <app-name>. Check out https://www.balena.io/docs/reference/balena-cli/#deploy-appname-image which has some more info on using the CLI to deploy new releases and also check out https://www.balena.io/docs/learn/deploy/deployment/ which has a good overview on deployments.

If you need more help let us know!