How to Record System Audio on a Mac for Meetings (No Bot)

Recording your own voice on a Mac has always been trivial. QuickTime, Voice Memos, the mic in any app — point it at the microphone and you get a file. The hard part, the part that sends people searching, is the other half of a meeting: the audio coming out of the Mac. The voices of everyone else on the Zoom call. The customer talking through your speakers. The system audio.

macOS made this deliberately difficult for years. Apps could read the microphone, but the system’s audio output was walled off. The standard workarounds were ugly: install a virtual audio driver like BlackHole or Loopback, route the output through it, and pray nothing in the signal chain broke before the meeting started. Or invite a recording bot into the call and let it do the capture from the cloud side. Both work. Both are more friction than “record the audio my Mac is already playing” should ever require.

As of macOS 26 Tahoe, the workaround era is over. The OS exposes a clean, sanctioned way to record system audio per application, and an app can transcribe that audio on-device without any of it touching a network. This post is about how that works, why it matters for meetings specifically, and how to go from “I want a transcript of this call” to a finished, searchable summary without a bot in the meeting or a kext in your audio chain.

Why recording system audio on a Mac used to be hard

The microphone and the speakers are governed by different rules on macOS, and for good reason. Any app reading your system’s audio output could, in principle, eavesdrop on every other app — your music, a private FaceTime call, a video you forgot was playing. Apple’s answer for most of macOS history was simply: third-party apps don’t get the output stream. Full stop.

That left three options for anyone who needed to record a meeting’s far-end audio:

• Virtual audio drivers. BlackHole, Loopback, Soundflower in the old days. You create a virtual output device, set it as the system output, then record from it as if it were a microphone. It works, but it hijacks your audio routing — you stop hearing the call through your normal speakers unless you build a multi-output aggregate device, and one misconfigured step means a meeting where you can’t hear anyone.
• A meeting bot. Otter, Fireflies, Read.ai, and the rest join the call as a participant and record server-side. No driver to configure, but now there’s a stranger in your customer’s meeting and the audio is on someone else’s cloud.
• Recording the screen. QuickTime’s screen recording could capture system audio in some macOS versions, but only the whole system, only as a video file, and with no path to a transcript.

None of those is what you actually want, which is: capture the audio this specific app is playing, leave everything else alone, and hand me text.

The four ways, compared

Method	Scoping	Where the audio goes	Transcript?	Fragility
Per-app capture (macOS 26 app, e.g. Dictanta)	One app’s audio + your mic	Stays on the Mac	Yes — on-device, live	Grant one permission, done
Virtual audio driver (BlackHole, Loopback)	Whole system output	Stays on the Mac	No — raw audio file only	Reroutes your audio; one misstep mutes the call
QuickTime screen recording	Whole system, as video	Stays on the Mac	No	Produces a video file you then have to process
Cloud meeting bot (Otter, Fireflies, Read.ai)	The meeting, from inside it	Vendor’s cloud	Yes — cloud-side	Visible participant; vendor retention policy

Only two rows produce a transcript, and they differ in exactly one architectural respect: whether the meeting audio leaves your machine. The rest of this post is about the first row — what macOS 26 changed to make it possible, and what the flow looks like in practice.

What changed in macOS 26

Two frameworks, both shipping as standard parts of macOS 26 Tahoe, close the gap:

• ScreenCaptureKit with audio-only content filters. ScreenCaptureKit started life as the modern screen-recording API, but its content filters can be scoped to audio only, and — critically — to a single running process. You can tell the OS “give me the audio output of the Zoom helper process” and get exactly that stream, with nothing else from the system mixed in. No virtual driver, no rerouting, no aggregate device. Your speakers keep working normally; the capture happens in parallel.
• SpeechAnalyzer, Apple’s on-device automatic speech recognition framework introduced at WWDC 2025. It transcribes that captured audio locally on the Mac’s own silicon. MacStories’ independent testing put it roughly 55% faster than Whisper Large V3 Turbo on the same Apple silicon, with no network round trip at any point.

The combination is the thing that matters. ScreenCaptureKit gets you the far-end audio cleanly; SpeechAnalyzer turns it into text without that audio ever leaving the laptop. Add Apple’s on-device Foundation Models for the summary and the entire pipeline — capture, transcribe, summarize — runs on the chip in front of you.

Because the capture is scoped per process, it’s also meeting-platform-agnostic. ScreenCaptureKit sees Zoom, Teams, Meet in a browser, Webex, Discord, and a podcast playing in Safari the same way: as processes producing audio. That’s why a single capability — “record system audio on Mac” — underpins the platform-specific guides for transcribing Zoom without a bot, recording Teams on Mac, Google Meet transcription, and Webex transcription. The mechanism is identical; only the app producing the audio differs.

Recording system audio for a meeting, step by step

Here’s the full flow on a fresh macOS 26 Mac, using Dictanta — the Mac/iPhone/iPad/ Vision Pro app that wires ScreenCaptureKit, SpeechAnalyzer, and Foundation Models into one record-transcribe-summarize loop. The specific app matters less than the shape; this is what “record system audio for a meeting” looks like when the OS does the heavy lifting.

1. Grant screen recording permission once

The first time you capture system audio, macOS prompts for screen recording permission. The pane’s macOS 26 name — Screen & System Audio Recording — says it plainly: system audio is part of what this permission grants, and audio is the only part Dictanta uses. ScreenCaptureKit’s audio path lives under the same TCC entitlement as its video path, even when no video frames are captured. Grant it once in System Settings → Privacy & Security → Screen & System Audio Recording, and the prompt never returns.

You’ll also grant microphone permission if you want your own voice in the recording, which for a meeting you almost always do.

2. Join the meeting however you normally would

There’s nothing to configure inside Zoom, Teams, Meet, or Webex. You don’t enable a host setting, you don’t invite anyone, you don’t need to be the meeting organizer. The capture happens entirely outside the meeting, on your Mac, by reading the audio your speakers are already producing. A guest on someone else’s call has exactly the same capability as the host — which is the whole point.

3. Start the recording from the menu bar

Dictanta lives in the menu bar. Click the waveform icon and hit Record when the call starts. The icon turns coral and pulses; the panel shows a live caption of what’s being said, streaming in near real time. ⇧⌘R starts a new recording when Dictanta or its panel is frontmost, and an optional global shortcut (⌃⌥⌘R) — the “Global record shortcut” toggle in Settings, off by default — starts or stops recording from any app.

This is also where the per-process scoping shows up. Dictanta points the capture at the meeting app’s process specifically, so if you have Spotify playing or a YouTube video paused in another tab, none of that audio lands in the transcript. The source picker has exactly three options: My voice (just your mic), This meeting (the auto-detected meeting app’s audio plus your mic), and Another app (the frontmost app’s audio plus your mic) — pick before you press record if more than one app is making noise.

4. Your microphone is part of the mix

For a meeting, the two system-audio options capture both streams: the system audio (everyone else) plus your microphone (you), mixed automatically and transcribed together so the transcript reads as a single conversation. For a solo recording — dictating a draft, a voice memo — choose My voice.

5. Stop, and get a finished summary

When the meeting ends — or you click stop in the menu-bar panel — three things happen locally, with no network call:

1. A final transcript with per-segment timestamps. Every segment is tap-to-seek; click a line and the audio player jumps to that moment.
2. A structured summary via Apple’s Foundation Models. TL;DR, action items with best-effort owner and due-date inference, decisions, and open questions. The LLM runs on-device, same as the transcription, and the text never leaves the Mac.
3. Audio-anchored bullets. Every summary bullet links back to the audio span it came from. Click a bullet, the audio scrubs to that moment, the matching transcript line highlights. When a summary claims “the customer agreed to a Q3 renewal,” you click it and hear whether anyone actually said that — the difference between a verified note and a plausible one.

6. Export, or leave it in place

Dictanta exports to Markdown, PDF, Word (.docx), SRT subtitles, and JSON. Markdown drops cleanly into Notion, Obsidian, Bear, Apple Notes, Logseq, and Craft; PDF and Word cover anyone who just needs a readable document; SRT covers video workflows; JSON is for Shortcuts flows or your own automation. Or leave the recording in place and rely on on-device full-text search across every meeting you’ve captured.

The privacy difference, stated precisely

“Record system audio on Mac” can mean two very different architectures, and the distinction is the entire reason people in regulated work search for it.

The bot approach records the meeting from a server-side client. The audio is streamed to a cloud transcription service, summarized by a cloud LLM, and stored on the vendor’s backend so their dashboard and search work. When a customer asks “where does this audio live,” the honest answer involves at least three external processors.

The on-device approach records the audio your Mac is already playing, transcribes it on the Mac itself, summarizes it with an on-device model, and writes the result to your SSD. When a customer asks where the audio lives, the answer is “on this laptop, behind FileVault — delete the recording and it’s gone” — which is acceptable to a much wider range of customers, compliance teams, and procurement reviews. Transcripts and summaries sync across your Apple devices through CloudKit by default; the audio itself never syncs — there is no setting that sends it anywhere.

This is the same architectural argument that drives people away from cloud notetakers toward an on-device stack, covered from the competitor angle in the Otter alternative and Fireflies alternative write-ups. The underlying capability — recording system audio locally — is what makes the no-cloud answer possible at all.

Where local system-audio recording has limits

Worth being honest about the gaps, because they’re real and they matter for some workflows:

• It’s Mac-only. System audio capture depends on ScreenCaptureKit’s per-process audio path, which exists on macOS. iOS and iPadOS don’t let third-party apps subscribe to other apps’ audio output, so the iPhone and iPad versions of Dictanta cover mic-only recording and Voice Memo import, not meeting system-audio capture. If you need to record a meeting’s far-end audio, you need to be on the Mac.
• No speaker labels. Because the capture is a single mixed audio stream, there are no per-participant tracks to label. Cloud bots that join as a participant can tag speakers from the meeting’s named audio streams; a local system-audio mix can’t. Diarization from a mixed stream is planned for a later release. If “who said what” is a hard requirement today, a bot-based tool is the better fit.
• You have to be present. A bot can sit in a call you skipped. Local recording needs your Mac in the meeting, awake, and playing the audio.
• The call has to run on the Mac. If you join the call on your phone instead of the Mac, there’s no Mac audio to capture. Capture works whenever the call itself runs on the Mac, whatever headphones you use — ScreenCaptureKit taps the meeting app’s audio stream directly, so the output device doesn’t matter.
• macOS 26 minimum (26.4 for Dictanta). SpeechAnalyzer and Foundation Models require macOS 26 Tahoe on Apple silicon. On an older OS or an Intel Mac, the on-device path isn’t available.

If none of those is a blocker for your meetings, local capture is the cleaner default. If one of them is, the bot model still exists and nothing about local recording prevents you from using both.

A note on the old virtual-driver method

You can still do this the old way — install BlackHole, build an aggregate output device, route system audio through it, record from the virtual input. It’s free and it works on older macOS versions where ScreenCaptureKit’s audio path isn’t available.

What you give up is everything around the capture. You get a raw audio file, not a transcript. You manage your audio routing manually and risk a meeting where you can’t hear anyone because the aggregate device dropped your real output. You have no per-process scoping, so the recording catches every sound the Mac makes, not just the meeting. And you’ve added a kernel-level audio driver to a machine that may be managed by an IT department that doesn’t love unsigned kexts.

For a one-off recording on an older Mac, the virtual-driver route is fine. For recording meetings regularly on macOS 26, the sanctioned per-process path is strictly less fragile.

Bottom line

Recording system audio on a Mac stopped being a hack in macOS 26. ScreenCaptureKit exposes the audio output of a single process cleanly, SpeechAnalyzer transcribes it on-device, and Apple’s Foundation Models summarize it — all without a virtual driver, a bot in the call, or a single byte leaving the laptop.

For meetings specifically, that’s the whole game: click Record when the call starts, get a timestamped transcript and an audio-anchored summary when it ends, and never explain to a customer who the unfamiliar attendee in the participant list is, because there isn’t one. Dictanta ships exactly this flow, free for your first three recordings with no length cap — enough to record a real meeting end to end and decide whether the on-device path fits. Paid tiers are $9.99/mo, $79.99/yr, or $149.99 lifetime, with no per-minute meter at any tier.

If you’ve been routing audio through a virtual driver or apologizing for a bot in your meetings, the macOS 26 way is the upgrade you’ve been waiting for.

FAQ

Do I need to be the meeting host to record system audio?

No. There’s nothing to configure inside Zoom, Teams, Meet, or Webex — the capture happens entirely outside the meeting, on your Mac, by reading the audio your speakers are already producing. A guest on someone else’s call has exactly the same capability as the host.

Why does macOS ask for screen recording permission to record audio?

ScreenCaptureKit’s audio path lives under the same TCC entitlement as its video path, even when no video frames are captured. On macOS 26 the pane is named Screen & System Audio Recording — system audio is precisely what’s being granted. Grant it once and the prompt never returns.

Will music or other apps end up in the meeting recording?

No. The capture is scoped to the meeting app’s process, so Spotify or a YouTube video paused in another tab never lands in the transcript. The source picker offers three options before you press record: My voice, This meeting (the auto-detected meeting app), or Another app (the frontmost app).

Can an iPhone or iPad capture a meeting’s system audio?

No — per-process system-audio capture depends on ScreenCaptureKit, which exists on macOS. The iPhone and iPad versions cover mic-only recording and Voice Memo import; to record a meeting’s far-end audio, you need to be on the Mac.