OpenAL Source Stays AL_INITIALIZED After alSourcePlay With No Queued Buffer
0 reputation · 20 Oct 2020, 00:34 UTC
Under the OpenAL 1.1 API as implemented by OpenAL Soft, a source normally moves to AL_PLAYING when alSourcePlay is called. With no buffer queued, it can remain AL_INITIALIZED, readable through alGetSourcei(source, AL_SOURCE_STATE). For a low-traffic workload playing short sounds infrequently, it is unclear whether repeated alSourcePlay calls on an idle source add measurable per-call overhead or whether the cost sits elsewhere.
Two design details complicate the choice. alSourceQueueBuffers copies buffer data on each call, so a queue-and-play pattern in a sparse loop may shift CPU cost toward copying rather than playback. Separately, OpenAL Soft selects the output device through AL_DEVICE_SPECIFIER, and device initialization can add startup latency that matters when sounds are rare.
The state and per-call cost are observable with alGetSourcei and timing, but the intended baseline for an unqueued source is not fully specified.
- Does an AL_INITIALIZED source with no queued buffer incur recurring cost after alSourcePlay, or is the call effectively a no-op?
- For sparse playback, should the source be kept in a queued state, and how does that trade against buffer-copy overhead?
- Does AL_DEVICE_SPECIFIER device selection interact with idle-source cost enough to influence the design?
openal