Spotify connect playback issues/lag

[Razorfoot]

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.

[rage2dev]

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.

[Razorfoot]

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

[rage2dev]

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! :)

[kingosticks]

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

[ashthespy]

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.

[kingosticks]

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.

[dowhiletrue]

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

[StopMotionCuber]

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