win-asio: Add ASIO host for obs-studio

[pkviet]

Description

ASIO is a driver standard developed by Steinberg for low-latency audio. It is commonly used in pro audio.
It was unfortunately not possible for a long time to write a native ASIO host in obs because of license issues.
This has changed thanks to a partnership between the project and Yamaha Steinberg:
https://www.steinberg.net/press/2025/obs-collaboration/
The ASIO sdk is now released under dual licensing, including GPL v3 which is compatible with obs-studio.

Historical aside. When I got involved with obs coding, after working on surround sound support, my first plugin
endeavor was to write an asio source, which was developed eventually in collaboration with Andersama. It was a great learning experience. The ASIO sdk is notoriously tricky with lots of pitfalls for hosts and drivers alike. It was so daunting that at that time (early 2018) we relied on third-party libraries (RTAudio, Bassasio, portaudio) and now JUCE. The last incarnation of our asio plugin for obs (based on JUCE) was mostly coded by Andersama. It has been superseded in many ways by another third-party plugin based also on JUCE, atkaudio which has lot of capabilities but again relies on a third-party library. And anyway our ultimate goal had always been to add support for ASIO into obs.

This PR brings ASIO support in obs-studio natively: no third-party library is used but Steinberg SDK is leveraged directly.
For the host implementation, we have taken cues from JUCE ASIO host which documents a lot of pitfalls.

Our ASIO host provides:

• an asio source where inputs from asio devices can be captured with also channel selection.
• an asio output.

The asio output in turn allows:

• track monitoring with channel selection too,
• a special monitoring track which automatically mixes all monitored sources and can be selected in the asio output.

Technical note

The asio callback processes both audio from host to device and from device to host at the same time. The main difference with wasapi, is that any monitored audio sent to the device is not automatically mixed; it is the responsibility of the host to do the mixing. That is why asio can not be seamlessly integrated into libobs/audio-monitoring and that we resorted to creating an obs-output for asio.
This output is controlled through a frontend plugin which instead of adding an entry into the tool menu (as is customary) is callable from Settings > Audio alongside monitoring devices (wasapi on windows).

Screenshots:

ASIO source

ASIO source with channel selection

ASIO source with device selection

ASIO monitoring integrated to audio settings

ASIO monitoring panel

ASIO monitoring panel with track channel selection. Not the special monitoring track

Motivation and Context

ASIO brings the following advantages:

• low-latency capture,
• low-latency monitoring (the wasapi monitoring has long been a source of user complaints),
• capability to do complex channel routing.

How Has This Been Tested?

Tested on windows 11 pro with several asio devices:

• Steinberg IXO 22
• Steinberg UR22C
• ESI U22XT
• Behringer XR18
• Tascam US-122 MKII
• virtual drivers such as Rearoute from Reaper, Dante virtual card

Testers are welcome to report their results with their interface and I'll update the list.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.

[pkviet]

Update

