Capturing System Audio on macOS Without a Virtual Device

Capturing System Audio on macOS Without a Virtual Device

October 10, 2026

Recording what the machine is playing — a video call, a video being demonstrated, an alert sound — used to be the hardest part of building a screen recorder on macOS. The microphone was easy. Everything else required getting into the audio stack in ways Apple increasingly did not want you in.

Why everyone shipped a driver

Table of macOS system audio capture approaches and their costs
Four routes to system audio, and what each asks of the user.

macOS does not hand an application the system output mix. The historical workaround was to install a virtual audio device: the system plays into it, your app reads from it, and the user hears a copy routed onward.

It works. It also means the user installs a system extension, approves it in Security settings, and restarts. Most people do not finish that. They abandon at the restart, and your “free screen recorder” has a first-run experience worse than the problem it solves.

The kernel-extension version of the same trick is worse — deprecated and blocked by default on recent macOS, with no path back.

Aggregate devices avoid the install but reconfigure the user’s audio setup, which produces its own category of support request when their headphones stop working after a recording.

What changed

ScreenCaptureKit captures system audio directly. No driver, no extension, no restart. The same API that gives you the screen gives you the audio the screen is producing.

Practically:

  • enable audio capture on the stream configuration
  • audio arrives as sample buffers through the same output callback as video
  • you can exclude your own process, so the recorder does not capture its own sounds
  • the user grants Screen Recording permission once, and that covers it

That last point is the one that matters commercially. One permission prompt, no restart, nothing installed. The drop-off between “downloaded” and “made a recording” collapses.

The sharp edges

One permission covers both. Screen Recording permission grants audio too, which is good for the flow and means you should be explicit in your own interface about what is being captured. A user who granted “screen recording” may not have understood that the call audio comes with it.

The format is not what you asked for. Buffers arrive at the system’s rate and layout, which may not match your encoder. Resample and convert explicitly rather than assuming — and do not assume it stays the same if the user changes output device mid-recording.

Excluding your own app matters more than it sounds. Without it, any sound your recorder makes is in the recording, and so is anything it plays back while recording.

Silence is still buffers. When nothing is playing you still receive audio buffers full of zeros. Treating “no sound” as “no data” produces gaps that desynchronise the file.

Keep the two sources apart

Table explaining why system audio and microphone should be captured separately
Why the two sources stay apart in the pipeline.

Microphone and system audio want different handling. System audio arrives at whatever level the source produced; the microphone needs gain, possibly automatic levelling, and the user may mute it mid-recording.

Capture them as separate streams and mix at write time. Mixing at capture time means any later decision — duck the system audio while the person speaks, let the user mute retrospectively, write separate tracks — is no longer available.

It also makes the common user request trivial: record the call but not my voice, or my voice but not the call.

Keeping it in sync

Audio and video arrive through the same callback with presentation timestamps. Use them. Deriving timing from your own clock, or from a buffer count, drifts — slowly enough that a two-minute test looks perfect and a forty-minute recording is half a second out at the end.

If audio and video come from different sources with different clocks, one of them has to be authoritative and the other resampled against it. Pick audio: a frame dropped from video is invisible, a gap in audio is immediately audible.

What to tell the user

Two things, in the interface rather than in a help page.

That macOS will ask for Screen Recording permission, and that this single permission is what allows system audio as well — otherwise a privacy-minded user sees an unexplained prompt and refuses it.

And a visible indicator of which audio sources are live, with a way to toggle each. Recording a call and discovering afterwards that only your own voice was captured is the single most common complaint about any screen recorder, and it is an interface problem rather than a technical one.