WASAPI loopback

WASAPI loopback is a built-in mode of the Windows Audio Session API (WASAPI) that lets an app record the audio a computer is already playing — such as the voices in a video call — straight from the operating system’s output stream, without a microphone, a meeting bot, or a virtual audio cable.

How WASAPI loopback works

WASAPI is the core audio API that Windows has shipped since Windows Vista. Normally an app opens an audio client on a capture device (a microphone) to record, or on a render device (your speakers or headphones) to play sound.

Loopback is the twist: an app opens an audio client on a render device but in loopback mode, and instead of pushing audio out, it reads back the exact stream being sent to that output. So whatever Windows is currently playing — a Zoom call, a Google Meet tab, a Teams window, a YouTube video — is delivered to the app as a clean digital signal, at the device’s own sample rate and format. No driver is installed; the capability is part of the OS audio stack.

Loopback vs. a microphone vs. a virtual audio cable

These three approaches all let you “record a call,” but they are not equivalent:

• Microphone — records the room: your own voice, background noise, and the speaker output played back through the air, echoey and degraded. It captures your side cleanly but the other participants’ voices badly.
• Virtual audio cable — a third-party loopback driver you install and route by hand. It works, but it has to be configured, it can hijack or mute your normal playback, and it is one more thing to break.
• WASAPI loopback — uses Windows’ own API, so there is nothing to install and nothing to route. Your audio keeps playing normally through your real speakers while the app reads a copy of the same stream.

This is the Windows half of system audio capture: the general technique of reading what the computer is already playing, locally, instead of rejoining the meeting as a bot.

Capturing one app vs. the whole system

Classic WASAPI loopback captures the full mix being rendered to a chosen output device — every app at once. Newer Windows 10 and Windows 11 builds added a process loopback (application loopback) API that can include or exclude a specific process tree, so a tool can capture only the meeting app’s audio and leave your music alone. Either way, it is still the same native mechanism: no virtual device, no bot in the call.

Why it matters for bot-free meeting notes

Because WASAPI loopback reads audio that is already playing, a meeting tool can listen to a Windows call without sending a bot into it or installing a browser plugin. That is the engine behind bot-free meeting notes on Windows — there is no extra attendee on the participant list, and the audio is processed on your own machine. Canary feeds that captured stream into its streaming transcription and a live, rolling, multi-resolution summary, so you can catch up the instant your name is called. For the hands-on version, see how to take meeting notes without a bot.

The macOS and Linux equivalents

WASAPI loopback is the Windows-specific name for a cross-platform idea. macOS provides a Core Audio process-tap API (macOS 14.4 and later) that captures system or per-app audio without a virtual device; older macOS versions generally needed one — see how to record system audio on a Mac without a virtual device. Linux exposes “monitor” sources through PulseAudio and PipeWire. All three are forms of loopback audio capture; WASAPI loopback is simply how Windows does it.

A note on consent

Capturing a call should always be transparent, never secret. Recording-consent laws vary by region — some require only one party’s consent, others require everyone’s — so tell participants when you are capturing a meeting, regardless of which audio API does the work.