AudioIOKit

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

Biography

Every audio app in this ecosystem once carried its own engine plumbing. NoiseColour, Sonics, Voice Memo and the AUv3 extensions each started and stopped AVAudioEngine, each handled (or failed to handle) route changes and interruptions, and each installed taps in its own way. AudioIOKit is the response: a package whose README states that it is "not meant to be a monolithic DAW engine, device driver, or plugin host", but a substrate that an app can import, configure quickly and adapt with minimal friction. The design goal is explicit separation of low-level transport and graph lifetime from app policy, DSP composition, visualisation, inference and research tooling.

The package is organised as modular SwiftPM targets that mirror ownership boundaries. AudioIOHost is the narrow core: engine lifecycle, source/sink plumbing, rebuild handling, manual rendering. AudioDSPCore defines the canonical realtime DSP contract, a mixer, atomic parameter snapshots and single-producer single-consumer ring buffers on swift-atomics. AudioAnalysis provides LUFS; AudioDeviceControl enumerates and selects Core Audio devices on macOS; AudioScheduling is a separate target. Higher modules are deliberately optional: AudioOffline (codec and file-type discovery, deterministic export manifests), AudioPluginHost (scan-safe Audio Unit discovery and stable metadata snapshots), AudioARAHost (host-owned ARA-style document, region, key and scale metadata), AudioTimelineAnalysis (waveform pyramids, transient slices, time-stretch planning), AudioMIDI (semantic MIDI controller contracts including a three-octave air-piano keybed model and MIDI 2.0 UMP projection), AudioConvolution (impulse-response loading, CPU direct and partitioned convolution references, GPU parity contracts), AudioML and AudioPythonBridge (capability snapshots and disabled-by-default sidecar job plans with bounded payloads), AudioVisualizationMetal (waveform and spectrogram renderers), AudioComputeKernels (GPU capability reporting and CPU-oracle kernels), AssistantAudioIOBridge (AssistantApp-compatible bindings and readiness rollups) and AudioReleaseReadiness with an audio-release-readiness executable that turns external runner evidence into Markdown or JSON release summaries. AudioIOAppSupport adds an optional AppAudioEngine façade that composes policy above the host. AudioIOKit is a convenience umbrella for the core non-UI modules.

The distinctive idea is honesty about what a package test can and cannot prove. The manifest keeps SemanticCompute out of normal adoption entirely; GPU parity tests only compile when an environment variable points at a SemanticCompute checkout. The release-gate documents and the readiness tool exist because "a package-only green test run does not establish AA adoption", a sentence that appears verbatim in the handoff note. The package ships test targets for every module, including long-running SPSC stress cases and a stress CLI.

The most recent documented work is the October 2026 reliability upgrade. The host now tracks requested running state independently of engine.isRunning, coalesces configuration-change bursts, ignores replaced-engine notifications and recovers requested playback even if hardware stopped the engine before notification. Endpoint replacement is safe: it stops rendering, installs and prepares endpoints, rebuilds and resumes. Receiver setters can apply capture or tap enable flags in the same rebuild. Each graph generation has a callback gate so control code waits for in-flight callbacks outside realtime execution. Suspension reasons overlap safely, and reset recovery recreates resources and restores offline mode and the selected device. Diagnostics expose lifecycle state, suspension reasons, callback counters, output presentation latency and optional deadline metrics.

AssistantApp adopted that upgrade on 4 October 2026. Before it, by the adoption note's own account, AssistantApp had no AVAudioSession interruption or media-services-reset handling anywhere. NoiseColour's runtime moved to the batched receiver setters; an iOS session gate now suspends on interruption and resumes only when the system says it should, the user still wants sound and the session reactivates; the Sonics core's deinit no longer risks waiting inside a render callback. Three schemes built green against the live checkout. Real-device acceptance (calls, Siri, media-services reset, route changes, voice processing, sustained capture under load) is listed as outstanding and undone.

The audience is other audio apps on this Mac and, in principle, any Apple-platform developer who wants a host they can adopt in layers. This is a reusable native library without a browser runtime.

Modules (all authored; swift-atomics is the dependency)

Listed above: 18 library products plus two executables. Product names: AudioIOKit, AudioIOHost, AudioDSPCore, AudioAnalysis, AudioDeviceControl, AudioScheduling, AudioComputeKernels, AudioOffline, AudioPluginHost, AudioARAHost, AudioTimelineAnalysis, AudioMIDI, AudioConvolution, AudioML, AudioPythonBridge, AssistantAudioIOBridge, AudioReleaseReadiness, AudioIOAppSupport, AudioVisualizationMetal; executables audio-release-readiness, audio-io-stress.

Technical foundations

Swift tools 6.2; AVFoundation/AVAudioEngine; Core Audio HAL for device control; Metal (bundled SpectrogramShaders.metal, copied for runtime compilation); swift-atomics 1.2+; optional SemanticCompute via AUDIOIOKIT_SEMANTIC_COMPUTE_PATH for parity tests only. Test targets: one per module (18), including AudioKernelParityTests and AudioVisualizationMetalTests that only gain the parity dependency when opted in.

Maturity

Roadmap, limits, FAQs

Roadmap : multichannel I/O, GPU/MPS compute, codecs, AU/VST/ARA hosting, ML/Python sidecars, AssistantApp adapters, external evidence and release-candidate cutover, all in Docs/PHASED_IMPLEMENTATION_PLAN.md; AssistantApp side: Sonics iOS session owner, route-unavailable policy, device acceptance. Limits: macOS-first; several modules are contracts and metadata rather than engines (plugin host discovers and snapshots, it does not yet host audio; ARA module is host-owned metadata, not an ARA runtime; ML and Python modules are containment plans); no device acceptance; uncommitted changes. FAQ: Is this a DAW engine? No, by design. Do I have to take all of it? No; import AudioIOHost alone, add modules as needed. Does it need SemanticCompute? Only for opt-in parity tests. Who uses it today? AssistantApp's NoiseColour runtime and Sonics core; NoiseColour's iOS app. Is it tested on devices? Builds and package tests yes; interruption, reset and route acceptance on hardware is open.