Skip to content

ALSA: Avoid closing a device while the audio thread is still using it - #1707

Draft
emezeske wants to merge 1 commit into
juce-framework:developfrom
emezeske:pr/alsa-close-stuck-io-timeout
Draft

ALSA: Avoid closing a device while the audio thread is still using it#1707
emezeske wants to merge 1 commit into
juce-framework:developfrom
emezeske:pr/alsa-close-stuck-io-timeout

Conversation

@emezeske

@emezeske emezeske commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

Changing the audio device can crash inside libasound, on setups using a large buffer at a low sample rate. A 4096 frame buffer at 8kHz is a 512ms read, and that is all it takes.

ALSAThread::close() waits 400ms for the audio thread to exit and then, if the thread still has i/o in progress, calls closeNow() on the devices from the calling thread to unstick it. That frees the snd_pcm_t while the audio thread may still be inside snd_pcm_readi or snd_pcm_writei, and the blocked thread then crashes inside libasound. The 400ms is shorter than a single read or write on plenty of perfectly valid configurations, so merely changing devices on such a setup is enough to free the handle out from under a thread that is not stuck at all and is just part way through one normal read.

This waits for the base timeout plus one i/o period, capped so that closing a genuinely wedged device stays responsive. A typical buffer size and sample rate is unaffected and still waits 400ms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant