Guide · macOS · first-hand · updated 2026-09-06

Recording the sound your Mac is playing — and the failure that returns silence with no error.

There are three ways to capture internal audio on a Mac. Use an app built on ScreenCaptureKit when you want per-app sound with no driver installed and no change to your output device — this is the modern path and the one that needs the least from you. Install a virtual audio device when the sound has to be routed into another app that expects a microphone. Use QuickTime plus a virtual device for a one-off file when you do not want to install anything else. Whichever you pick, two things bite everybody, and neither is documented where you would look for it: ScreenCaptureKit needs a display that is awake, and its background daemon can wedge in a way that gives you a running stream, no error, and not one byte of audio. Both are below, with the numbers we measured while building a live captioner on top of this API.

Way one: ScreenCaptureKit, no driver

ScreenCaptureKit is Apple's framework for capturing screen content and system audio; Apple documents the audio side under Capturing screen content in macOS. An app built on it records what other apps are playing without a virtual audio driver, without a kernel extension, and without touching your input or output device — so your headphones keep working normally while the recording happens.

Open the app and start a capture. macOS asks once for Screen & System Audio Recording.
Approve it in System Settings → Privacy & Security → Screen & System Audio Recording, then start again.
Keep a display awake for the whole recording. See below.

Three limits worth knowing before you rely on it

The screen must be awake. ScreenCaptureKit enumerates displays before it captures anything. With the display asleep it fails with no display found and captures nothing — even when all you asked for was audio. Anything that has to run unattended needs the display kept awake.

Windowless processes are not captured. Sound from a command-line process — afplay somefile.wav in a terminal, say — is audible on your speakers and absent from the capture: the API works in terms of applications with windows. This makes testing confusing, because the obvious way to generate test audio is the one way that produces none. Play the file in a real app instead.

The permission belongs to the launching process. A capture helper started from Terminal inherits Terminal's grant, and the prompt names Terminal, not your helper. The same binary launched from inside a bundled app asks for that app. Rename the app or change its bundle identifier and macOS treats it as a new application, so the user has to approve it again — a detail that turns into a support ticket the first time you rename a product.

Way two and three: a virtual device, with or without QuickTime

A virtual audio device appears to macOS as both an output and an input. You send system sound to it, then any app that can record from a microphone can record it. This is the older approach and it is still the right one when the receiving app only understands microphones — a browser tab, a conferencing client, a DAW.

The cost is that it is a real change to your machine: an audio driver is installed, and while the recording runs your output device is the virtual one, so you have to route sound back to your speakers to keep hearing it. Multi-output setups solve that and are fiddly to get right.

QuickTime Player can record audio and will happily record from a virtual input device, which is the cheapest one-off recipe: install the virtual device, select it as output, open QuickTime → File → New Audio Recording, choose the virtual device as the input. QuickTime alone, with no virtual device, cannot capture internal audio.

The silent failure: replayd wedges and nothing tells you

This is the part that is not in anyone's tutorial, and it cost us an evening twice.

macOS serves ScreenCaptureKit through a background daemon, /usr/libexec/replayd. On macOS 26.5.2, after 45 days of uptime, that daemon wedged. From the app's side everything looked correct: the stream was created, startCapture returned successfully, no permission error, no exception. And no audio callback ever fired. Zero bytes, forever, with a UI that had every reason to believe it was recording.

What fixes it:

killall replayd — does nothing.
kill -9 $(pgrep -x replayd) — works, and does not need sudo. launchd restarts the daemon immediately and capture recovers.

Two consequences if you are building on this API rather than just recording once. First, a started stream is not evidence of a working stream: keep a monotonic byte counter and treat "ready, and still zero after a few seconds" as a distinct failure state with its own message, separate from "no permission". Second, restarting the daemon kills every ScreenCaptureKit stream on the machine, including your own other streams, so anything else you have running has to be restarted too.

Our own recovery, verified on 2026-09-02 while the daemon was actually wedged: detect zero bytes, kill -9 once, open a fresh capture, and 489,600 bytes arrived in the next 15 seconds. Once, not in a loop — if it does not come back, that is something else and a retry loop only hides it.

What healthy capture looks like, in numbers

If you are checking whether a capture is really working, compare against a rate rather than a waveform. Measured on our machine, capturing at 16 kHz mono 16-bit — the shape a speech recogniser wants:

What	Measured	Note
Steady-state byte rate	31,782 B/s	99.3% of the theoretical 32,000 B/s for 16 kHz mono 16-bit
Including stream startup	95.2% of theoretical	ScreenCaptureKit takes roughly 0.4 s to deliver the first buffer
48 kHz stereo resampled to 16 kHz mono	17 ms shorter than the source	0.025% — resampler priming, not drift
Envelope correlation, resampled vs native 16 kHz	0.9999	Resampling in the app is not what costs you accuracy

All four are from our own runs on an Apple-silicon MacBook, macOS 26.5.2 (2026-08 and 2026-09). They are here because a byte rate is falsifiable and "works great" is not.

Where this came from: Voice Translator (formerly Meeting Translator) captions English meetings on a Mac using exactly this path, and publishes its measured latency the same way. If what you want is the sound turned into bilingual subtitle files, the subtitle converter on this site takes it from there.

Questions people actually ask

Can a Mac record internal audio without installing anything?+

Yes, if the app you use is built on ScreenCaptureKit, which macOS provides for capturing screen and system audio. No virtual audio driver, no kernel extension, no change to your input or output device. You grant Screen & System Audio Recording once. What it will not do is capture audio from a process with no window: a command-line player such as afplay produces sound you can hear and ScreenCaptureKit does not capture.

Why is my system audio recording completely silent?+

If the app reports no error and the file is silence, the usual cause is not permissions. macOS runs ScreenCaptureKit through a background daemon at /usr/libexec/replayd, and that daemon can wedge: the stream starts, no error is raised, and no audio callback ever fires. We hit this on macOS 26.5.2 after 45 days of uptime. killall replayd does nothing; kill -9 $(pgrep -x replayd) works without sudo, launchd restarts it immediately, and capture recovers.

Does the screen have to stay awake?+

Yes. ScreenCaptureKit enumerates displays before it captures anything, so with the display asleep it fails with no display found and you get no audio at all — even though you only wanted sound. A recording that needs to run unattended needs the display kept awake.

Which app do I actually grant the permission to?+

The process that launched the recorder. A helper binary started from Terminal inherits Terminal's permission, so the prompt names Terminal; the same binary launched by a bundled app asks for that app. Rename the app or change its bundle identifier and macOS treats it as a different application, so the permission has to be granted again.