Record System Audio on Mac for Meetings, No Bot Required

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.

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 Neural Engine. Apple’s published benchmarks put it roughly 55% faster than Whisper 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. This catches people off guard — you’re not recording the screen, you’re recording audio. The reason is that 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 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.

Dictanta lives in the menu bar. The default global hotkey is ⇧⌘R. Press it when the call starts. The icon turns coral and pulses; a short live-captions strip drops down with the transcript scrolling in near real time, about 300ms behind the speaker on an M-series Mac.

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 default source is “the process with active audio,” and you can pick a specific source from the picker before you press record if more than one app is making noise.

4. Choose whether to include your microphone

For a meeting, the default is both streams: the system audio (everyone else) plus your microphone (you), mixed and transcribed together so the transcript reads as a single conversation. For a solo recording — dictating a draft, a voice memo — you flip to mic-only. The choice is one toggle before recording.

5. Stop, and get a finished summary

When the meeting ends — or you press ⇧⌘R again — three things happen locally, with no network call:

A final transcript with per-segment timestamps. Every segment is tap-to-seek; click a line and the audio player jumps to that moment.
A structured summary via Apple’s Foundation Models. TL;DR, decisions, action items with best-effort owner and due-date inference, open questions, follow-ups. The LLM runs on the same Neural Engine as the transcription and the text never leaves the Mac.
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 v1.0 exports to Markdown, JSON, and plain text. Markdown drops cleanly into Notion, Obsidian, Bear, Apple Notes, Logseq, and Craft; JSON is for Shortcuts flows or your own automation. DOCX, PDF, and SRT export ship in v1.1. 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 Neural Engine, 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, auto-deleting in seven days” — 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 stays local-only unless you explicitly turn on iCloud Drive backup.

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 in v1.0. 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, at least not in v1.0. Diarization from a mixed stream is on the v1.1 roadmap. 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.
AirPods bonded only to your iPhone bypass the Mac. If you route meeting audio to AirPods paired only to your iPhone, that audio never goes through the Mac’s output and there’s nothing for ScreenCaptureKit to capture. Pair to the Mac, use wired headphones, or use the built-in speakers, and the path works.
macOS 26 minimum. 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 the Neural Engine, 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: press a hotkey 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.