Repository navigation
Conversation
An alsa IO created in a match scrutinee lives across the match arms, and alsa allows only one IO per PCM. On duplex playback underrun (EPIPE/EAGAIN or Suspended), recover_duplex() -> begin_duplex_playback() therefore panicked with 'No hw_params call or additional IO objects allowed' when creating the prefill IO on the same PCM. Bind the readi/writei result first so the IO drops before recovery, in both duplex loops and the single-direction input/output loops.
This branch has not been deployed
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.
I was testing my DAW on linux now that cpal has duplex for alsa. Ran into a few buffer underruns and my audio engine crapped out. Found a panic in the callback thread:
I then used an ai agent to help me dig into this, as the error message wasn't quite helpful. It looks like it is a double borrow checked at runtime, and a solution is to let go of the borrow before entering the match arms so that calling recover_duplex isn't called while already holding the borrow on the io object.
It only hits on the match arms that call recover_duplex, so only in error conditions as far as I can tell.
I've confirmed that an underrun no longer panics -- I'm using Omarchy Quattro as my lab test.