Keep audio device open across pause for instant play/pause#358
Draft
IsaiahWitzke wants to merge 1 commit into
Draft
Keep audio device open across pause for instant play/pause#358IsaiahWitzke wants to merge 1 commit into
IsaiahWitzke wants to merge 1 commit into
Conversation
librespot's PortAudio sink was torn down and reopened on every pause/resume, costing ~600ms on resume and ~900ms on pause on macOS (measured). RecoveringSink now keeps the device open across pause — librespot silences output by ceasing to feed packets, so tearing the stream down only forces a slow reopen — and treats a redundant start() as a no-op when the stream is already running. Only the first play after launch (or a post-error recovery) pays the device-open cost. Co-Authored-By: Oz <oz-agent@warp.dev>
Owner
|
manual testing with airpods would be much appreciated as i have neither a mac nor airpods |
Author
|
Sorry, meant to keep this as draft. This pr was vibecoded and I dont totally feel it fixed pausing latency 100%, although with my Bluetooth headset on mac it seems to pause faster. When I get a free moment I'll try to actually read the code and see what claude did here lol |
Owner
dont worry take your time |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
On macOS, native play/pause was noticeably (~500ms) slower than the Spotify desktop app. Instrumenting the transport pipeline showed the entire cost is librespot's PortAudio sink being torn down on pause and reopened on resume:
playdispatch: ~20µsPlayingevent: ~50µsstart()(PortAudio open + start): ~621msPaused(PortAudio stop/close): ~887msCoreAudio stream open/start/stop on macOS is inherently slow; the native app keeps its output device open permanently.
Fix
RecoveringSinknow keeps the underlying device open across pause:stop()no longer tears down the stream — librespot silences output by ceasing to feed packets, so the reopen was pure overhead.start()is a no-op when the stream is already running.with_innerclears thestartedflag when it drops the sink).Only the first play after launch (or a post-error recovery) pays the ~600ms device-open cost.
Results (measured, same session)
Testing
cargo build,cargo clippy -- -D warnings,cargo fmt --allclean (default features).cargo runbuild: pause silences audio, resume is instant, no glitches.Worth an extra check on Bluetooth (AirPods) and when switching to a decoded source (local/YouTube) while librespot is paused, since the device now stays open across pause.