System audio and the microphone on macOS.

Your voice reaches the Mac through a microphone, and that half is ordinary: the app opens a capture session, macOS shows the microphone permission prompt once, and the orange dot appears in the menu bar for as long as it is listening. It works the same way in every tool, and it has for twenty years.

Everyone else’s voice reaches the Mac as playback, on its way out to your speakers or headphones, and there is no input device on a Mac that means what the speakers are playing. Playback goes out to hardware, and by default nothing gets to listen in on the way. Every way of capturing it is a way around that, and each one comes with a different permission attached.

1. A virtual audio device. The old way, and still in use. You install a system-wide plug-in that presents itself as a speaker, set it as your output, and it hands whatever it receives back as an input the recorder can read. It works everywhere, and it is intrusive: your sound now goes through a third party component, you generally need a second device on top so you can still hear the call, and every macOS update is a chance for it to need re-approving.
2. ScreenCaptureKit. Since macOS 13 the screen capture framework can capture audio as well as pixels, and a stream can be configured to capture the audio and no pixels at all. No driver, nothing installed, nothing rerouted. The catch is the front door: it is the screen capture framework, so macOS asks for the Screen Recording permission even though the app is not looking at your screen. It can also exclude its own process from the capture, so the recorder never picks up its own playback.
3. Core Audio process taps. The newer and more surgical option: tap the output of chosen processes rather than everything the machine plays. That is the difference between recording the meeting and recording the meeting plus the notification that arrived halfway through it.

All three end in the same place. The recorder holds two streams, one from the microphone and one containing every other voice in the call, and it never had to touch the meeting service to get them.

The obvious next step is to mix the two into a single track. The better one is to keep them apart for as long as possible, because the split carries information that is expensive to recover afterwards: everything in the microphone stream is someone in the room with you, everything in the system stream is someone on the far end. That is speaker separation for free, before any model has to guess at it.

What makes it fiddly is that the two streams are driven by different clocks. A microphone and an output device each run on their own timing, and over an hour they drift apart by enough to matter, so the audio has to be resampled onto a common timeline rather than simply stacked. Getting that wrong is what produces transcripts where the two halves of a conversation slowly stop lining up.

Sitting in a room with speakers rather than headphones undoes some of this on its own: the microphone hears the far end coming out of the speakers, so the same voice arrives twice, slightly apart. Headphones are the single cheapest improvement to any meeting recording.

The other way to get a meeting’s audio is to ask the meeting service for it. The tool joins the call as a participant, using the same interfaces the platforms publish for recording, and the audio arrives on the vendor’s servers already mixed. That is the extra attendee with a name like Notetaker that shows up in the participant list, and it is not laziness. It buys real things.

Capturing on the device is the mirror image. It works only on that Mac, only while it is awake and the app is running, and only for meetings you are actually in. In exchange nothing appears in the attendee list, there is no link to paste and no account to connect, and the audio never has to leave the machine to become a recording. It is also app agnostic in a way the bot route is not: a browser tab is just another process making sound, so a call in a browser is captured exactly like a native meeting app, and so is the conversation happening in the room.

• The permission looks wrong to users. An app that records no pixels asking for Screen Recording reads as suspicious, and explaining it once in the onboarding is the whole fix. It is worth checking that any tool you install has an answer.
• Permissions get reset. Major macOS updates and reinstalls can drop the grant, and a recorder that does not check its permission before it starts will happily record an hour of silence.
• The system stream is everything. Notifications, music, a video someone left playing. Excluding processes, or at least the recorder’s own output, is what keeps that out of the transcript.
• Sleep ends the party. A closed lid stops both streams. Anything that must survive a shut laptop belongs on a server, which is precisely the case a bot exists for.
• Nobody asks the room for you. No framework, no platform API and no vendor obtains consent on your behalf, and the rules differ by country and by state. Say you are recording.

Aside takes the on-device route. It records your Mac’s system audio and your microphone, so nothing shows up in the attendee list, there is no link to paste and nothing to connect. That covers Zoom, Google Meet, Teams, Webex, Whereby, Slack huddles and the table you are sitting at, because the capture never knew which app the sound came from in the first place.

From there it records and transcribes on your Mac, and the note lands as a Markdown file in the folder you chose. The trade is the one described above: it is the Mac in front of you, awake, with the app running. If you need a recording of a meeting you are not in, a bot is the honest answer and this is not it.

What happens to the audio after it is captured is the transcription guide, and the tools that take the bot route are laid out on the comparison pages.

Last updated 13 August 2026.