Home / Guides / Does AudioRoute need ASIO? (Windows)
Does AudioRoute need an ASIO driver on 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.
Why AudioRoute doesn't need ASIO
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.
Where ASIO does matter (your DAW, not us)
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.
Two situations where ASIO does complicate things
There are two distinct cases worth pulling apart, because they look similar at first but actually need different solutions.
Situation A — the source app is using ASIO in exclusive mode
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.
Situation B — your audio interface only exposes an ASIO driver, with no WDM/WASAPI multi-client
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:
- AudioRoute can still capture those apps just fine — their audio is still going through the Windows mixer (just routed to the wrong physical output), and WASAPI loopback taps the mixer regardless of where it's heading.
- AudioRoute alone does not get that audio playing through your ASIO-only interface. AR has no Windows-side playback device; it can't push audio out to your monitors directly. To hear browser/Spotify audio on the interface, you need a separate tool (see "media-player ASIO renderers" and "virtual ASIO/WASAPI drivers" below).
- The DAW-routed workaround is real but situational. Inside Cubase you can insert AudioRoute Capture FX on a track, enable monitoring, and the captured audio gets routed Cubase → ASIO → interface → monitors. Works, but only while Cubase is open with the plug-in instantiated, and you'll need to mute the Windows-default fallback output (usually laptop speakers) to avoid hearing it twice.
Bridge tools — two categories
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:
Virtual ASIO/WASAPI drivers (for Situation A — capturing from ASIO-exclusive sources)
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.
- Voicemeeter (Banana or Potato) — full virtual mixer with ASIO and WASAPI inputs/outputs. The most flexible, also the most setup. Free / donationware. (See our honest Voicemeeter comparison.)
- ASIO Link Pro — bidirectional ASIO routing with a WASAPI bridge mode. Designed for pro-audio multi-app workflows. Free.
- VB-Audio Virtual ASIO / Virtual Cable — lighter-weight, focused on the bridge function. Free / donationware.
- Sonarworks SoundID Reference includes a virtual driver that handles WASAPI ↔ ASIO conversion if you already own it for room correction.
Media-player ASIO renderers (for Situation B listening — not for AudioRoute capture)
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.
- Coffeeholic ASIO Renderer — the leading example. Works with PotPlayer, MPC-HC, MPC-BE. Free.
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.
Which apps and interfaces fall into which case?
| 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.
FAQ
I have a single-client ASIO driver (RME, Focusrite, MOTU, generic ASIO4ALL). Does AudioRoute conflict?
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.
I have a Yamaha/Steinberg interface on driver 2.1.9 (URX44, UR series, AXR4). Can AudioRoute play system audio through my interface?
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.
Does AudioRoute require Windows 10 specifically because of WASAPI Process Loopback?
Yes — WASAPI Process Loopback shipped in Windows 10 version 1903 (May 2019 Update). AudioRoute requires that version or later. Windows 11 works fine.
Will adding multi-client ASIO support to AudioRoute help anything?
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.
Can I capture from another DAW playing back with ASIO without a bridge tool?
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.
Does this differ on macOS?
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.
Related guides
- Record system audio on Windows — the basic capture workflow, no DAW required.
- Bit-perfect system audio capture on Windows — the technical deep-dive on WASAPI Process Loopback's bit-identical properties.
- AudioRoute vs Voicemeeter — comparison covering where each tool fits, including the ASIO-bridge use case.
- How AudioRoute works under the hood — daemon, tap, ring buffer, plug-in path.
Got a Windows ASIO setup we should know about?
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