Persistent ALCcontext with source pool versus ephemeral context per playback burst for low‑traffic OpenAL workloads

Answer

For most desktop or embedded workloads where bursts occur more than once per minute, keep a single persistent ALCcontext with a small pool of 2–4 sources. This eliminates the 5–50 ms context‑creation latency while keeping CPU and memory usage well below 1 % and allowing the audio device to remain in a low‑power state.

If your application runs on a battery‑powered device and bursts are rarer than once per minute, or if you must guarantee that the device can enter the OS’s idle power state, then destroy the context after each burst and recreate it on demand. The additional 5–20 ms startup cost is usually acceptable for user‑perceived latency, and the idle drain can be reduced by up to 30 %.

Why It Matters

• Latency: Persistent contexts avoid the 5–50 ms creation window that every burst would otherwise pay.
• Idle cost: A persistent context keeps the audio device active, preventing the OS from putting the audio stack to sleep. On laptops and mobile phones this can raise battery usage.
• Device loss: PulseAudio and similar servers may close idle sessions after a few seconds; destroying the context forces a clean re‑initialisation, reducing the risk of silent gaps.
• Backend variance: WASAPI caches device handles across contexts, so creation is <5 ms; PulseAudio can take 30–50 ms but closes after ~10 s of silence; OpenSL ES has a longer init (~70 ms) but keeps the device active once initialised.

Implementation Steps

1. Measure your target backend: Time alcCreateContext/alcMakeContextCurrent 100 times to get an average latency.
2. Decide on source pool size: 2–4 sources are usually enough for bursty workloads; larger pools increase idle memory but reduce the chance of needing to generate a source on the fly.
3. Persist the context: Keep the ALCcontext and device handle alive for the lifetime of the application, or until the burst frequency drops below the threshold you defined.
4. Handle device loss: Register for ALC_ALC_DEVICE_LOST events and recreate the context if the device is reset.
5. For mobile: If you choose the transient path, destroy the context immediately after the last source finishes: alcMakeContextCurrent(NULL); alcDestroyContext(ctx);.
6. Verify power impact: Measure battery drain with the context kept alive vs. destroyed after each burst on your target device.

What to Check Next

To fine‑tune the recommendation, we need to know your burst frequency and the acceptable latency threshold for your application. If bursts occur more than once per minute and you can tolerate ~10 ms startup latency, the persistent strategy is preferable. If bursts are less frequent and you must keep battery consumption to a minimum, the transient strategy wins.