-
Notifications
You must be signed in to change notification settings - Fork 630
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
Gapless play and next button #1213
Comments
I think https://github.com/librespot-org/librespot/blob/dev/playback/src/player.rs#L941 is the culprit but I don't know/remember why that
means we also need to stop the sink (and cause your pop). It might be possible to trigger |
Thanks for the pointer! Fun fact, if I wait to be near the end of the song (a little after the total time of the song minus
Maybe it would be a good idea regardless of my pop problem to have a "gapless" next for instance if one-day crossfading gets implemented. Cheers! |
As part of the shift to the HTTP CDN in For purpose of diagnostics, would you please try the latest 0.4 release and see what happens there?
I also think that's wrong. This already deals with this correctly: librespot/playback/src/player.rs Line 1773 in 054074c
librespot/playback/src/player.rs Line 1915 in 054074c
This preloading implementation, like the previous one, estimates when it should start downloading depending on network throughput and time left. So it's optimised to save bandwidth. I never gave it much thought, but I think you are right. In this age there is little reason not start the preload immediately. Though I'm no longer an active developer, from what I remember this should be easy to do. Of course, it's also entirely possible that a user selects a "next" song which is not next in queue. That could still trigger your pop. It never did for me, so I guess it depends on the output device. So an alternative to preloading immediately, covering this case as well, is to a quick mute-unmute cycle when manually changing songs. Somewhere in the area of 20 ms ramp time should work fine. This will take a little more effort to put in. |
Thanks for the detailed answer!
I ran into the issue with the following release on moodeaudio:
I believe that it would be nice to have a more eager strategy for preloading since users with bad bandwidth can disable gapless playing
The pop is clearly a design mistake from my DAC manufacturer, I totally can live with a pop if my playlist has ended, and I do not have autoplay 😆 |
Yeah in that case please try compiling from |
That's a nice idea. |
Oooh maybe I did not understand the proposal, it means that when clicking the next button librespot would mute / load the next song / unmute instead of recreating a sink?
Ok tried that, surprisingly easy on the raspberry. Got |
Status update: got librespot working fine using @kingosticks fix for #1179: On this version, the behavior is the same as I tried removing |
Another testing update: not only does the removal of |
Could you put in a PR to fix it for everyone? |
Of course! Here it is at #1223 |
Hi! First thanks a lot for this amazing project! I use it daily and I really love it!
I have a USB DAC that emits a small pop when an audio sink is released or created. Fortunately, librespot uses gapless playback and therefore when I listen to a song till the end and the next song is played, I do not get this pop.
However, I have remarked that when I click on the next button on my Spotify client, there is a pop that is emitted, meaning that in this case, there is no gapless play? I was not able to find out where to look in the code to be sure.
Would it be possible to enable gapless play also when clicking the next button? I imagine that the problem is that there is no preloaded data for the next song in this case, but would it be possible to keep the sink open?
Cheers!
The text was updated successfully, but these errors were encountered: