[GH-ISSUE #253] Spotify connect playback issues/lag

kerem commented

2026-02-27 19:29:13 +03:00

Owner

Originally created by @Razorfoot on GitHub (Oct 2, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/253

Hi,

Im currently using an Rpi3b+ and a Suptronics X5000 DAC with some JBL 308P MkII powered 8" two-way studio monitors, connected via TRS 1/4" to RCA to the DAC (not ideal but im waiting for the ALLO Katana DAC to be re-released)

However I have an issue with Spotify connect taking 10-20 seconds to play a song every time I change song from any device I use, i.e. Desktop PC, Android phone, Android tablet. Skipping forward and back will intermittently play song on demand but more often not.

This seems to be via anything I browse on Spotify or from my playlists. Local USB drive stored audio works fine.

Removing the DAC and using the pi by itself results in the same issue. I have tried the latest Volumio OS and Moode OS

Any help would be appreciated as im fairly new to the Rpi scene.

Originally created by @Razorfoot on GitHub (Oct 2, 2018). Original GitHub issue: https://github.com/librespot-org/librespot/issues/253 Hi, Im currently using an Rpi3b+ and a Suptronics X5000 DAC with some JBL 308P MkII powered 8" two-way studio monitors, connected via TRS 1/4" to RCA to the DAC (not ideal but im waiting for the ALLO Katana DAC to be re-released) However I have an issue with Spotify connect taking 10-20 seconds to play a song every time I change song from any device I use, i.e. Desktop PC, Android phone, Android tablet. Skipping forward and back will intermittently play song on demand but more often not. This seems to be via anything I browse on Spotify or from my playlists. Local USB drive stored audio works fine. Removing the DAC and using the pi by itself results in the same issue. I have tried the latest Volumio OS and Moode OS Any help would be appreciated as im fairly new to the Rpi scene.

kerem

2026-02-27 19:29:13 +03:00

closed this issue
added the
help wanted

question
labels

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@rage2dev commented on GitHub (Oct 3, 2018):

I guess you using alsa as backend? Had the same issue, looks like librespot is waiting for the song to fully download and than starting playback.

I worked around it by using jackd with "jackaudio"-backend.

@rage2dev commented on GitHub (Oct 3, 2018): I guess you using alsa as backend? Had the same issue, looks like librespot is waiting for the song to fully download and than starting playback. I worked around it by using jackd with "jackaudio"-backend.

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@Razorfoot commented on GitHub (Oct 3, 2018):

And how would I go about setting that up? Sorry I'm new to this :)

@Razorfoot commented on GitHub (Oct 3, 2018): And how would I go about setting that up? Sorry I'm new to this :)

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@rage2dev commented on GitHub (Oct 4, 2018):

Build librespot:
cargo build --release --features jackaudio-backend
Install jackd1 or jackd2 (jackd2 seems to work better on newer kernel versions).
Use qjackctl to connect the librespot jacks, to your soundcard or if terminal only : jack_lsp (list all jacks) and jack_connect {from_jack} {to_jack}

But we still should fix the alsa bug! :)

@rage2dev commented on GitHub (Oct 4, 2018): Build librespot: cargo build --release --features jackaudio-backend Install jackd1 or jackd2 (jackd2 seems to work better on newer kernel versions). Use qjackctl to connect the librespot jacks, to your soundcard or if terminal only : jack_lsp (list all jacks) and jack_connect {from_jack} {to_jack} But we still should fix the alsa bug! :)

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@kingosticks commented on GitHub (Oct 4, 2018):

It would be interesting if that helps since the code doesn't suggest there would be any difference in the loading behaviour.

@kingosticks commented on GitHub (Oct 4, 2018): It would be interesting if that helps since the code doesn't suggest there would be any difference in the loading behaviour.

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@ashthespy commented on GitHub (Oct 4, 2018):

I highly doubt it as well - as per player.rs the file is fetched either from the cache or from the servers and only then is the sink opened.

