Virtual audio device

A virtual audio device is a software driver that presents itself to the operating system as both an output and an input — a speaker that is also a microphone — so that audio played into it by one app can be recorded or rerouted by another, with no physical sound card involved. VB-Cable and Voicemeeter on Windows, BlackHole and Soundflower on macOS, and null sinks on Linux are all the same idea.

You will also see it called a virtual audio cable, a loopback driver, or a virtual mixer. For years it was the standard answer to “how do I record the sound my computer is playing.” On current operating systems it usually isn’t, and knowing why is the difference between a five-minute setup and an afternoon of routing.

How it works

Your operating system keeps a list of audio endpoints: outputs it can send sound to, and inputs it can read sound from. A virtual audio device adds a fake entry to both lists at once, wired together so that whatever arrives at the output side becomes readable on the input side.

That gives you a plumbing trick. Set your system output to the virtual device, and every sound your computer plays — including the voices on a video call — now arrives somewhere an ordinary recording app can open as if it were a microphone. Nothing physical is involved: the audio never becomes sound in a room, so what you capture is the clean digital stream rather than a mic’s echoey re-recording of your speakers.

What follows from being a destination, not a copy

Almost everything people find frustrating about virtual audio devices comes from one fact: a virtual device is a real destination. Sound sent there goes there instead of going to your headphones — it is a detour, not a duplicate.

• You stop hearing the call. This is the step every tutorial has to deal with. Once your output is the virtual device, your headphones get nothing, so you have to rebuild a path back to your ears — a multi-output device on macOS, a monitoring option in a virtual mixer like Voicemeeter on Windows. You are hand-building a fork in the signal that the OS could have given you for free.
• The routing is static, and it breaks quietly. The setup points at one endpoint. Plug in a USB headset, connect Bluetooth earbuds, or join a call that grabs the default device, and the audio takes a different path than the one you configured. Nothing errors — you just get a recording of silence, which you usually discover afterwards.
• It is a driver, so it needs permission to exist. Installing one requires administrator rights and, on macOS, approving system software from the vendor. On a managed work laptop that is often a hard stop — the same wall people hit when their company blocks meeting bots, reached from the hardware side. It also survives reboots as a permanent entry in your device list, and it is one more piece of low-level software to break after an OS update.
• It carries only what you routed into it. A plain virtual cable receives your system output, and your own voice does not go to your speakers — it goes out through your microphone. So your side of the conversation is missing unless you deliberately mix it in, which is exactly why simple cable setups escalate into full virtual mixers.

What a virtual audio device is genuinely good at

None of this makes them obsolete. Because a virtual device is both a destination and a source, it can do something that capture APIs fundamentally cannot: put audio into an application.

That is a real job with no substitute. Playing a sound file or a backing track into a video call, routing a synth or a DAW into a recorder, sending one app’s output into another app’s input, splitting several apps onto separate tracks, or blending a microphone and system sound into a single stream for streaming — all of that is routing, and routing is what a virtual device is for. Some tools install one for reasons that have nothing to do with recording: real-time noise cancellation works by sitting in the path your microphone audio travels through, which is why noise-suppression tools like Krisp show up as an extra device in your list.

The narrow claim is this: a virtual audio device is a router, and for the specific job of recording what your computer is already playing, it is now the wrong tool.

Why capture apps stopped needing one

Every major operating system now exposes playback capture directly, so an app can ask for a copy of the output stream while that stream keeps playing normally:

• Windows — WASAPI loopback, available since Windows Vista, lets an app open an output device in loopback mode and read back exactly what is being rendered to it.
• macOS — the Core Audio process-tap API added in macOS 14.2 Sonoma taps system or per-app audio with no driver installed. Before it, a virtual device really was the only option on a Mac, which is why so much advice still online assumes one.
• Linux — PulseAudio and PipeWire expose monitor sources that mirror an output device’s stream.

The distinction in one line: native loopback audio capture hands an app a copy of a stream that is still on its way to your ears, while a virtual audio device makes you redirect the original and then build the path back yourself. Same recording, one fewer thing to install, configure, and re-fix.

Things that get called virtual audio devices but aren’t

• Stereo Mix is a legacy recording input exposed by some onboard audio drivers, not a virtual device you install and not a feature of Windows. It is missing on many modern laptops and is tied to an analog output path, so it typically stops carrying what you hear the moment you switch to a USB headset or Bluetooth — see recording system audio on Windows without a virtual device.
• Aggregate and multi-output devices on macOS are built into Audio MIDI Setup and install nothing, but they only combine or duplicate endpoints you already have. They cannot capture playback by themselves — in the classic recipe, a virtual driver still has to be one of the members. The Mac walkthrough covers what replaced that.
• A meeting bot isn’t on your machine at all. It is a cloud participant that joins the call through the meeting link, which is a different capture method with an entirely different set of tradeoffs.

Why this matters for meeting notes

Most people who go looking for a virtual audio device are trying to capture a call. It is worth noticing that the plumbing is the easy half of that problem: even a perfectly routed setup leaves you with an audio file, and for a meeting an audio file is a worse version of the problem you started with, because you still have to go and listen to it.

Canary is a real-time, bot-free meeting summarizer. It captures your computer’s system audio (no bot in the call, no plugin) and shows a live, multi-resolution rolling summary — from what’s being said right now to the whole call — so you can catch up the instant your name is called. It uses the operating system’s own system audio capture, so there is no virtual device to install, nothing to reroute, and nothing that breaks when you switch to Bluetooth — and because it listens to the machine rather than the platform, it works the same in Zoom, Teams, Meet, or Webex. If you want your own voice in the transcript as well, a tool has to mix in your microphone; system audio alone is the other participants.

For the wider picture of capturing calls without a bot, a plugin, or a driver, see the complete guide to bot-free meeting notes and how to take meeting notes without a bot.

A note on consent

Removing the virtual audio device removes plumbing, not the courtesy. Capturing a call should always be transparent, never quiet — and a setup that installs nothing is if anything less visible to the people you’re talking to, which puts the disclosure entirely on you. Recording and consent laws vary by region: some require only one party’s consent, others everyone’s. Tell participants when you’re capturing a meeting.