Synchronous Audio Router: Windows application audio locked to your ASIO interface

The difference is a shared clock, not a longer buffer

Synchronous Audio Router is a Windows audio driver that routes application audio through your digital audio workstation software. The project description is one line, low latency application audio routing for Windows, and the homepage is sar.audio.

Its distinguishing claim is about clocking, and it is worth being precise about why that matters. Ordinary virtual audio cable software presents itself to Windows as an audio device with its own timing. That device has its own clock, and your physical interface has a different one. Over a long session the two drift, and the symptom is the classic one: a recording that was fine for ten minutes slowly slides out of sync with the audio it was supposed to sit against, with buffer underruns appearing along the way.

The fix in this design is to synchronise all virtual audio streams to the physical audio interface. Every virtual stream shares the hardware clock, so nothing can drift relative to anything else. The README lists that as the first of its unique characteristics, and the other characteristics follow from the same premise: the virtual streams are mapped to a single multichannel ASIO interface which also includes all channels from the physical device.

So this is not a general purpose virtual audio device. It is a bridge whose job is to make Windows application audio and hardware audio agree on time, because the whole point is that they will be recorded together.

Endpoints as channels, not as extra devices

The second characteristic is about how the virtual devices appear in Windows, and it is a design decision with real consequences for a working setup.

Instead of exposing one fixed device, Synchronous Audio Router allows dynamic creation of an unlimited number of Windows audio devices with custom names. The README makes the point that you get exactly as many endpoints as you need with no useless names of the Line 6 type.

The mapping runs in both directions and it is easy to get backwards if you do not read carefully. Playback endpoints allow Windows applications to play sound and show up as corresponding input channels on your ASIO device. Recording endpoints allow Windows applications to record output sound and correspond to ASIO output channels.

The channel layout in the ASIO device follows from that. The first ASIO channels are the physical ones from the underlying ASIO driver, and the remaining channels are mapped to the virtual endpoints. So the DAW sees the hardware inputs at the front of the channel list and the virtual devices stacked after them.

In the DAW, the new channels have to be enabled explicitly. Most DAWs have a dialog or a dropdown where you select which channels to use, and if a channel is not enabled there, it will not appear on the mixer even though the driver is exposing it.

Per-app routing is the feature that removes a driver hack

The third characteristic solves a problem that is usually solved badly. Some applications do not let you choose an audio device, so the only way to capture them is to change the Windows default playback device, which breaks every other application in the process.

This driver offers per-app override of the Windows default audio device for exactly those applications. Regex matching lets you set rules for many applications at once, and the example given is routing every app under your steamapps directory to a specific endpoint. That is the kind of rule that makes a multi-application recording session possible without touching the system default each time.

A rule that sends anything under steamapps to endpoint 3 is a more reliable approach than switching the default device back and forth, because it does not depend on the order in which you start things and it does not affect the audio of the programs you did not intend to capture.

The same idea works in the other direction for applications that record rather than play, which is what the recording endpoints are for. A voice chat application, a screen recorder or a browser tab that captures system audio can each be pointed at a recording endpoint, and the corresponding audio lands on an ASIO output channel in the DAW where it can be recorded alongside everything else.

WaveRT, 1 to 2 ms buffers, and why the DAW latency is untouched

The low latency claim comes with a specific mechanism rather than a number, and the two halves of it matter separately.

First, the transport. The README states that since SAR is synchronous with the hardware audio interface and uses WaveRT to transport audio to and from applications, it does not impact your DAW's latency. This is the point of the design. A virtual cable that runs its own timing path adds a buffer and a resampling stage between the application and the recorder, and that is latency you cannot remove. Here the application stream is not on a separate path at all, it is on the hardware clock, so there is nothing extra to pay.

Second, the consequence. Because of that, the README says it is practical to use 1 to 2 ms buffer sizes on a cheap USB 2.0 interface. That is an unusual claim. USB 2.0 interfaces are not known for reliable low latency, and a claim about them should be read as a statement about what the driver does not add rather than a promise about the hardware.

The UI is deliberately minimal for the same reason. The DAW is expected to do all the hard work of audio processing, so SAR does not include a complicated mixer interface or extensive configuration options. The configuration surface is a small dialog: pick the ASIO driver for your physical device under Hardware Interface, add endpoints, and enable the corresponding channels in the DAW. There is no mixing, no gain staging, no routing matrix beyond the endpoint creation, because all of that belongs in the DAW where the user already knows how to do it.

