OpenAL source state polling during zero‑downtime migration

Goal

We want to replace the audio stream of a running OpenAL source without stopping playback, using alSourceQueueBuffers and alSourceUnqueueBuffers while the source continues to play.

Uncertainty

The OpenAL spec states that after calling alSourcePlay the source state should transition from AL_INITIAL to AL_PLAYING. In practice, some implementations return AL_INITIAL for a short period, and the transition timing is not defined. This makes it unclear how quickly we can begin queuing new buffers and whether we need to poll the state or rely on a timeout.

Unresolved Decision

Should we poll alGetSourcei in a tight loop, sleep for a brief interval, or use a callback mechanism if available? Additionally, we need to know if changing AL_GAIN or AL_PITCH while the source is playing can introduce clicks or if the implementation guarantees smooth transitions.

Questions

1. Does alGetSourcei reliably return AL_PLAYING immediately after alSourcePlay across all major OpenAL implementations?
2. What polling interval is recommended to balance responsiveness and CPU usage when monitoring AL_SOURCE_STATE during a migration?
3. Are there documented implementation bugs where AL_SOURCE_STATE remains AL_INITIAL until a context flush, and how can we detect or mitigate this?