[GH-ISSUE #115] Tracks sometimes stutter a bit on first playback #75

Closed
opened 2026-02-28 14:25:08 +03:00 by kerem · 6 comments
Owner

Originally created by @aykevl on GitHub (Oct 5, 2024).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/115

This issue is easiest to hear with the following track:
https://open.spotify.com/album/2dVSmVK9W05Mnmqgmg3SMX (track: "The Sun in Your Heart")
Pressing the same track in the album again triggers the issue again.

When you start playing the song, you can hear a short stutter at the beginning.
I assume it happens on many other tracks, but since most start with silence or ramp up volume it's less audible.

I tested on both my main system (Asahi Linux, over USB audio) and on a Raspberry Pi 3 (analog jack). I also tried with the PulseAudio patches in #86 but the same issue is present there (so it doesn't seem like a problem with the ALSA driver).

Originally created by @aykevl on GitHub (Oct 5, 2024). Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/115 This issue is easiest to hear with the following track: https://open.spotify.com/album/2dVSmVK9W05Mnmqgmg3SMX (track: "The Sun in Your Heart") Pressing the same track in the album again triggers the issue again. When you start playing the song, you can hear a short stutter at the beginning. I assume it happens on many other tracks, but since most start with silence or ramp up volume it's less audible. I tested on both my main system (Asahi Linux, over USB audio) and on a Raspberry Pi 3 (analog jack). I also tried with the PulseAudio patches in #86 but the same issue is present there (so it doesn't seem like a problem with the ALSA driver).
kerem 2026-02-28 14:25:08 +03:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@aykevl commented on GitHub (Oct 5, 2024):

Probably unrelated, but when debugging this issue I've seen messages like the following:

WARN[0121] failed handling dealer request                error="failed loading current track (load context): failed creating stream for spotify:track:1AGZTrBoRotCtDKYGZ70UA: failed retrieving audio key: failed retrieving aes key with code 2"

I suspect I got rate limited for a bit. It might be worth implementing some sort of cache :)

<!-- gh-comment-id:2395026418 --> @aykevl commented on GitHub (Oct 5, 2024): Probably unrelated, but when debugging this issue I've seen messages like the following: ``` WARN[0121] failed handling dealer request error="failed loading current track (load context): failed creating stream for spotify:track:1AGZTrBoRotCtDKYGZ70UA: failed retrieving audio key: failed retrieving aes key with code 2" ``` I suspect I got rate limited for a bit. It might be worth implementing some sort of cache :)
Author
Owner

@aykevl commented on GitHub (Oct 5, 2024):

I did some unrelated experimenting with a Go native Ogg Vorbis decoder (see https://github.com/devgianlu/go-librespot/compare/master...aykevl:go-librespot:vorbis-purego) and to my surprise the issue is not present there. This suggests that the bug is somewhere in the Vorbis decoder.

<!-- gh-comment-id:2395087818 --> @aykevl commented on GitHub (Oct 5, 2024): I did some unrelated experimenting with a Go native Ogg Vorbis decoder (see https://github.com/devgianlu/go-librespot/compare/master...aykevl:go-librespot:vorbis-purego) and to my surprise the issue is not present there. This suggests that the bug is somewhere in the Vorbis decoder.
Author
Owner

@devgianlu commented on GitHub (Oct 5, 2024):

Seems strange to have a bug in the Vorbis decoder, perhaps it is a bug in how it is used? I see the native Go decoder also removes a bunch of code, but not sure if it would be appropriate to switch.

<!-- gh-comment-id:2395120582 --> @devgianlu commented on GitHub (Oct 5, 2024): Seems strange to have a bug in the Vorbis decoder, perhaps it is a bug in how it is used? I see the native Go decoder also removes a bunch of code, but not sure if it would be appropriate to switch.
Author
Owner

@aykevl commented on GitHub (Oct 5, 2024):

Seems strange to have a bug in the Vorbis decoder, perhaps it is a bug in how it is used?

Yeah that's what I mean, sorry. Maybe the first part gets accidentally decoded and played twice? Or it seeks to the start after starting to play or something?
Interestingly changing the ALSA buffer size has no effect.

I see the native Go decoder also removes a bunch of code, but not sure if it would be appropriate to switch.

It mainly removes seek indices. The new code does support seek, but feels somewhat slow. (This could also be due to general sluggishness of Spotify Connect, need to test more carefully). That's one reason I haven't made a PR yet. The fact that it also seems to fix the stuttering is just luck.

<!-- gh-comment-id:2395125385 --> @aykevl commented on GitHub (Oct 5, 2024): > Seems strange to have a bug in the Vorbis decoder, perhaps it is a bug in how it is used? Yeah that's what I mean, sorry. Maybe the first part gets accidentally decoded and played twice? Or it seeks to the start after starting to play or something? Interestingly changing the ALSA buffer size has no effect. > I see the native Go decoder also removes a bunch of code, but not sure if it would be appropriate to switch. It mainly removes seek indices. The new code does support seek, but feels somewhat slow. (This could also be due to general sluggishness of Spotify Connect, need to test more carefully). That's one reason I haven't made a PR yet. The fact that it also seems to fix the stuttering is just luck.
Author
Owner

@devgianlu commented on GitHub (Oct 5, 2024):

Yeah that's what I mean, sorry. Maybe the first part gets accidentally decoded and played twice? Or it seeks to the start after starting to play or something?

It may be putting frames in the internal buffer between the start of decoding and the initial seek. Just guessing, haven't reviewed the code.

It mainly removes seek indices. The new code does support seek, but feels somewhat slow.

Yeah I see you removed the seek table stuff (GetSeekPosition, etc...). That I have reversed from the official Spotify client, including all the strange calculations and magic numbers.

<!-- gh-comment-id:2395133557 --> @devgianlu commented on GitHub (Oct 5, 2024): > Yeah that's what I mean, sorry. Maybe the first part gets accidentally decoded and played twice? Or it seeks to the start after starting to play or something? It may be putting frames in the internal buffer between the start of decoding and the initial seek. Just guessing, haven't reviewed the code. > It mainly removes seek indices. The new code does support seek, but feels somewhat slow. Yeah I see you removed the seek table stuff (`GetSeekPosition`, etc...). That I have reversed from the official Spotify client, including all the strange calculations and magic numbers.
Author
Owner

@aykevl commented on GitHub (Oct 5, 2024):

Yeah I see you removed the seek table stuff (GetSeekPosition, etc...). That I have reversed from the official Spotify client, including all the strange calculations and magic numbers.

That certainly sounds like something we'd want to keep!

<!-- gh-comment-id:2395205795 --> @aykevl commented on GitHub (Oct 5, 2024): > Yeah I see you removed the seek table stuff (`GetSeekPosition`, etc...). That I have reversed from the official Spotify client, including all the strange calculations and magic numbers. That certainly sounds like something we'd want to keep!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/go-librespot#75
No description provided.