au-review
Reviews AudioUnit v2/v3 plugin implementations for spec compliance, thread safety, and correctness. Use when the user asks to review an AudioUnit plugin, check…
Reviews audio DSP and audio processing code for realtime safety violations. Use whenever the user asks to review, audit, or check audio processing code — including plugin process callbacks, audio engine render functions, DSP implementations, or any code that runs on the audio
$ npx -y skills add kunitoki/sonic-skills --skill audio-dsp-review --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/audio-dsp-reviewContext preview
The summary Claude sees to decide when to auto-load this skill.
Reviews audio DSP and audio processing code for realtime safety violations. Use whenever the user asks to review, audit, or check audio processing code — including plugin process callbacks, audio engine render functions, DSP implementations, or any code that runs on the audio
name: audio-dsp-review description: > Reviews audio DSP and audio processing code for realtime safety violations. Use whenever the user asks to review, audit, or check audio processing code — including plugin process callbacks, audio engine render functions, DSP implementations, or any code that runs on the audio thread. Trigger on phrases like "review my processBlock", "check this DSP code", "is this safe for the audio thread?", "review my JUCE plugin", or when you see an audio callback and spot potential realtime violations. Flag issues proactively even when the user hasn't explicitly asked for a 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.
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.
**Memory allocations** (allocator paths may lock, grow arenas, touch new pages, or run unbounded bookkeeping):
`unordered_map::insert`, `deque::push_back`
**Locking** (priority inversion: the low-priority UI thread holds the lock your audio thread needs):
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)`.
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).
**System calls / blocking I/O** (kernel transitions stall for unbounded time):
**Warnings** (flag but don't block):
## Audio Realtime Safety Review: `[file / function]` ### Verdict [Safe | Has critical violations | Warnings only] — [one sentence summary] ### Critical Violations **[Category]: [description]** `file:line` — `offending code` Why: [one sentence on the realtime risk] Fix: [concrete suggestion] ### Warnings [same format] ### What's Done Well [correct patterns observed — pre-allocation, atomics, lock-free queues, etc.] ### Recommended Fixes (priority order) 1. ...
| Violation | Realtime-safe alternative | |-----------|--------------------------| | `std::mutex` for shared state | Lock-free `std::atomic<T>` for scalars after checking `is_lock_free()`; SPSC lock-free queue for structs | | `std::mutex::try_lock()` + RAII | `unlock()` in destructor does a syscall — not safe. Use `std::atomic_flag` spinlock with `try_lock()` only on audio thread + fallback | | Spinlock with busy-wait on non-audio thread | Progressive back-off: spin 5× → `_mm_pause()` 10× → batched 10× `_mm_pause()` → occasional `std::this_thread::yield()` | | `new`/`delete` in callback | Allocate in `prepareToPlay`; use pre-allocated pool or ring buffer | | `printf`/`DBG()` | Write to a lock-free ring buffer; drain from a background thread | | `std::string` ops | `std::array<char,N>` + `snprintf`; format on UI thread | | `vector` growing | `reserve()` on init; fixed-capacity container (`etl::vector`, `heapless::Vec`) | | `map::operator[]` insertion | `find()` + pre-populate; or `std::array` with index lookup | | Exception throwing | Validate in `prepareToPlay`; use error codes; never throw from callback | | `std::function` w/ captures | Function pointer + `void*`; or pre-store as member |
For deeper patterns (JUCE-specific, VST3, CLAP, Rust/cpal, Web Audio) see `references/realtime-violations.md`.
Precision audio-engineering skills for AI agents. Sonic Skills is a curated pack of Markdown skills for reviewing, debugging, explaining, and implementing audio software.
Repo: kunitoki/sonic-skills
Reviews AudioUnit v2/v3 plugin implementations for spec compliance, thread safety, and correctness. Use when the user asks to review an AudioUnit plugin, check…
Systematic checklist for diagnosing audio artifacts. Use when the user describes a sound quality problem — clicks, pops, crackling, silence, DC offset,…
Explains DSP math concepts to developers who need the theory behind an algorithm. Use whenever the user asks how a signal-processing concept works, wants…
Reviews audio DSP code for numerical correctness. Use when the user asks to review, audit, or check DSP code for correctness issues — filters, feedback loops,…
Profiling strategy for audio CPU issues — xruns, spikes, and buffer underruns. Use when the user reports CPU overload, audio glitches under load, or…
Traces and documents signal paths, bus/aux architecture, and sidechain connections in audio systems. Surfaces hidden coupling between audio components. Use…