@ashthespy commented on GitHub (Oct 4, 2018): I highly doubt it as well - as per [`player.rs`](https://github.com/librespot-org/librespot/blob/master/playback/src/player.rs#L405) the file is fetched either from the cache or from the servers and only then is the sink opened.

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@kingosticks commented on GitHub (Oct 7, 2018):

I had a closer look at how this all works and the player will open the sink and start writing data to output as soon as the first 128K chunk of data is received. The remaining chunks will be fetched in the background while the audio plays. You can see this yourself if you run with debug logging:

$ RUST_LOG=librespot=debug ./target/debug/librespot <YOUR OPTIONS>
DEBUG:librespot_playback::player: command=Load(SpotifyId(u128!(307046987122905149274613336200758987899)), true, 0)
INFO:librespot_playback::player: Loading track "We Flood Empty Lakes" with Spotify URI "spotify:track:71SOzhIRtSz25YjcdoWO8P"
DEBUG:librespot_audio::fetch: Downloading file 7283c15eb582109b54be56bb189c629e8e476a10
DEBUG:librespot_playback::player: Normalisation Data: NormalisationData { track_gain_db: -9.580002, track_peak: 1.1605701, album_gain_db: -9.760002, album_peak: 1.1613277 }
DEBUG:librespot_playback::player: Applied normalisation factor: 0.3318944
INFO:librespot_playback::player: Track "We Flood Empty Lakes" loaded  <-- playback starts here
DEBUG:librespot_audio::fetch: File 7283c15eb582109b54be56bb189c629e8e476a10 complete <-- some time later

This is most obvious when you load a long track.

If there is a delay in audio starting you might be able to see where it is with the above log output. Maybe a delay in opening the device (why?) or the hardware is waiting until ALSA's ring buffer is sufficiently full before starting. librespot's ALSA implementation is very simple and maybe doesn't work well with some sound devices. It might be helpful to dump your ALSA parameters. For my onboard soundcard I get:

$ cat /proc/asound/PCH/pcm0p/sub0/*w_params 
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 8192
buffer_size: 16384
tstamp_mode: ENABLE
period_step: 1
avail_min: 15503
start_threshold: 18446744073709551615
stop_threshold: 4611686018427387904
silence_threshold: 0
silence_size: 0
boundary: 4611686018427387904

Jack is supposed to be a lot easier to interface with so I guess whatever the issue is is handled better.

@kingosticks commented on GitHub (Oct 7, 2018): I had a closer look at how this all works and the player will open the sink and start writing data to output *as soon as the first 128K chunk of data is received*. The remaining chunks will be fetched in the background while the audio plays. You can see this yourself if you run with debug logging: ``` $ RUST_LOG=librespot=debug ./target/debug/librespot <YOUR OPTIONS> DEBUG:librespot_playback::player: command=Load(SpotifyId(u128!(307046987122905149274613336200758987899)), true, 0) INFO:librespot_playback::player: Loading track "We Flood Empty Lakes" with Spotify URI "spotify:track:71SOzhIRtSz25YjcdoWO8P" DEBUG:librespot_audio::fetch: Downloading file 7283c15eb582109b54be56bb189c629e8e476a10 DEBUG:librespot_playback::player: Normalisation Data: NormalisationData { track_gain_db: -9.580002, track_peak: 1.1605701, album_gain_db: -9.760002, album_peak: 1.1613277 } DEBUG:librespot_playback::player: Applied normalisation factor: 0.3318944 INFO:librespot_playback::player: Track "We Flood Empty Lakes" loaded <-- playback starts here DEBUG:librespot_audio::fetch: File 7283c15eb582109b54be56bb189c629e8e476a10 complete <-- some time later ``` This is most obvious when you load a long track. If there is a delay in audio starting you might be able to see where it is with the above log output. Maybe a delay in opening the device (why?) or the hardware is waiting until ALSA's ring buffer is sufficiently full before starting. librespot's ALSA implementation is very simple and maybe doesn't work well with some sound devices. It might be helpful to dump your ALSA parameters. For my onboard soundcard I get: ``` $ cat /proc/asound/PCH/pcm0p/sub0/*w_params access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 8192 buffer_size: 16384 tstamp_mode: ENABLE period_step: 1 avail_min: 15503 start_threshold: 18446744073709551615 stop_threshold: 4611686018427387904 silence_threshold: 0 silence_size: 0 boundary: 4611686018427387904 ``` Jack is supposed to be a lot easier to interface with so I guess whatever the issue is is handled better.

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@dowhiletrue commented on GitHub (Jan 20, 2019):

I'm facing similar issues. Sometimes it takes up to 10 seconds after "Track ... loaded" till the music starts to play. The delay might be longer when skipping track, while it is loaded. The time on my controller device starts to count but no sound. The CPU load is about 20% while loading.

cat /proc/asound/card0/pcm0p/sub0/*w_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5504
buffer_size: 22048
tstamp_mode: NONE
period_step: 1
avail_min: 5504
start_threshold: 22016
stop_threshold: 22048
silence_threshold: 0
silence_size: 0
boundary: 1444937728

@dowhiletrue commented on GitHub (Jan 20, 2019): I'm facing similar issues. Sometimes it takes up to 10 seconds after "Track ... loaded" till the music starts to play. The delay might be longer when skipping track, while it is loaded. The time on my controller device starts to count but no sound. The CPU load is about 20% while loading. ``` cat /proc/asound/card0/pcm0p/sub0/*w_params access: RW_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 5504 buffer_size: 22048 tstamp_mode: NONE period_step: 1 avail_min: 5504 start_threshold: 22016 stop_threshold: 22048 silence_threshold: 0 silence_size: 0 boundary: 1444937728 ```

kerem commented

2026-02-27 19:29:14 +03:00

Author

Owner

@StopMotionCuber commented on GitHub (Mar 19, 2019):

Can you maybe check with the current master again as #297 got merged?
This should improve the behaviour

@StopMotionCuber commented on GitHub (Mar 19, 2019): Can you maybe check with the current master again as #297 got merged? This should improve the behaviour

Rows
Columns

[GH-ISSUE #253] Spotify connect playback issues/lag #172