Configuration, the admin requirement, and endpoint lifetime

After installation nothing happens immediately, and the project is explicit about that, because the driver only becomes real when the DAW is running.

There are three ways to reach the configuration dialog. The first is to start the DAW, open its audio configuration settings, select the Synchronous Audio Router ASIO driver and open the ASIO configuration dialog, and the instruction notes that for the beta build the DAW should be started as admin. The second is the SAR Configuration tool in the Windows start menu, available from version 0.13.99.1 onwards. The third, for earlier versions, is to get asioconfig and choose Synchronous Audio Router from it.

The admin requirement comes back later. If you get errors initialising the SAR ASIO driver, make sure the DAW is running as admin, which is required by the beta build, or if you chose the Require Administrator privileges to access SAR option in the installer.

The lifetime rule is the one that catches people out. The endpoints created by SAR are only active while your DAW is running and has started ASIO, and they are automatically disconnected when the ASIO driver is closed. If you are using REAPER, the fix is to disable the Close audio device when stopped and application is inactive option in the Audio preferences.

Unsigned prereleases, Secure Boot, and the 2021 release line

Two platform constraints will decide whether the driver loads on your machine at all.

The first is code signing. Prereleases of SAR are unsigned, and the project states that it is required to enable the testsigning boot option to make Windows load the driver, otherwise the driver will not be loaded. Enabling test signing puts the machine into a mode where the operating system accepts drivers signed by an untrusted certificate, which is a deliberate reduction in security that a general purpose machine should not carry permanently.

The second is Secure Boot. The system requirements say Windows 7 or later, and that if you are running a current version of Windows 10, Secure Boot is not supported. Secure Boot and test signing are in direct conflict on a single machine, so the combination decides which of the two you keep. There is also a Windows 7 specific note: you must have the KB3033929 update installed before installing SAR, or you will get an error about an unsigned driver.

The release history is the third factor, and it needs stating plainly. The most recent tagged release is v0.13.2 from 2021-01-22, before that v0.13.1 from 2018 and v0.13 from 2017. The repository is not archived and the last push was on 2026-10-03, so work continues on the source, but a user installing the latest tagged build is running code from five years ago, and the configuration tool referenced in the instructions at version 0.13.99.1 sits above that tag, which means the instructions describe a build that is not in the release list.

The licence is GPL-3.0, with COPYING.txt and COPYING-V2.txt in the repository root, so the source is available and the driver can be inspected.

The source layout shows how a Windows audio driver is built

The repository is a Visual Studio solution, SynchronousAudioRouter.sln, with the components split into directories that map to the distinct parts of a driver.

SarAsio is the ASIO driver side, which is what the DAW talks to. SarConfigure is the configuration tool with the endpoints dialog. SarCtl is the control component. SarInstaller and SarInstallerActions handle installation and the options, including the Require Administrator privileges setting. SarWeb holds web related resources including the endpoint configuration image the documentation shows. RioPing and nm_ping are the ping tools, which is how the driver measures round trip latency to the hardware.

There is a BUILDING.md for compiling from source, a deploy.sh script for deployment, and an Examples directory with a REAPER example, which tells you the intended reference workflow.

The source is published and the licence is copyleft, which is unusual and useful for a driver. Most audio drivers on Windows are closed binaries from a hardware vendor, and the people who write them are the only people who can fix them. A GPL driver whose source is in the repository, with the ping tools included so the timing behaviour can be measured rather than assumed, is a considerably better position for anyone who needs to understand why the routing is behaving the way it is.

Editorial conclusion

Synchronous Audio Router is the right pick for a musician who records application audio, a game stream, a voice chat or a browser tab in a DAW and keeps losing sync to a plain virtual cable, because the driver locks every virtual stream to the physical interface clock instead of running a separate clock, and it suits a setup where the DAW is always running; it is the wrong pick if you need a general audio device for ordinary system sound, if you are on Windows 11 with Secure Boot, or if you will not run the DAW as administrator, and before you install a prerelease you should plan for the testsigning boot option because those drivers are unsigned.

Frequently asked questions

Official sources

1. eiz/SynchronousAudioRouter on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases