Real-time audio on a mobile phone is a scheduling problem with human consequences. The operating system calls your callback every N samples — at 48 kHz with a 512-sample buffer, that is every 10.67 milliseconds — and expects a full buffer of PCM floats back before the deadline. Miss it once and the user hears a click or pop. Miss it repeatedly and Estua's sleep sound becomes unusable at 3 AM, which becomes a one-star review, which becomes a real problem for a studio with five apps and no venture capital cushion. Sonarish's microphone capture path lives under the same constraints: the audio HAL delivers samples on a high-priority thread, and anything you do in that callback determines whether the noise meter reads truth or garbage.

What the audio thread is and why it is sacred

On iOS, Estua uses AVAudioEngine with a manual source node callback. On Android, it uses AudioTrack with ENCODING_PCM_FLOAT in low-latency mode when the OEM supports it. Both platforms invoke your render function on a real-time priority thread that bypasses the normal UI run loop. This thread must never wait on contended locks, never allocate memory from the heap, never perform I/O, and never call into code paths that might do any of those things transitively. The reason is scheduling unpredictability: a malloc on a fragmented heap might take 200 microseconds on a good day and 5 milliseconds on a bad day. Your budget is 10.67 milliseconds total for all channels, all DSP, all mixing — and the OS needs part of that for its own overhead. One slow malloc and you glitch.

Rules we enforce in code review

These are not guidelines — they are review blockers. No heap allocation in the callback: no Swift Array append, no Kotlin list growth, no std::vector push_back, no NSString formatting. Preallocate all buffers at session start on the UI thread and pass pointers into the callback context. No locks that can block — use lock-free single-producer single-consumer ring buffers for passing data between the audio thread and the UI thread. No logging, file writes, or network calls, even guarded by debug flags, because debug builds ship to ktuyen's overnight soak tests and a forgotten print statement that allocates a string has caused more clicks than any DSP bug. On iOS specifically, avoid Objective-C message sends on the hot path; keep the callback in C or Swift struct code that the compiler can inline. Biquad filter coefficients, LFO rates, and scene parameters are computed when the user changes a setting on the UI thread; the callback reads only const structs that were written once and never mutated concurrently.

How Estua generates sound under these constraints

Estua's synthesis chain — described in detail in our non-repeating audio post — generates pink noise via Paul Kellet's economical recursive filter, a handful of multiplies and adds per sample with no FFT per block. Slow amplitude modulation uses one-pole low-pass filters on the absolute value of the signal envelope, running at the same sample rate with precomputed coefficients. Multiple uncorrelated LFOs modulate filter cutoff and gain at 0.02–0.15 Hz so the output never repeats on human-perceptible timescales. All of this fits comfortably within the 10.67 ms budget on modern phones at roughly 3–8% CPU, leaving headroom for Bluetooth audio output and background app suspension scares. The product context for why synthesis instead of loops is in our sleep and waves post.

Buffer size adaptation and Sonarish capture

Not every Android device wants 512 samples. Some OEMs request 192 or 256 for their DSP path. Estua adapts the requested buffer size at session start but keeps internal DSP state continuous across size changes so a resize does not produce a discontinuity click. Sonarish's capture side feeds a ring buffer consumed by the FFT engine on a background queue — the FFT itself never runs on the audio thread, only the PCM copy into the ring buffer does. That separation is why Sonarish can run a 4096-point transform while the meter updates at 30 Hz without glitches; see our FFT post for the transform details. The architectural principle is the same across both apps: the audio thread copies samples and returns; everything else happens elsewhere.

Debugging the clicks that still happen

When a click appears, we profile the audio thread directly — Instruments Time Profiler with the audio thread marked on iOS, Systrace with Trace.beginSection on Android. In our experience, 99% of production clicks trace to debug-only code that leaked into the hot path: a String format for logging, a guard assertion that allocates, an accidental Swift optional unwrap that triggers a slow path. We guard all debug instrumentation with compile-time flags that are verified off in release builds, and ktuyen's overnight Estua soak test — eight hours of continuous playback in airplane mode — is the final gate before any release tagged by atuan. The audio thread is unforgiving. Treat it accordingly.