SDL Audio Double‑Buffer Rollback After Mid‑Play Sample Rate Change

Question

Goal: Verify that SDL_SetAudioDevice sample rate change while audio buffers are queued results in a clean rollback without audible glitches.

Constraint: The SDL API provides no transactional rollback for in‑flight buffers, and SDL 2.26’s sample rate handling may introduce race conditions when multiple audio devices are active.

Questions: 1) Does SDL guarantee atomic rollback of queued audio buffers after a sample rate change? 2) Under what conditions can concurrent device usage break rollback safety? 3) How can rollback behavior be verified programmatically without relying on undocumented source inspection?

Tasadduq Burney · Answer

Direct answer
SDL does not guarantee atomic rollback of queued audio buffers when the sample rate is changed while audio is playing. SDL has no transactional snapshot of the device queue, so pending frames can be delivered at the new rate, flushed, or reinterpreted by the backend. Audible clicks, pops, or underruns are possible.
Likely explanation versus confirmed facts
Likely explanation: Each open SDL audio device owns an independent queue. Changing the sample rate reconfigures the device or backend stream; SDL does not pause all in-flight buffers, stage them, and restore them on failure. Whether queued bytes are resampled, dropped, or converted depends on the backend, not on a universal SDL rollback contract.
Confirmed facts: SDL exposes no rollback API for queued audio. SDL_GetQueuedAudioSize reports pending bytes for one device. Multiple devices maintain separate queues. SDL 2.x sample-rate handling is backend-dependent and not transactional.
When concurrent device usage breaks rollback safety

One thread queues audio on a device while another thread changes that device's sample rate; the queue and format change race without an application-visible lock.
Two active devices share a backend mixer or hardware stream; a rate change on one device can stall or starve the other, producing underruns that resemble failed rollback.
Non-exclusive access lets other clients use the same backend device, making the format change asynchronous while buffers are still draining.

Verification steps

Call SDL_GetQueuedAudioSize(device) immediately before the sample-rate change and save the value.
Issue the rate change while a steady test tone is queued.
Poll SDL_GetAudioDeviceStatus(device) and SDL_GetQueuedAudioSize(device) for several hundred milliseconds. A clean result shows the device stays SDL_AUDIO_PLAYING, the queue drains smoothly at the new byte rate, and no backend underrun is reported.
If glitches appear, repeat with SDL_PauseAudioDevice(device, 1) before the change and SDL_PauseAudioDevice(device, 0) after, then compare. This isolates whether the glitch comes from the rate change itself or from concurrent queuing.

Missing diagnostic detail: which SDL audio backend and SDL version you are targeting. Backend behavior differs enough that pass/fail criteria should be adjusted per backend.

SDL Audio Double‑Buffer Rollback After Mid‑Play Sample Rate Change

1 answer

Direct answer

Likely explanation versus confirmed facts

When concurrent device usage breaks rollback safety

Verification steps

Your perspective belongs here.

1 question comment