-
-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
librespot takes 97% CPU, music replay stutters #504
Comments
I just starting hitting this today, too. It was working fine before so I think it was caused by an OS or raspotify update.
Before the errors start happening, It's reproducible on two different Raspberry PIs (a v1 and a Zero), both of which are using HifiBerry DACs. |
Maybe worth to mention, i'am running |
It looks as though Spotify itself might be having issues? The desktop app will not load properly for me (the desktop app is basically a glorified browser frame) If that is the case a slow and/or unstable connection (on their side) could be starving the audio backend. So far Spotify Connect seems unaffected for me at least. Lets give it a little time to see if this is just an Spotify problem.
I also have a HifiBerry DAC (DAC+ ZERO) which is currently on my Pi 4. My PiZero + the DAC+ ZERO is my go to setup for testing when I hack on |
Spotify-Electron app at Linux works for me (region Germany) as usual. |
The files are downloaded and saved to disk or stored in memory but the player will start playback as soon as enough audio is there to play. It doesn't wait for the file to be completely downloaded. In theory if Spotify could not at least keep up with the audio in realtime it would starve the audio backend. |
I had the same issue with |
Which version did you downgrade too? |
The only difference between 0.31.6 and 0.31.5 is this commit. Which actually saves a tiny amount of CPU usage during dynamic volume normalization compared 0.31.5. Nothing related to the audio backend or network code changed between those versions. I have been streaming all day with the same hardware/software combo as others who are affected. I still think that it's a network issue on Spotify's side as I can't reproduce. |
I confirm, on a fresh install on a PI-zero : |
I downgraded to I'm not sure about the Spotify backend issue, Spotify app was working fine on desktop and mobile when I experienced the issue. |
Same problem here. Edit: does this help?
|
Yes it tells me it's a network issue just like I suspected. |
That release corresponds to this commit. Again nothing really changed much from 0.31.4 - 0.31.6. Where (as far as country or geographical area) are people being affected by this? I am located in central Iowa in the Midwestern United States and can not reproduce this. |
I am located in mid Europa, yesterday once it lasts about half an hour, since it starts to stutter. Are you working with cache? If so, whats your configuration? Maybe this will prevent the occurrence 🤔 |
I'm in Western Europe |
We know, every effect is possible. But this doesn't look like network issue for me
|
I found this post because I am having similar issues on a RPi Zero with Spotify + Adafruit speaker bonnet. After a while (15- 20 mins) music starts stuttering. HTOP shows 98% of the CPU (around 20% before the problem). Pausing Spotify doesn't fix the problem. |
I'm in Norway. Today I didn't have any dropouts, but I have updated the system with the latest packages, so maybe it was just some weird coincidence? |
I'm just guessing. I have no way to fix it because I can't reproduce it and so far all I've got is a lot of "Me to". Sorry, there's not much I can do about it but wait to see if it affects me or see it passes with time.
My Raspberry Pi 4 doesn't run off of a micro sd card. Raspberry Pi OS is installed on a Kingston 120GB A400 SATA 3 2.5 SSD in a Inateck 2.5 Hard Drive Enclosure (with UASP), so there's plenty of room and I'm not really worried about wearing it out since it's a proper SSD and it only cost like $25. I generally run it with 16G of audio file cache on the Pi 4. The cache locations are already taken care of and can't be changed without changing the systemd unit file. All you have to do to duplicate my config as far as caching is edit Comment out: And uncomment and follow the instructions above it: My Pi Zero runs off a micro sd card. I do not cache to disk on the Pi Zero because I don't want to prematurely kill my micro sd card. When I'm hacking around on my desktop sometimes I run with a cache sometimes not depends on what bits in
It's hard to say? at this point it really could be anything? |
If anyone would like to help debug you can stop the Raspotify service ( Look for a section that looks like:
|
I would like to help debuging but I need some guidance, I don't understand much about RPi's, but I can follow instructions.
|
Interestingly, I tried running I re-ran via systemd, and it died again after 20 minutes with the same errors as before (repeating every couple seconds):
|
Today I stopped again raspotify and run librespot -v and I have been playing music for more than an hour without any issues. |
To be clear, everyone is running the latest version of Raspberry Pi OS, the version based on Debian Bullseye and not the legacy version based on Debian Buster right? Because Buster is not supported. |
Hi, I also have the same issue. I am using a Raspberry PI Zero with Raspberry Pi OS Lite (Bullseye). The behavior is the same like ssombra's. I stopped raspotify and run librespot and could play music for hours. |
Yes, latest version (lite) |
@ssombra those are some really low buffer numbers (sub 100ms). Have you configured your buffer size in But I digress... Between what you, @tobiasmcnulty and @Seal1984 report it sounds like it's got something to do with the combination of Pi Zero + systemd? I can't reproduce on my Pi4 so I guess it's time to bust out the Pi Zero. |
@JasonLG1979 I am not sure. I don't really understand much about those configurations, I just installed a fresh Raspberry Pi OS version. Then I installed raspotify using the installation script. Finally, as I am using the Adafruit speaker bonnet, I run the script provided by them, which I think is the script that sets the buffer up (I am guessing here): which according to the website, is a copy of the script used by PhatDAC. |
Hi guys, this issue becomes a hobby Shame on me, was running Buster. Did a distro upgrade few weeks ago. Thought I had upgraded to Bullseye, but was still one version back. But today I really did upgrade to Bullseye But anyway - the problem didn't disapear.
My hardware setup:
|
Thank you, I will try those values along with the volume normalization suggestion. |
@JasonLG1979 I was wondering if the issue might be happening on the Pi4, simply not apparent due to its more powerful CPU... Do you have any thoughts on the errors I posted above ( I also confirmed:
This presumably would line up with your theory about the new dynamic limiter, since it looks like the only code changes between those versions were in Thanks for your help debugging this (and more broadly for maintaining this project)! |
Oh yes, can reproduce this As soon CPU hits 100% |
The calculation is done on the fly as the song plays. |
Spotify provides ReplayGain info and we then use that to normalize the track by adjusting the gain and then running it though a dynamic limiter. |
I get the same error. This explains the error. basically the Pi Zero can't keep the buffer full.
Even if the limiter is not engaged samples are still processed to change their gain at the rate of 88,200 samples a sec (44,100 stereo) and over all the sample pipeline is very inefficient in general in |
Just lo let you know that after the changes (volume normalization and buffer) everything is working good, almost 2 hours without issues. Thanks @JasonLG1979 for your support ont his issue |
I long for the day when Pi Zero v2's aren't basically unobtainium. I'd love to get my hands on one. I'd be willing to bet it could handle anything |
I have Bullseye on an old Raspberry B+, always had volume-normalization disabled because the processor has never been able to handle it properly, even with modest overclocking, and the cache has always been disabled to save the SD card. |
The Pi 1 and Zero have the same processor but I believe that the Zero has a higher stock clock though? I can overclock my Zero to about 1100Mhz before it gets unstable. The CPU on the Zero (and I would assume the 1?) is not thermally limited it's just that the processor physically can't run any faster than about 1100MHz. |
Thank you @JasonLG1979 ! Yesterday i was able to stream all day without any Trouble! #504 (comment) solved it for my old raspberry pi 2 B :) |
Both processors are Broadcom BCM2835, but the pi Zero runs at 1GHz vs 700MHz (800MHz with modest overclocking) for the B+. |
We might have to strike the Pi 1 off of the supported list then. |
The Pi 1 has been removed from the supported list. In other sad news the soon-ish to be merged |
Sad news indeed. The Zero was a good option in terms of budget and form. I hope it is fixable. |
If the Pi Zero v2 were not constantly sold out everywhere I would feel better about it since It's basically a drop-in replacement. But at this point it would be kinda shitty to say "Well just buy a Pi Zero v2." since you really can't. |
Although this is not a documented setting for raspotify, setting the normalisation method to basic as follows seems to resolve the issue for me without having to give up normalisation.
|
How / where do you set this mode? During build time or as environment variable or parameter during runtime? |
https://github.com/dtcooper/raspotify/wiki/Configuration |
Thanks, I found it here: https://github.com/librespot-org/librespot/wiki/Options |
Librespot settings are clearly link to in the wiki. |
Sorry, @pejobo, I should have said it was a config setting. Glad you sorted it out. |
These settings come from dtcooper/raspotify#504 (comment)
Compatible OS
Latest Version
Due Diligence
What happened?
Since a few days music replay is starting to stutter after a few minutes working fine.
/usr/bin/libespot takes up to 97% CPU
Did a check with journalctl, there is an error writing to PCM
ALSA works fine, just testet with aplay as documented in log below
Relevant log output
The text was updated successfully, but these errors were encountered: