mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 00:05:55 +03:00
[GH-ISSUE #532] Stuttery or choppy audio on Raspberry Pi #341
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#341
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lumaxis on GitHub (Oct 19, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/532
For a few weeks now, I've been observing occasional stuttering or choppy audio when playing music via my Raspberry Pi Zero W whereas it used to fork flawlessly in the beginning.
I recently started running another service on the Pi but the timeline doesn't really align with when I started experiencing these issues. I monitored
topfor a little bit and also didn't see any correlation between CPU usage and the choppiness.Is there anything I can do to debug or understand why this might be happening? Appreciate any help!
@JasonLG1979 commented on GitHub (Oct 25, 2020):
I also run librespot (via raspotify) on a Raspberry Pi Zero W. I use my Pi Zero as a Spotify Connect appliance so I've stripped it down to the bare minimum even then though I can get CPU spikes of 60 - 70% while librespot is fetching a song.
In general stuttering or choppy audio is usually caused by a buffer underrun. Off the top of my head the easiest things to try are:
Don't resample librespot. ALSA's default sampling rate is 48000 so if you're going to the "default" input, audio from librespot will be upsampled to 48000 (it's 16 bit 41000).
Increase the buffer size from 0.5 sec to 1 sec.
Drop the Niceness of librespot so it has a higher priority.
Drop the quality from 320 to 160. 160 for some reason uses a little bit less CPU on my Pi.
If the other service is audio then stop that service before you start playback with librespot with a hook script.
Disable frequency scaling on the Pi Zero. Unless you run your Pi Zero in an oven heat isn't a concern even running it at 1GHz 24/7. I just checked the temp on mine that runs 24/7 without a heatsink in an unventilated case and it's 49.8'C.
@roderickvd commented on GitHub (Mar 12, 2021):
Also make sure you've compiled with
--release.@lumaxis commented on GitHub (Mar 12, 2021):
I have since moved from a Raspberry Pi Zero W to a 4 (for other reasons), where I have not seen this anymore. I'm fine to close this as long as nobody else still has an interest to track this issue.
@Emgalai commented on GitHub (Apr 19, 2021):
I installed Librespot service addon on top of LibreELEC 9.2.6 on Raspberry Pi 1 B+ and the audio is so stuttery it is completely unusable. It is not just occassional stuttering, it is constant stuttering. I don't know how to test the options suggested by JasonLG1979 on LibreELEC (I was able to set the niceness level, but not the rest).
I have IQaudio DAC+ on the Pi. The audio stutters the same if I use IQaudio or the HDMI output.
EDIT:
If I run librespot from commandline (so that it does not run as an Kodi addon), it runs perfectly, even if I use bitrate 320. So it seems a problem of the Kodi addon and not librespot.
EDIT2:
My workaround was to disable the addon and add /storage/.config/autostart.sh script with the contents:
librespot -b 320 -n LibreELEC &@JasonLG1979 commented on GitHub (Apr 19, 2021):
@Emgalai
A Raspberry Pi 1 B+ is basically the same thing as a Pi Zero. Do you actually use the UI bits and if so is Kodi even usable on a Pi 1? Audio is kinda heavy. For the most part any sort of upsampling is a no go on a Pi 1/Zero if you plan on doing absolutely anything else on it. If I had to guess kodi is doing some resampling. Running librespot via the command line is probably bypassing that resampling.
@Emgalai commented on GitHub (Apr 20, 2021):
I have used Kodi on RPi 1 B+ since it was released in 2014 and most of my video files work without any problems. For music I have used mpd on the same RPi, without any problems. I have even run some surround audio files through mpd and downmixed them to stereo without any problems (My mpd setup has the audio output set to have two channels). Maybe having the IQaudio DAC on the RPi is helping for that, I don't know.
@JasonLG1979 commented on GitHub (Apr 20, 2021):
@Emgalai I don't mean down mixing I mean resampling specifically upsampling. Like converting from 44.1 kHz to 48 kHz on the fly during playback.
@Emgalai commented on GitHub (Apr 22, 2021):
I tried limiting sample rate of Kodi to 44.1 kHz, in case the Kodi addon uses the Kodi settings, but it didn't help. How could I know if resampling is done or not?
@JasonLG1979 commented on GitHub (Apr 22, 2021):
While playing something with librespot
cat /proc/asound/card*/pcm*p/sub*/hw_paramsshould tell you what your DAC is actually receiving. Ifrate:is not44100audio is being resampled.@JasonLG1979 commented on GitHub (Apr 22, 2021):
period_size:andbuffer_size:are also relevant to make sure the buffer is large enough for smooth playback.@JasonLG1979 commented on GitHub (Apr 22, 2021):
Drop outs are generally the result of the CPU not being able to keep up. Either because the buffer is to small or because it can't handle whatever processing is being done to the audio, or a combination of both.
@roderickvd commented on GitHub (May 24, 2021):
Closing this as this seems to be an issue in
Kodidownstream.@Mysonemo commented on GitHub (Feb 12, 2024):
I've found the solution here by disabling the normalization.
https://github.com/dtcooper/raspotify/issues/504