OpenAL source state polling during zero‑downtime migration

Answer

Based on the OpenAL specification and observed behavior of the major implementations:

Confirmed facts

• The spec guarantees that after alSourcePlay the source will eventually reach AL_PLAYING, but does not require an immediate state change.
• OpenAL Soft (versions ≥ 1.18.2), Creative’s OpenAL, and Apple’s OpenAL all transition to AL_PLAYING once the first queued buffer has been processed; they may report AL_INITIAL for a few milliseconds before that.
• Changing AL_GAIN or AL_PITCH while a source is playing is applied smoothly in the mixing stage and does not produce clicks in software implementations; hardware‑accelerated drivers may show minor artifacts only for abrupt, large jumps.

Likely explanation & recommended steps

Because the transition time is implementation‑dependent and typically only a few milliseconds, a tight spin‑loop is unnecessary and wastes CPU. A short sleep between polls gives a good balance of responsiveness and low overhead.

1. Queue at least one buffer with alSourceQueueBuffers before calling alSourcePlay.
2. Call alSourcePlay.
3. Enter a polling loop that:
   1. Queries the state with alGetSourcei(source, AL_SOURCE_STATE, &state).
   2. Breaks when state == AL_PLAYING.
   3. Otherwise sleeps for 1–2 ms (e.g., std::this_thread::sleep_for(std::chrono::milliseconds(1)) on POSIX or Sleep(1) on Windows).
   4. Optionally also check AL_BUFFERS_PROCESSED > 0 as an additional confirmation that the source is consuming data.
4. After the source reports AL_PLAYING, you can safely call alSourceUnqueueBuffers to remove processed buffers and alSourceQueueBuffers to enqueue the new audio segment, ensuring the queue never empties.
5. If you need to adjust gain or pitch during the migration, apply the change immediately; for guaranteed click‑free transitions across all drivers, ramp the parameter over a few milliseconds (e.g., 5–10 ms) using small incremental steps.

Missing diagnostic detail

To refine the polling interval, please confirm which OpenAL implementation you are targeting (OpenAL Soft, Creative’s OpenAL, or Apple’s OpenAL). The exact latency of the AL_INITIAL → AL_PLAYING transition varies slightly between them, and knowing the implementation lets us recommend a more precise sleep duration if needed.