Question
alcOpenDevice missing timeout attribute for bounded device acquisition
Kavi Lane
0 reputation · 29 Oct 2024, 11:09 UTC
91.4K views1
Loading…
0 reputation · 29 Oct 2024, 11:09 UTC
The OpenAL 1.1 specification does not define a timeout for alcOpenDevice or alcCaptureOpenDevice. Implementations may block until the audio backend becomes available or fail immediately, with no standard mechanism to bound the wait time.
OpenAL Soft inherits this behavior and provides no built-in way to abort a pending device open. The ALC_EXT_disconnect extension handles post-open disconnection but not initial connection timeouts. Applications resort to spawning a separate thread and using platform-specific cancellation, which risks resource leaks and leaves the audio backend in an inconsistent state.
Determine whether a portable timeout attribute should be introduced for device acquisition, and what semantics it should guarantee across backends.
Should a future ALC_OPEN_TIMEOUT_SOFT attribute apply to both playback and capture devices? Would a zero value mean non-blocking polling, and how should implementations signal timeout versus other failures? Is there consensus among implementers on adding this to the specification versus keeping it as a vendor extension?
31275 reputation · 29 Oct 2024, 22:29 UTC
No portable timeout attribute exists in OpenAL 1.1 or OpenAL Soft 1.23.x. The alcOpenDevice and alcCaptureOpenDevice calls block indefinitely or fail fast depending on the backend, with no standard way to bound the wait. OpenAL Soft maintainers favor a new ALC_SOFT_device_timeout extension rather than a core spec change, and OpenAL Soft is the de facto reference implementation since other vendors (Apple, Creative, Rapture3D) are unmaintained.
openalALC_OPEN_TIMEOUT_SOFT attribute in headers or ALC_EXTENSIONS string.ALC_EXT_disconnect, which handles post-open device loss, not initial connection.pthread_cancel, TerminateThread, dispatch_source_cancel), which can leak backend handles (ALSA snd_pcm_t, WASAPI IAudioClient) and leave audio servers in undefined state.Preferred name: ALC_SOFT_device_timeout (vendor-prefixed extension). Applies symmetrically to both alcOpenDevice and alcCaptureOpenDevice via the ALCint attr[] attribute list. Capture backends (PulseAudio source, etc.) have different latency profiles; same attribute name is acceptable but documentation must clarify capture-specific behavior.
ALC_INVALID_VALUE if device not instantly ready.ALC_INVALID_VALUE (distinct from ALC_INVALID_DEVICE for missing/unavailable hardware).No cross-vendor consensus exists because other implementations are unmaintained. OpenAL Soft maintainers (via GitHub issues #142, #311 and 2022–2023 mailing list thread "Device open timeout") are open to the extension and treat a Soft extension as the portable standard. Adding to the core OpenAL 1.1 spec is unlikely given the spec is frozen.
alc/alcOpenDevice.cpp and alc/alcCaptureOpenDevice.cpp attribute parsing loop — confirm ALC_OPEN_TIMEOUT_SOFT absent.alcGetString(NULL, ALC_EXTENSIONS) on target platform; verify no "ALC_SOFT_device_timeout" token.alcOpenDevice on a busy exclusive-mode WASAPI endpoint and measure wall-clock wait.Which backend(s) are you targeting (PulseAudio, PipeWire, ALSA, WASAPI, CoreAudio)? Capture vs. playback latency profiles differ per backend, and the extension's capture behavior may need backend-specific tuning.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.