Home / Guides / Does AudioRoute need ASIO? (Windows)
Short answer: no. AudioRoute captures system audio on Windows via WASAPI Process Loopback — a Windows 10+ API that taps the per-process audio mixer directly. That path is completely independent of ASIO. Any standard ASIO driver on your interface works fine. The one edge case — capturing audio from an app that's holding ASIO in exclusive mode — has a simple workaround documented below.
Most "capture system audio on Windows" tools (Voicemeeter, BlackHole-style virtual cables, Stereo Mix, hardware loopback cables) work by inserting themselves somewhere into the playback chain. They depend on driver-level cooperation, and ASIO multi-client support determines whether they can coexist with your DAW.
AudioRoute takes a different route. The Windows daemon uses WASAPI Process Loopback, a Windows 10 (version 1903 and later) and Windows 11 API that taps the per-process audio session inside the OS audio mixer. It reads what each application is sending to the mixer, before the audio is routed to a specific output device. That tap happens entirely in the WASAPI subsystem — ASIO doesn't enter the picture at all.
Translated: you can have a single-client, basic ASIO driver on your audio interface (or no audio interface at all, just the on-board system speakers) and AudioRoute's capture works exactly the same. There's no shared resource for ASIO to contend over.
ASIO matters on the output side of the chain — your DAW (Cubase, Live, REAPER, Studio One, FL Studio, etc.) talks to your audio interface via whatever ASIO driver it normally uses, for low-latency monitoring and disk recording. That ASIO connection is between the DAW and the hardware. AudioRoute slots into that chain as a VST3 plug-in on a track, which means it inherits whatever the DAW already does for audio I/O. We don't open our own ASIO connection.
The full chain on Windows looks like this:
┌─────────────────┐
│ Browser/Spotify │ ← what you want to capture
│ Discord/games │
│ etc. │
└────────┬────────┘
│ WASAPI shared (the Windows mixer)
▼
┌────────────────────────────────────────┐
│ Windows Audio Engine (mixer) │
│ │
│ AudioRoute daemon ◄── WASAPI Process │
│ reads here Loopback │
└────────┬───────────────────────────────┘
│ named-pipe IPC + shared memory
▼
┌─────────────────┐
│ Your DAW │ ← AudioRoute Capture (VST3)
│ + AR plug-in │ reads the daemon's audio stream
└────────┬────────┘
│ ASIO (your existing driver)
▼
┌─────────────────┐
│ Audio interface │
└─────────────────┘ASIO is on the bottom arrow — DAW to hardware. WASAPI loopback is on the top arrow — apps to mixer. Different worlds, no shared resource.
There are two distinct cases worth pulling apart, because they look similar at first but actually need different solutions.
Examples: a second DAW playing back through its ASIO output, certain pro-audio standalone apps that grab ASIO directly to avoid the Windows mixer's resampling.
ASIO exclusive bypasses the Windows audio graph entirely — including the WASAPI mixer that loopback taps. So if the source you want to capture never touches the mixer, AudioRoute's loopback can't see it. This isn't a multi-client driver issue; it's an architectural property of ASIO exclusive mode, and the same blind spot exists for every system-audio capture tool on Windows. The fix is a virtual ASIO/WASAPI driver (see below) that re-exposes the ASIO stream as a WASAPI source so the mixer (and therefore AR) can see it.
This is the case Yamaha/Steinberg interface owners ran into starting with driver build 2.1.9 (URX44, UR series, AXR4 and similar). The interface accepts an ASIO client (your DAW) just fine, but it isn't registered as a Windows playback device, so Spotify / browsers / Discord / Windows Media Player can't play through it natively. They fall back to whatever Windows does see as a default output (usually the laptop's internal speakers).
Three things follow from that:
The phrase "ASIO bridge" gets used for two different kinds of utility, which solve different problems. Picking the wrong category is the most common stumbling block, so it's worth being explicit:
These install a driver that exposes itself as both an ASIO endpoint and a WASAPI-visible device. The source app sends audio to the virtual ASIO side; it surfaces on the WASAPI side; AudioRoute's loopback captures from there.
These are plug-ins that integrate inside specific DirectShow-based media players (PotPlayer, MPC-HC, MPC-BE) and replace the player's output stage with a direct ASIO path. They bypass the Windows mixer entirely so the player can talk to an ASIO-only interface for bit-perfect listening.
Important caveat: because these renderers bypass the Windows mixer by design, audio playing through them is not visible to AudioRoute's WASAPI loopback. They solve listening on ASIO-only interfaces; they do not enable AR to capture from the player. If you want both — hear PotPlayer audio on a Yamaha URX44 and record it via AR — you'd want a Voicemeeter-style virtual driver setup instead, where audio surfaces on both sides at once.
| What you're capturing | Path it uses | Captureable by AR? |
|---|---|---|
| Browsers (Chrome, Firefox, Safari, Edge) | WASAPI shared | ✓ Yes |
| Spotify, Apple Music, Tidal desktop apps | WASAPI shared | ✓ Yes |
| YouTube / streaming sites | WASAPI shared | ✓ Yes |
| Discord, Zoom, Teams, Slack calls | WASAPI shared | ✓ Yes |
| Games | WASAPI shared / DirectSound | ✓ Yes |
| OBS, Streamlabs | WASAPI shared | ✓ Yes |
| VLC, mpv, foobar2000 (default) | WASAPI shared | ✓ Yes |
| PotPlayer / MPC-HC running Coffeeholic ASIO Renderer | ASIO direct (mixer bypassed) | ✕ No — switch player to WASAPI to capture |
| Second DAW playing back via ASIO exclusive | ASIO (exclusive) | ⚠ Virtual ASIO driver required (Situation A) |
| Standalone pro-audio apps grabbing ASIO directly | ASIO (often exclusive) | ⚠ Virtual ASIO driver required (Situation A) |
| Anything, on a Yamaha/Steinberg interface with the ASIO-only driver | WASAPI shared (still works for capture; just doesn't reach the interface for listening) | ✓ Yes for capture; see Situation B for listening |
In practical terms: almost everything an "I want to capture this into my session" workflow targets is on the green-tick side. The amber rows are real but narrow; the red row is a configuration choice the user makes inside their media player.
No. AudioRoute doesn't open an ASIO connection on Windows. Your DAW uses ASIO via the same driver it always has; AudioRoute lives next to that chain via WASAPI loopback. No contention.
No — AudioRoute has no Windows-side playback device. Your interface accepting only ASIO is an architectural choice by the vendor that AR can't work around on its own. To hear browser/Spotify audio through the interface you need a tool from the "virtual ASIO/WASAPI drivers" or "media-player ASIO renderers" sections above. AudioRoute can still capture those apps' audio (because they're playing to the Windows mixer, even if the wrong physical output) and feed it into your DAW; that's a separate, complementary problem.
Yes — WASAPI Process Loopback shipped in Windows 10 version 1903 (May 2019 Update). AudioRoute requires that version or later. Windows 11 works fine.
For the capture side, no. Our capture path is WASAPI-based; adding ASIO would be a parallel architecture for a small audience (Situation A above), and Voicemeeter / ASIO Link Pro / similar virtual drivers already solve that case well. For the listening side on ASIO-only interfaces (Situation B), an AR-side virtual ASIO output is a more interesting idea — we don't have it on the roadmap today but if there's clear demand we'd look at it.
Not directly — if the second DAW is using ASIO exclusive (most ASIO drivers default to exclusive), the audio never enters the Windows mixer where loopback can see it. Install a virtual ASIO/WASAPI driver from the list above, or switch the source DAW to WASAPI shared mode in its preferences if it supports that.
Yes — macOS doesn't have ASIO at all. AudioRoute on Mac uses Apple's Core Audio process taps API, which works regardless of the audio interface and doesn't have the equivalent edge case. ASIO is a Windows-only concern.
If your interface or workflow doesn't fit the picture above — multi-client / single-client driver behaving unexpectedly, an app using ASIO that we should add to the table, a bridge tool that worked or didn't — we want to hear it. Drop us a line and we'll update this guide.
Email support Back to guides