mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #317] [Rodio][Windows] Playback stuttering #210
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#210
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 @ashthespy on GitHub (Mar 22, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/317
Testing with my win10 box - I seem to have some stuttering issues when I start multitasking a bit.
@willstott101 Any debug/profiling options I can turn on to get more info?
@willstott101 commented on GitHub (Mar 22, 2019):
Hm, not that I know of. You could try increasing the buffer size? Maybe we should expose that as a cmdline arg for all backends
@willstott101 commented on GitHub (Mar 25, 2019):
Hm, I have noticed some lack of playback smoothness when using a debug build on my laptop
@willstott101 commented on GitHub (Mar 25, 2019):
I wonder if there's a buffer beyond librespot which we can increase, reducing the buffer size that we're explicitly creating.
@willstott101 commented on GitHub (Mar 25, 2019):
As far as I can tell from the CPAL source and Windows docs is that CPAL uses the minimum buffer size.
I've stuck an
info!()which prints when number of chunks in the Rodio Sink's queue is < 6 and I'll see if I notice any audio problems again, and if that's been printing out when I do.If that doesn't provide evidence that it's Librespot-side I might have a go at specifying a buffer size for the Windows client in CPAL.
@ashthespy commented on GitHub (Mar 26, 2019):
I had some improvements increasing the buffer size on my debug build. However, shouldn't there be a method to set something akin to alsa's
start_threshold? That should allow for some flexibility, instead of exposing another parameter to the end user?EDIT: Doubling the buffer still has stuttering issues when I hit >40% RAM useage on my machine.
@sashahilton00 commented on GitHub (Apr 17, 2019):
any further troubleshooting on this? Have tried to reproduce in a throttled VM, but no luck yet...
@willstott101 commented on GitHub (May 25, 2019):
Not really had any luck with this. As mentioned here https://github.com/librespot-org/librespot/pull/314#issuecomment-495916619 my CPAL-direct backends still struggle under heavy load.
@willstott101 commented on GitHub (Sep 8, 2019):
I think the requirement of a second thread might be part of the problem here. As I don't think that thread is given higher priority (though I haven't confirmed).
There's some movement towards improving the CPAL API in https://github.com/RustAudio/cpal/issues/278 so I propose helping/waiting for those changes before trying again.
EDIT: Some rudimentary CPAL based backends here...
https://github.com/willstott101/librespot/tree/cpal-backend2 - uses mpsc::sync_sender
https://github.com/willstott101/librespot/tree/cpal-backend-ringbuf - uses ringbuf crate and thread::sleep
@ashthespy commented on GitHub (Nov 6, 2019):
@willstott101 was playing around again, and hit this again. It is also aggravated when using a bluetooth audio device. Will try running a profiler and take a deeper look.
@willstott101 commented on GitHub (Nov 6, 2019):
I've updated the cpal-backend2 branch above to use the newer cpal API, I suspect this won't help much but it'd be good if you could try that branch out.
@strafe commented on GitHub (Nov 21, 2020):
@ashthespy is there any chance the
rodioversion could be bumped? There's a crackling issue on macOS that was likely fixed in the latest release - https://github.com/RustAudio/rodio/pull/320@willstott101 commented on GitHub (Dec 6, 2020):
@strafe Does my branch above using latest rodio help?
@Johannesd3 commented on GitHub (Jan 27, 2021):
I created a simple crate that does not use librespot_playback and feeds the vorbis audio of a single track directly into rodio: https://github.com/Johannesd3/librespot-player. Does this increase performance? At least I had no issues on Windows. Then maybe it's a matter of implementation.
@strafe commented on GitHub (Mar 6, 2021):
@willstott101 spotifyd finally bumped librespot to
0.1.5and cut a new release a couple days ago. Sadly Rodio still crackles on most songs. It's really unfortunate since it makes any combination of spotify-tui and spotifyd pretty much unusable on macOS.@Johannesd3 commented on GitHub (Mar 21, 2021):
If I understand everything correctly, there are to problems:
The first is our rodio backend. Currently, it allocates a new buffer every time a new packet arrives. This could become faster using a spsc queue/ring buffer.
Secondly, cpal and alsa don't really fit (though it is not related to Windows): Cpal is callback-based while alsa uses an internal ring buffer. Therefore, cpal spawns an extra thread just to copy the data from our buffer to alsa's buffer.
The best solution imo is to make alsa the default backend on linux again.
@roderickvd commented on GitHub (Mar 21, 2021):
Oh yes. Still hunting down why Rodio on Alsa is broken in so many cases. While I appreciate the "black-box" approach of librespot sinking into a "one size fits all" backend, it's just not there yet.
@roderickvd commented on GitHub (Jun 14, 2021):
Cannot reproduce anymore on macOS and no further replies. There have been a lot of updates to
librespot,cpal, and Rodio since this was reported. Feel free to reopen if this is still an issue on the latest version.@strafe commented on GitHub (Jun 16, 2021):
This seems to be working in the latest version of
ncspot.spotify-tui(spotifyd) is probably still broken since they're depending on an older version of librespot for now. Thanks everyone who worked on this!