Repository navigation
alsa: refactor and enhance worker loop - #1122
Merged
Merged
Conversation
POLLERR from snd_pcm_poll_descriptors_revents() signals an xrun but was being returned as a BackendSpecificError, causing the poll loop to spin indefinitely. It now falls through to avail(), which returns EPIPE and triggers xrun recovery. Capture streams also require an explicit snd_pcm_start() after snd_pcm_prepare() to re-enter SND_PCM_STATE_RUNNING; without it the stream stalled in PREPARED and poll() timed out repeatedly. POLLHUP/POLLNVAL now stop the stream with StreamError::DeviceNotAvailable instead of looping and poll() returning 0 (timeout/spurious) is now treated as Continue rather than an error. Fixes #730
Member
Author
|
The Copilot review seems a valid concern and a pre-existing fragility. I'll think about how to address it. |
TriggerReceiver is now wrapped in Arc and a clone is stored in Stream alongside the sender. Worker threads take their own Arc clone, so dropping the worker no longer closes the read end of the pipe. This means wakeup() in Stream::drop() always writes to an open pipe, even when the worker exited early due to a device error, eliminating the SIGPIPE that would otherwise be raised.
roderickvd
changed the title
Contributor
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Member
Author
|
This PR has grown quite a bit beyond its original #730 scope so I updated the PR title and text. |
crmne
added a commit
to crmne/zapfast
that referenced
this pull request
Oct 15, 2026
) cpal 0.17's ALSA backend turns an underrun that leaves the device in its XRUN state into "`alsa::poll()` returned POLLERR" and polls again without calling prepare(), so the error comes straight back for as long as the stream lives, and rodio's default error callback prints each one to stderr: tens of thousands of lines a second and a core held until restart. cpal 0.18 recovers it (RustAudio/cpal#1122). Every output stream now reports to an audio::Health instead of rodio's default callback. It logs the first error and then a count at most every ten seconds; dozens of errors in a second, or a device that went away, mark the stream failed and slow its audio thread until the owner drops it. Voice playback reopens the device and carries on from where it was (a second failure within ten seconds pauses it there), a video plays on silently and reopens its sound after a wait that doubles, a call tone reopens the same way, a notification sound gives up, and the call speaker reopens as it does for a stall. rodio has no way to set a microphone's error callback, so microphones keep its default; their streams already close once an error leaves them without samples.
crmne
added a commit
to crmne/zapfast
that referenced
this pull request
Oct 15, 2026
cpal 0.17's ALSA backend reported an underrun as POLLERR in a loop without ever recovering the device; cpal 0.18 recovers it (RustAudio/cpal#1122) and ends a stream whose device went away. rodio's master carries cpal 0.18.2 and RustAudio/rodio#833, which no release has together, so the crmne/rodio fork's `zapfast` branch is now master plus MicrophoneBuilder::with_error_callback, sent upstream. audio::Health takes cpal 0.18's errors: a device that went away, an invalidated stream or a missing host fail it at once, and a rerouted stream or a refused real-time promotion is logged without counting towards a flood.
intellq
added a commit
to intellq/zapfast
that referenced
this pull request
Oct 16, 2026
…rmne#507) cpal 0.17's ALSA backend turns an underrun that leaves the device in its XRUN state into "`alsa::poll()` returned POLLERR" and polls again without calling prepare(), so the error comes straight back for as long as the stream lives, and rodio's default error callback prints each one to stderr: tens of thousands of lines a second and a core held until restart. cpal 0.18 recovers it (RustAudio/cpal#1122). Every output stream now reports to an audio::Health instead of rodio's default callback. It logs the first error and then a count at most every ten seconds; dozens of errors in a second, or a device that went away, mark the stream failed and slow its audio thread until the owner drops it. Voice playback reopens the device and carries on from where it was (a second failure within ten seconds pauses it there), a video plays on silently and reopens its sound after a wait that doubles, a call tone reopens the same way, a notification sound gives up, and the call speaker reopens as it does for a stall. rodio has no way to set a microphone's error callback, so microphones keep its default; their streams already close once an error leaves them without samples. (cherry picked from commit 29f2358)
intellq
added a commit
to intellq/zapfast
that referenced
this pull request
Oct 16, 2026
cpal 0.17's ALSA backend reported an underrun as POLLERR in a loop without ever recovering the device; cpal 0.18 recovers it (RustAudio/cpal#1122) and ends a stream whose device went away. rodio's master carries cpal 0.18.2 and RustAudio/rodio#833, which no release has together, so the crmne/rodio fork's `zapfast` branch is now master plus MicrophoneBuilder::with_error_callback, sent upstream. audio::Health takes cpal 0.18's errors: a device that went away, an invalidated stream or a missing host fail it at once, and a rerouted stream or a refused real-time promotion is logged without counting towards a flood. (cherry picked from commit bb19cfe)
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
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.
Fixes
Capture overrun recovery (ALSA: invalid handling of capture overruns #730):
snd_pcm_start()was not called aftersnd_pcm_prepare()when recovering a capture stream from an underrun.POLLERRmishandled as error:POLLERRfromsnd_pcm_poll_descriptors_revents()signals a pending underrun. It was being returned asBackendSpecificError, causing spurious error callbacks and skipping recovery.poll()timeout reported as error:poll()returning 0 (timeout or spurious wakeup) was fired as aBackendSpecificErroron every timeout .Device disconnection looping:
POLLHUP/POLLNVALwere not handled. The worker now stops withStreamError::DeviceNotAvailableon device removal.SIGPIPEon early worker exit: If the worker exited early (e.g. onDeviceNotAvailable) beforeStream::drop()calledwakeup(), the write to the self-pipe's closed read end raisedSIGPIPEEINTRpanic in self-pipe paths:write()/read()on the self-pipe could return-1withEINTRon signal delivery, causingassert_eq!(ret, 8)to panic.Added
Suspend/resume support:
ESTRPIPEfromavail()orwritei()(system suspend) is now handled.Changed
The internal
PollDescriptorsFlowenum andpoll_descriptors_and_prepare_bufferfunction havebeen refactored for simplicity and likeness to
Ready/Pendingvocabulary.Fixes #730