• Fixed a lot of bugs; thanks to @prgmitchell , indrit (on discord), @WizardCM
• On @WizardCM suggestion, i added a message when a driver fails to load (usually because the device is disconnected,
  or just because of flaky drivers - there's a lot of them in ASIO landscape , or because the ASIO driver is being used by another host.)

[pkviet]

Update 10-19-25
Fixed some bugs with output.
Factored a lot of the input and output functions.
Fixed a bug with drivers which set a different default sample rate than that from obs

[PatTheMav]

I feel like I need to see the code "in action" to better gauge its correctness. I there something like an "ASIO virtual device" or something I can install in my VM and then use this plugin with it?

[pkviet]

General architecture

All the audio processing is done in the own ASIO driver thread, NOT obs audio thread. This ensures the lowest latency.
One big difference with WASAPI is that both input and output buffers are processed concurrently.
On OBS side we need to ensure there is sufficient data to fill the buffers to avoid xruns. This is done through 2 deques, one on the capture side (ASIO Input source) and another on the play side (ASIO Output).
The play deque is filled in the audio thread by OBS with output audio from tracks or from monitoring.
The capture deque is filled in the asio driver thread but delivered to obs on the audio thread at each audio tick (1024 samples usually).
As already explained above, the ASIO driver does no mixing, so it is not possible to push separately all monitored sources; they must be mixed on our side. This is why a special "monitoring" track has been added. When compared with WASAPI, we have as a bonus that the monitored sources have the same sync as in outputs since they are processed in the obs main audio callback at the same time.

The main ASIO SDK issue:

• this old sdk (it dates back to 1996, so pre-historic times) assumes that the host is a DAW and that it will load a single driver at a time.
• conversely, the drivers are also supposed to be single client to minimize latency and not split the processing among several hosts. (A few ASIO drivers fortunately are now multi-client, that is, allow concurrent use by several hosts at the same time: ex: RME or Lynx.)
• As a result of these limitations, it will not in general be possible to open an ASIO interface both in obs and a DAW. Workarounds do exist : for instance use Rearoute virtual ASIO driver, provided by Cockos Reaper.
• The single driver host architecture of the SDK is a big issue for OBS because we need a multi-client host; a setup with a single ASIO device + one virtual ASIO driver such as VB-cable or ReaRoute allowing routing from DAWS, is a reasonable scenario that we need to support.
• We had therefore to work around the ASIO callbacks because they don't pass a 'this' pointer allowing us to identify the ASIO driver. Our solution was to template callbacks, each driver having its own set.

The scanning phase.

The scan just checks the registry to list all installed ASIO drivers.
There is no check at that time of whether a device is actually connected or not.
The SDK has no way for us to check the connection state apart from actually loading the device.
There is then an error message but unfortunately the SDK has no explicit message regarding the disconnected state ...
If a device is erroring during loading, we disable its audio processing. But we don't discard it from the devices list because it could be: (1) the device is being concurrently used by another host, like a DAW; (2) a genuine disconnection, the USB cable being loose ... So obs should stick to the source settings, to allow the user to recover their setup.

The loading phase.

The driver is loaded during the creation phase when a driver is picked by the source.
During this loading some basic tests are done (in asio_device_test function) to ensure the device will stream properly during the real operating.
The driver is then opened (asio_device_open), meaning that all settings are applied, correct sample rate, buffer size, buffers are created... The device is started once all this initialization is done, meaning that processing can start. If audio callbacks are not triggered by the driver within 300 ms, the driver is stopped.

The streaming phase.

The driver calls repeatedly the bufferSwitch callback; this is where the main processing logic is done on our side (asio_device_process_buffer): there we copy the buffers coming from the device into the 'capture deque', and we copy the 'play deque' into the output buffers of the device.

[RytoEX]

Update Renamed asio.h → asio-compat.h to avoid confusion with the Steinberg SDK header.

Clarification There is no vendoring of the ASIO SDK: no SDK headers or source files are copied into the tree. asio-compat.h is a minimal compatibility header that re-declares only the subset of types, enums, and structs required by this implementation (derived from the SDK definitions). The host interacts directly with the IASIO COM interface via its vtable (pure C implementation). The SDK’s C++ wrapper layer and additional components are not used, and including the full SDK would introduce a larger, unused API surface without changing how the driver is accessed.

I guess my question is: why we can't just include asio.h in obs-deps and discard everything else we do not need instead of having a derived version? Are there things in the full header that would cause issues in the implementation in this PR?

[pkviet]

Update Renamed asio.h → asio-compat.h to avoid confusion with the Steinberg SDK header.
Clarification There is no vendoring of the ASIO SDK: no SDK headers or source files are copied into the tree. asio-compat.h is a minimal compatibility header that re-declares only the subset of types, enums, and structs required by this implementation (derived from the SDK definitions). The host interacts directly with the IASIO COM interface via its vtable (pure C implementation). The SDK’s C++ wrapper layer and additional components are not used, and including the full SDK would introduce a larger, unused API surface without changing how the driver is accessed.

I guess my question is: why we can't just include asio.h in obs-deps and discard everything else we do not need instead of having a derived version? Are there things in the full header that would cause issues in the implementation in this PR?

The SDK asio.h can be used, but it requires either patching or adding compile definitions (via CMake) to get correct native types.
I understand the preference for routing third-party material through obs-deps, and I agree with that in general. I did that for vst3 where i do use the sdk extensively (and is typically included in-tree in full by hosts).

But, in this specific case the cost seems disproportionate to what is actually being used. The host only needs a very small subset of ASIO definitions (roughly 130 lines of typedefs / enums / structs derived from the SDK header), and the implementation talks directly to the IASIO COM interface via its vtable. No SDK functions are used.

Moving this through obs-deps would mean just for the sake of a single file:

• adding an ASIO SDK finder
• updating the plugin CMake to consume it
• adding in obs-deps a script to download the sdk zip from Steinberg (there's no github for the sdk)
• staging a release on my fork and adding a commit in the PR just to expose asio.h header until obs-deps picks it up in a release.

That is a lot of extra infrastructure for a very small compatibility layer (130 lines out of 1080) that is already local, documented, and limited to the exact subset used by this plugin.
ASIO is widely deployed across hardware, and the subset used here is very stable, so the risk of breakage from maintaining this minimal definition set is extremely low. The SDK has historically evolved via additive changes rather than breaking ABI changes, as backward compatibility is a critical requirement for broad hardware support. I don't see nor foresee any maintenance burden here.

So from a technical point of view, I still think the local asio-compat.h is the more proportionate solution here. It keeps the dependency surface minimal and explicit, without introducing additional build infrastructure or unused API surface.
I don't use the SDK at all, don't call any functions from it, only the COM interface is used.

[pkviet]

Update
Fixed braces due to new Contributing Guidelines.

[RytoEX]

Nits.

[RytoEX]

Nits.

[RytoEX]

Nit.

[pkviet]

Update

• fixed a series of bugs related to audio output, and swap between devices.
• for audio output, changed the deque to a real circular buffer with atomic accesses.
• the asio audio output relies on obs outputs so it is subject to up to 960 ms of latency; it benefits from the low latency setting in Audio Settings, so I modified the en-US.ini related entry to mention ASIO alongside Decklink.

[pkviet]

Update (August 14, 2026)

• I have made an important architecture change regarding ASIO monitoring. Previously I had added an extra track (so Track 7) to which all monitored sources where automatically streamed. This allowed to have a dedicated track for monitoring. The incentive for that was the fact that the current monitoring API can not be adapted to ASIO because it assumes the audio platform solution (WASAPI, CoreAudio, PulseAudio) will mix all the audio data thrown at it; but ASIO has no such capability. There is however a major drawback which is the audio runs through the main output audio_callback (in obs-audio.c) and therefore can buffer up to 45 audio ticks (960 ms at 48 kHz). And so the main advantage of ASIO with low latency is defeated. Even with the current low latency option (which exists for Decklink outputs for instance), there are at minimum 2 audio ticks so about 40 ms of audio latency.
• I decided to add a new 'monitoring_mix' API to allow the libobs/audio_monitoring to mix monitored sources. Outputs can subscribe to a new raw audio callback 'raw_audio_monitoring' which ticks at 256 samples so about 5 ms.
• I tested against a Yamaha Steinberg IXO 22 sound card. I used a Media Source at 120 fps with an audio burst and a video flash ticking every second and shooted my monitor set to 120 fps with my smartphone camera set at 120 fps. So the resolution for the latency is one video frame so 8.3 ms. I made at least 10 runs of 15 seconds in both WASAPI and ASIO monitoring.
• I found that WASAPI had a latency around 30 - 50 ms, with a latency drifting over time, a fact well-known to OBS users.
• With ASIO, the Yamaha driver was set to a buffer of 128 and a achieved a sub-frame latency (< 8.3 ms) so delay is impossible to spot. I tested also another driver (ESI U22XT at buffer 128) which achieved a latency of about 20 ms against WASAPI (50 -60 ms).