How AudioRoute works

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.

The four components

AudioRoute ships as four small pieces that talk to each other over local IPC. Each one has a narrow job.

Tray app UI / control

UDS

Daemon capture

shared memory
lock-free ring

VST3 / AU plugin inside the DAW DAW track

Virtual audio device system input DAW input

Blue is captured audio, red is audio arriving in your DAW, grey is control only: the tray app never touches the signal. Both output paths read the same ring buffer, so you pick whichever one your app expects — you never need both.

1Daemon

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."

2Tray app

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.

3VST3 / AU plugin

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.

4Virtual audio device

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.

Why shared memory?

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.

What this approach enables

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.

Mic and system audio on separate tracks

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.

Zero audio-routing configuration after install

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.

What it doesn't do

No kernel extension. Everything runs in user space. No kernel module to sign, no System Integrity Protection prompts.
No output redirection. Your Mac's main output stays pointed at whatever device you had — speakers, headphones, interface.
No aggregate or multi-output device. Audio MIDI Setup is left alone.
No background network traffic. Capture is entirely local; the only network activity is license checks and crash reports (both opt-in-able).

Platform & requirements

macOS 14.2+ — required for CoreAudio process tap APIs. Apple Silicon & Intel, universal binary. Signed and notarized with an Apple Developer ID (Team ID 46A6G4F5XX).
Windows 10 build 20348 (21H2) or later, 64-bit — required for the process-loopback capture API. Installer is EV code-signed; the daemon, plugin and tray are all signed.
VST3 on both platforms; Audio Unit on macOS. Tested in Ableton Live (plugin) and Audacity (virtual device). Logic Pro, Reaper, FL Studio and other DAWs should work via the same standard formats.

Where the code lives

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.

Ask me anything

support@audio-route.com

Architecture questions, build questions, "does this do X?" — all welcome. I usually reply within a day.