Every live transcription tool — meeting notetakers, caption overlays, real-time interview assistants — depends on one unglamorous piece of plumbing: getting the other person's voice out of the operating system and into a speech model. That turns out to be the hardest part of the stack, and it's the part almost nobody explains. This article walks through how desktop audio capture actually works, why the microphone alone is never enough, what Windows and macOS each do differently, and where the delay between "they finished the question" and "text appears" really comes from.
Two audio streams, not one
Your computer keeps input and output audio strictly separate, and they carry different content:
- Microphone (input) audio is whatever a physical capture device hears in the room. In a video call that's your own voice, plus your keyboard, your fan, and the street outside.
- System (output) audio is whatever the machine is playing — the mixed signal heading to your speakers or headphones. In a call, that's the remote participant's voice, delivered over the network and decoded by the meeting app.
An app with microphone access alone can transcribe you and only you. To transcribe an interviewer, it needs the output side. Capturing that output side is called loopback capture: instead of reading from a mic, the app asks the OS for a copy of the stream that is already on its way to the speakers. There's a nice property here — because loopback taps the decoded playback stream, the app doesn't care whether the call is Zoom, Teams, Meet, or a phone bridge patched through the desktop. Everything that makes sound lands in the same place.
How loopback works on Windows
Windows makes this comparatively easy. The modern Windows audio stack exposes a loopback capture mode: an application opens an output endpoint but requests it in capture mode, and the system hands back the same PCM frames it is sending to that device. No virtual cable, no kernel driver, no extra install step. The app typically also asks for the device's mix format — sample rate, channel count, bit depth — and resamples to whatever the transcription model wants.
Two practical wrinkles matter more than the API details. First, loopback follows the active output device. If you're capturing the laptop speakers and then plug in a USB headset or dock, the audio moves to a new endpoint and the old capture goes silent until the app follows the switch. Well-built apps subscribe to device-change notifications and re-open the stream automatically. Second, if a playing device is idle, some configurations deliver silence rather than nothing at all, so the app has to distinguish "silent audio" from "no audio", which is one reason a level meter is genuinely useful.
How it works on macOS
macOS has historically been stricter. For a long time the system offered no general way for a normal app to tap the machine's output mix, so the standard workaround was a virtual audio device: a small software driver that registers itself as an output device, accepts whatever the system routes into it, and exposes that same signal back as an input the app can read. Users would install the driver, route playback into it, and often build an aggregate or multi-output device so they could still hear the call themselves. It works, but it's a lot to ask of a user, it can break across OS upgrades, and it changes the system's audio routing in ways people forget to undo.
More recent versions of macOS have added first-party facilities for capturing system or per-application audio, gated behind an explicit user permission prompt, which reduces the need for a third-party driver. We'd rather hedge than overstate here: exact capabilities and prompt wording differ by macOS release, so treat "recent macOS can do this natively, older macOS generally needed a virtual device" as the accurate summary rather than pinning it to a specific version number. What has not changed is the permission model — on macOS, capturing audio the user didn't explicitly authorize is not something an app can do quietly. The user grants it in System Settings, and the grant frequently only takes effect after the app is relaunched.
| Platform | How system audio is obtained | What the user has to do |
|---|---|---|
| Windows | Built-in loopback capture on an output endpoint | Usually nothing beyond installing the app |
| macOS (older) | Virtual audio device acting as a software speaker | Install driver, route output through it |
| macOS (recent) | System-provided capture API, permission-gated | Grant permission, often relaunch the app |
| Browser extension | Tab audio only, via the browser's own APIs | Grant per-tab access; desktop call apps unreachable |
Why a browser extension can only get tab audio
Extensions live inside the browser's sandbox, and that sandbox exists precisely to keep web code away from the operating system. The browser will let an extension capture the audio of a tab it has been granted access to, and it will let a page use the microphone with user consent, but it will not hand over the machine's output mix. So an extension-based tool works when the interview happens in a browser tab and nothing else is playing — and stops working the moment the call is in the Zoom desktop client, or a second source is mixed in, or the browser throttles the background tab.
A native app doesn't have that ceiling: it asks the OS directly, so it is agnostic to which meeting client is in use. That architectural difference is the main reason we build a desktop application, and it's covered in more depth in Chrome extension vs desktop AI interview assistant.
From raw samples to streaming text
Capture gives you a firehose of raw PCM samples. Turning that into live text is a pipeline:
- Buffer into chunks. The capture callback hands over small buffers continuously. The app accumulates them into chunks — commonly tens to a few hundred milliseconds each. Smaller chunks mean lower latency and more overhead; larger chunks are cheaper but laggier.
- Normalize the format. Devices run at whatever rate they like. The audio is downmixed to mono and resampled to the rate the speech model expects, then often converted to the encoding the transport uses.
- Stream, don't upload. Chunks go out over a persistent connection — a WebSocket or a bidirectional gRPC stream — as they're produced. Nothing waits for the speaker to finish.
- Receive partial then final results. The model emits interim hypotheses within a fraction of a second and revises them as context arrives. That's the visible "typing then self-correcting" behavior of live captions.
- Segment into turns. Voice-activity detection and endpointing decide where one utterance ends, which is what lets a downstream assistant know a question was actually asked rather than mid-sentence.
The mechanics of that last mile are unpacked further in how real-time AI transcription works.
Where the latency actually lives
People assume the model is the slow part. Often it isn't. The budget splits roughly like this:
- Capture buffer — you cannot transcribe audio that hasn't been captured yet, so the chunk size is a hard floor. Tens of milliseconds, by design.
- Network round trip — the dominant variable for many users, and the one most sensitive to Wi-Fi quality. Streaming amortizes it, but the first response still has to make the trip.
- Model inference — streaming ASR is fast; a downstream language model generating an answer is where seconds accumulate.
- Rendering — near-instant when tokens are painted as they arrive.
Our full breakdown of that end-to-end budget is in do AI interview assistants add latency?, and the hardware side is in system requirements for AI interview assistants.
Rule of thumb: if transcription feels slow, suspect the network before the model. If transcription is wrong, suspect the audio path before the model.
Troubleshooting: nothing is being picked up
Almost every "it's not hearing anything" report resolves to one of these, in rough order of frequency:
- Permission not actually granted, or granted but not applied. On macOS in particular, audio permissions commonly need an app relaunch. Toggle it off and on, then restart the app.
- The wrong output device. Loopback follows the active playback device. Headphones plugged in after launch, a dock, a Bluetooth switch, or a monitor with speakers can all move the stream out from under the capture.
- Exclusive-mode audio. Some apps and audio interfaces take a device in exclusive mode, which blocks other consumers. Switch the offending app to shared mode or pick a different output.
- Only your own voice in the transcript. That's the signature of microphone-only capture: system audio isn't running at all. Re-check the system-audio permission specifically, since it is usually separate from the microphone permission.
- Only their voice, never yours. The mirror image — system audio is fine, microphone permission or device selection is wrong.
- Level too low. If a meter shows a faint signal, the source volume, not the capture, is the problem.
- Stale virtual device. On macOS setups still relying on a virtual driver, an OS update can leave the routing half-configured. Rebuild the multi-output device or move to a native-permission path if available.
The short version
System audio capture is a solved problem, but it's solved differently on every platform. Windows exposes loopback natively. macOS gates it behind explicit permission and, on older releases, a virtual audio device. Browsers deliberately don't expose it at all, which caps what an extension can do. Once the stream exists, the rest is mechanical: chunk it, normalize it, stream it, and read partial results as they land. Understanding that chain is the difference between guessing at a problem and fixing it in thirty seconds.
See the capture pipeline in action
The fastest way to understand a real-time audio pipeline is to watch one run. Start on the free-forever plan — no trial timer, no credit card.
Start Free →FAQ
What is the difference between microphone audio and system audio?
Microphone audio is what a physical input device picks up from the room — your own voice, your keyboard, the fan behind you. System audio is what the computer is playing out of its speakers or headphones — in a video call, that is the other person's voice arriving over the network. They are two completely separate streams inside the operating system. A tool that only has microphone access hears you but not the interviewer; a tool that captures both has the full two-sided conversation. This is why system audio capture, sometimes called loopback capture, is the part that actually matters for transcribing a meeting.
How does an app capture system audio on Windows and macOS?
On Windows, the audio subsystem exposes a loopback mode: an app can open an output device in a special capture mode and receive a copy of the same audio being sent to the speakers, without any extra hardware or drivers. On macOS the story is different. For years the operating system did not expose a general system-audio tap to ordinary apps, so tools shipped or required a virtual audio device — a software driver that pretends to be a speaker, captures whatever is routed into it, and passes it back to the app. More recent versions of macOS have added first-party ways for an app to capture system or per-process audio after the user grants permission, which reduces the need for that workaround. Either way, macOS requires an explicit user permission grant.
Why can a browser extension only capture tab audio?
A browser extension runs inside the browser's security sandbox, and that sandbox intentionally stops web code from reaching the operating system's audio graph. The most an extension can normally get is the audio of a browser tab it has been granted access to, plus the microphone if the user allows it. That is enough if the interview happens in a browser tab and nothing else is making sound, but it breaks the moment the call runs in a desktop client such as the Zoom or Teams app, or when the audio is mixed across several sources. A native desktop application sits outside the browser sandbox and can ask the operating system directly, which is why desktop apps handle system audio more reliably.
How is captured audio turned into real-time text?
The capture layer produces a continuous stream of raw audio samples. The app slices that stream into small chunks — typically a fraction of a second each — normalizes the format to something the speech model expects, and streams the chunks over a persistent connection to a speech-to-text service instead of uploading a finished file. The model returns partial hypotheses almost immediately and refines them as more audio arrives, which is why live captions appear to type themselves and then quietly correct a word. Nothing waits for the speaker to stop talking, so text is usable within roughly a second of the words being spoken.
What should I check if no audio is being picked up?
Work through it in order. First confirm the operating system permission was granted — on macOS especially, audio and screen-related permissions often require quitting and reopening the app before they take effect. Second, check which output device is actually playing sound, since loopback capture follows the active output; plugging in headphones or a dock mid-call switches the device and can silence the capture. Third, make sure the meeting app is not holding the audio device in an exclusive mode. Fourth, check the input level meter to see whether audio is arriving but too quiet. If the transcript shows your own voice but never the other person's, the app is getting microphone input only and system audio capture is not running.