OpenAL Source Stays AL_INITIALIZED After alSourcePlay With No Queued Buffer

Question

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?

Tasadduq Burney · Answer

AnswerWhen alSourcePlay is invoked on a source that has no buffers queued, the source remains in the AL_INITIALIZED state and the call behaves as a no‑op. The only work done is a lightweight state check, so there is no recurring CPU cost tied to playback.Confirmed factsAccording to the OpenAL 1.1 specification, alSourcePlay begins playback only if at least one buffer is queued; otherwise the source stays AL_INITIALIZED and the call is effectively a no‑op.In OpenAL Soft the per‑call overhead consists of a mutex lock, an atomic read of the source state, and a branch that skips buffer processing; measurable time appears only when the call actually triggers mixing or device wake‑up.Likely explanationBecause no buffer is queued, the mixer never receives data to process. The driver therefore returns immediately after verifying the source state, incurring only the cost of the state‑check path. No mixing, no device wake‑up, and no buffer copy occurs.Steps to verifyCreate an OpenAL context and a source, leave it with zero buffers queued.In a tight loop (e.g., 200 000 iterations) call alSourcePlay and measure elapsed CPU time with a high‑resolution timer.Run a second loop that only calls alGetSourcei(source, AL_SOURCE_STATE) to isolate the pure state‑check cost.The difference between the two measurements gives the overhead of the idle alSourcePlay call.Recommendation for sparse playbackFor low‑traffic workloads, keeping the source idle (no queued buffer) avoids the copy cost of alSourceQueueBuffers. The per‑play overhead is tiny and usually negligible compared to other work. If you prefer to keep the mixer active, queue a single‑sample silence buffer; the copy cost of that buffer is typically far smaller than the play‑call overhead.Missing diagnostic detailWhich OpenAL implementation (OpenAL Soft, Creative Labs, Apple OpenAL, etc.) are you targeting, as error handling for alSourcePlay with no buffers can differ between libraries?

OpenAL Source Stays AL_INITIALIZED After alSourcePlay With No Queued Buffer

1 answer

Answer

Confirmed facts

Likely explanation

Steps to verify

Recommendation for sparse playback

Missing diagnostic detail

Your perspective belongs here.

0 question comments