u/Medical-Criticism173

Hey r/macOS — Developer Saturday post. 

I built AudioRoute - a menu-bar app that lets you capture system audio through the built-in ⌘⇧5 screen recorder OR directly inside any DAW as a VST3/AU plug-in.

The problem: macOS's ⌘⇧5 recorder doesn't include system audio, and existing solutions (BlackHole, Loopback, Soundflower) either require setting up an aggregate device in Audio MIDI Setup or switching your entire output to a virtual device.

The approach: AudioRoute uses Apple's Core Audio process taps API (macOS 14.2+) - it registers as a virtual mic input, macOS treats it like any real microphone, and your speakers keep working normally during capture. No output juggling, no aggregate device dance.

Use cases:

  - Record ⌘⇧5 screencasts with system audio (tutorials, browser demos)

  - Pull Spotify/YouTube reference tracks into your DAW timeline 

  - Capture Zoom/meeting audio to a file

  - Record another DAW's output for A/B comparisons

  - Route browser-based sample libraries into your production

Details:

  - macOS 14.2+ (Core Audio process-tap API floor) + Windows

  - €29 one-time, 14-day free trial, no subscription

  - 2-min walkthrough of the ⌘⇧5 flow: https://youtu.be/fzJMdb2tPb0

- Or see other videos on a Youtube channel: https://www.youtube.com/@audioroute

  

I'm the developer. Happy to answer questions or take feature requests.

macOS's built-in screen recorder doesn't include system audio bydefault - it only records from the mic. But if you install a virtual audio device, macOS treats it as just another microphone, so anything playing on your Mac flows into the recording alongside the video.

I made a short video showing how AudioRoute's audio device (disclosure: I built it) can be used with the macOS screen recorder to include system audio in the recording:

https://www.youtube.com/watch?v=fzJMdb2tPb0

Happy to answer questions.

Saw a few questions recently about whether system-audio capture on Windows can be truly bit-perfect, so I'm posting the results of some investigation and null-testing I did. Sharing in case it's useful for anyone.

WASAPI process loopback can be bit-identical, but the chain only stays clean if three things match:  

  1. Source app's playback rate = device's Default Format rate

  2. Capture tool's requested rate = device's Default Format rate

  3. Both running 32-bit float

Mismatch any of them and the OS silently resamples. The resampler is internal - you won't see it in any UI but it shows up in the residual against the source.

Where the chain breaks in practice:  

  - Source at a different rate than the device -> engine resamples upstream of any capture tool

  - Audio Enhancements enabled -> EQ / Bass Boost / OEM APO before the loopback tap

  - Spatial Audio / Sonic / Atmos for Headphones -> additional rendering and resampling

  - Capture tool requesting a different rate than the engine -> loopback API resamples internally

  - Multiple apps mixing simultaneously -> any non-matching rates were already resampled before mixing

Set device Default Format to your source rate, enhancements off, capture tool to match.

The thing that fooled me. The first ~50–100 ms of any freshly started WASAPI render stream carries the engine's anti-click fade-in ramp. It's not your signal - but it's faithfully captured because it really is what the engine produced. If your null test starts at the same moment your source app begins playing, that ramp can poison the global residual.

I caught it chasing a 57.9 dB residual on a real WAV when synthetic noise was passing infinitely. Head-trim sweep:

```

   50 ms:   57.9 dB (dirty) 

  100 ms:  999 dB, max error 0

  200 ms:  999 dB, max error 0

```

Fix: prepend ~200 ms of silence to your test stimulus, or trim ~100–200 ms from the captured file before null-testing. For continuous capture of an already-running stream, this is invisible.

Full writeup with the debug chain and per-source-type results: https://audio-route.com/guides/bit-perfect-capture-windows