AudioRoute gets system audio into any DAW or recorder without aggregate devices — your Mac's output stays pointed at your normal speakers or audio interface. Below: how that's actually implemented, and why the usual BlackHole-style output swap isn't necessary.
Getting system audio into a DAW on macOS has traditionally meant redirecting your Mac's output through a virtual device (BlackHole, Soundflower) and then reassembling a path to your speakers with an aggregate or multi-output device. It works, but it hijacks your audio setup and breaks monitoring in subtle ways.
AudioRoute uses CoreAudio process taps, an API Apple shipped in macOS 14. Process taps let a trusted helper observe the system mix without intercepting it — your Mac's output continues going to whatever device you had selected, and AudioRoute gets a parallel copy of the audio to deliver to your DAW.
AudioRoute ships as four small pieces that talk to each other over local IPC. Each one has a narrow job.
A user-mode background process (not a kernel extension). It installs the CoreAudio process tap, reads the captured audio, and writes it into a shared-memory ring buffer. Runs per-user as a LaunchAgent — starts with your session, not with the machine.
This is where essentially all of the audio work happens. It's intentionally the component with the fewest responsibilities beyond "capture and publish."
A menu-bar UI built with JUCE. It doesn't touch audio — it just talks to the daemon over a Unix domain socket for control (start/stop, status, device selection, level metering). If you quit it, capture keeps working; it's just a remote control.
Drop it on an Ableton (or any DAW) track. The plugin opens the same shared-memory ring the daemon writes to, reads audio in the DAW's buffer size, and outputs it as the track's signal. No audio preferences to change in the DAW — your interface stays selected, the plugin just appears as a new sound source on whatever track you put it on.
A CoreAudio HAL plugin installed at /Library/Audio/Plug-Ins/HAL/. If you'd rather use AudioRoute as a standard input device — in Audacity, OBS, Zoom, or any DAW's input dropdown — this is the path. Under the hood it reads from the same shared-memory ring as the VST.
Audio plugins run inside the DAW's realtime audio thread, which has hard timing constraints. You cannot block that thread on a network call, a mutex, or a system call that might take longer than a few hundred microseconds. So the plugin and the daemon don't talk "live" — they meet at a shared-memory ring buffer, written by the daemon and read by the plugin without locks (a single-producer single-consumer queue).
Control messages (start, stop, change source) go over a Unix domain socket separately, because those can tolerate the latency of a syscall.
Leaving your Mac's audio routing untouched isn't just a tidiness thing — it unlocks workflows that aren't cleanly possible with output-redirection tools.
Arm one DAW track with the AudioRoute plugin (system audio from any app), arm a second track with your audio interface's mic input — hit record once and you get two independent tracks. Because the mic input was never claimed by a virtual device, it behaves like it always has. Edit each track separately, apply different processing, mute one without affecting the other.
This is the setup podcast hosts, tutorial producers, and live-session recorders have been stitching together by hand for years — typically with an aggregate device that merges everything into one bus.
The installer drops a signed .pkg onto the system — the plugin, the virtual input device, and the daemon all register in one pass. There's no Audio MIDI Setup step, no aggregate device to build, no Mac output to repoint. Open your DAW and the plugin is on the plugin list, the input device is in the input dropdown.
This is a direct consequence of the process-tap approach: because nothing in your audio chain is being impersonated, there's nothing for you to reassemble.
U82KGW2J6A).AudioRoute is not open source today, but I'm happy to go deeper on any of this — specifically the shared-memory layout, the tap lifecycle, latency numbers, or how the macOS and Windows ports stay symmetric. Drop a note and I'll reply.
Architecture questions, build questions, "does this do X?" — all welcome. I usually reply within a day.