audio-dsp-review

Audio DSP Realtime Safety Review

The cardinal rule: If you don't know how long it will take, don't do it.

The audio callback has a hard deadline — typically 1–5ms per buffer. Miss it once and the user hears a glitch. The three categories of violations that cause this are: allocations, locking, and system calls — all of which can block for unbounded time.

Step 1 — Find the realtime context

Identify the audio callback and every function it calls (transitively). Common names: processBlock, process, render, getNextAudioBlock, audioDeviceIOCallback, AURenderCallback, JackProcessCallback, and the output-stream closure in cpal/JUCE/PortAudio.

Step 2 — Scan for violations

Memory allocations (allocator paths may lock, grow arenas, touch new pages, or run unbounded bookkeeping):

• new / delete / malloc / free / make_shared / make_unique
• std::string construction, concatenation, to_string()
• Container growth: vector::push_back without pre-reserve, map::operator[] on new keys, unordered_map::insert, deque::push_back
• std::function with non-trivial captures (may allocate), throwing exceptions

Locking (priority inversion: the low-priority UI thread holds the lock your audio thread needs):

• std::mutex, lock_guard, unique_lock, scoped_lock, shared_mutex
• pthread_mutex_lock, pthread_rwlock_*
• condition_variable::wait(), future::get(), semaphore::acquire()
• std::mutex::try_lock() + RAII wrapper — try_lock() itself is non-blocking, but the RAII destructor calls unlock(), which does a system call to wake waiting threads. Not realtime-safe. Same for std::unique_lock(mtx, std::try_to_lock).
• Spinlocks without exponential back-off on the non-audio thread — busy-wait burns CPU, causes starvation under contention, and drains battery on mobile devices. If you must use a spinlock: audio thread calls only try_lock() + fallback; non-audio thread uses progressive back-off (spin → _mm_pause() → batched pauses → occasional yield).