[Question] 16 speakers in Windows using AmbiSonics (without HDMI and Receiver)

[RennMekka]

Hello kCat,

Are there any plans to use the full AmbiSonics 3rd order (16 speakers max) with OpenAl-Soft in a way that I can directly route 16
channels from the internal decoder to discrete outputs, let's say 16 ASIO channels on two sound cards?

I don't know how to explain it better, but I want to use up to 16 speakers with the outputs of two ASIO cards. (no Receiver, and also no HDMI)

The only way to move around the Windows 7.1 config (as I see it) would be to directly address the ASIO channels that are available in the system.
So the decoder has to use an algorythm that produces true 16 channels from the internal B-stream, and map them to the channel-table.

But I assume that OpenAL-Soft never support the tool to do the matrix calculations for 16 speakers and the ambdec config file itself.
The "highest" configuration at the moment uses 7.1.4 speakers. The downside of it is that is produces no sound from below.

The idea was that I built my own matrix/rig of speakers (up to 16), but I don't know at the moment how to implement this with OpenAL-Soft.

[kcat]

Hi.

The 16 channels for the 3rd order ambisonic mix that OpenAL Soft uses internally aren't 16 discrete outputs/speaker feeds. It needs to be decoded before being played back, and actually for a proper reproduction of a full 3rd order ambisonic mix, you need more than 16 speakers (you need more speakers than ambisonic channels to properly play it back) and those speakers need to be arranged in a suitable layout to sound good. The internal decoders OpenAL Soft has is for outputting to the supported channel configurations; mono, stereo, quad, 5.1, 6.1, and 7.1 (along with an experimental 7.1.4 output, and an uncommon 3D7.1 setup). It can also decode using HRTF (binaural/headphones), or convert to stereo-compatible UHJ. Alternatively, the ambisonic mix can be output directly without decoding or converting it, but that requires a suitable output API and an external decoder if it's to be listened to.

The primary problem with outputting the internal ambisonic mix on Windows is that WASAPI seems limited to 8 channels for 7.1 output. Which isn't enough for even 2nd order ambisonics that requires 9 channels, let alone the 16 channels for 3rd order. To provide the ambisonic channels to ASIO, you'd need JACK installed as well as a custom build of OpenAL Soft with the JACK backend enabled. Or alternatively, make a build of the latest Git version with the PortAudio backend enabled, which should be able to output to ASIO. You'll need the proper development stuff installed to build OpenAL Soft with support for JACK or PortAudio if you go that route.

If there's free public development headers and such available to build for using ASIO, I can think about maybe creating a backend to use it directly. Or maybe I can enable JACK or PortAudio for future Windows binary builds (lower priority than the normal Windows audio APIs so they have to be expressly selected in the config file) to have a way to output to ASIO. But to reiterate, the ambisonic mix needs to be decoded before being played on speakers, with an appropriate decoder designed for your particular speaker arrangement, regardless of how it gets to ASIO.

[RennMekka]

Thank you for the fast reply!

for a proper reproduction of a full 3rd order ambisonic mix, you need more than 16 speakers (you need more speakers than ambisonic channels to properly play it back)

Oh, then I've got something seriously wrong. I thought that the order defines the amount of speakers directly (3rd order = 3+1^2 = 16 speakers). So the current speaker presets all use 2nd order, but with way less than 9 "channels" as I normally would assume with a hexagonic for example (less than 6). What's the formula for this, how many speakers one can (or has to) address with full 3rd order 16 "channels"?

But to reiterate, the ambisonic mix needs to be decoded before being played on speakers, with an appropriate decoder designed for your particular speaker arrangement

So the problem is not, that I could not talk to ASIO, the problem ist the decoder itself. I thought that the decoder algorythm currently implemented is universal and that I only need a proper *.ambdec file for any kind of speaker matrix, where it defines the angle and distance for each speaker. I just realize, that's not that easy. So you have to write a separate decoder for each output config?

[kcat]

Oh, then I've got something seriously wrong. I thought that the order defines the amount of speakers directly (3rd order = 3+1^2 = 16 speakers).

The order defines the number of channels in the ambisonic signal, but those channels relate to the spherical harmonics of the soundfield, not individual output speakers. Technically the number of ambisonic channels is the minimum number of discrete output feeds necessary to retain the complete soundfield, but it's not good enough for listening to (you can decode to and encode from an appropriate 16 channel layout for 3rd order without loss, but when listened to you'll get audible "holes" in the output where certain directions will have noticeably reduced quality compared to others, because of the way the sound interacts with our ears/brain).

For example, full 1st order ambisonics uses 4 channels ((1+1)^2 = 2*2 = 4), but to play it back properly with full sphere reproduction you need at least 6 speakers spaced out regularly, though it's more common to use an 8-channel cube layout for 1st order. The general rule of thumb is that more speakers provide better reproduction (within reason), which is why even though 6 speakers is suitable for full 1st order, 8 is considered better.

So the current speaker presets all use 2nd order, but with way less than 9 "channels" as I normally would assume with a hexagonic for example (less than 6). What's the formula for this, how many speakers one can (or has to) address with full 3rd order 16 "channels"?

The internal decoders (except for 7.1.4 and 3D7.1) are horizontal only. They ignore the height-related channels which cuts down on the number of ambisonic channels being decoded, reducing the number of output speakers needed for playback. For horizontal-only ambisonics, the channel calculation is order*2 + 1, so 1st order has 3 channels, 2nd order has 5, and 3rd order has 7. In this way, horizontal-only 1st order can be properly played back over a 4-speaker quad layout, for example, which wouldn't otherwise be enough for full 1st order. There's a similar trick to cut down on the number of effective ambisonic channels by using mixed order, which reduces the vertical "resolution" compared to horizontal by dropping some but not all height-related channels (with a speaker arrangement and decoder that properly compensates for their exclusion).

As for figuring out how many speaker outputs you need to properly play back a given ambisonic order, I'm not sure if there's any hard and fast rules to it. Generally more is better, but avoid going overboard.

I thought that the decoder algorythm currently implemented is universal and that I only need a proper *.ambdec file for any kind of speaker matrix, where it defines the angle and distance for each speaker.

The ambdec file is the decoder. It specifies how to take the ambisonic channels produced by OpenAL Soft, and mix them for each output channel on a given output configuration. Currently OpenAL Soft can only handle ambdec files for the supported surround output configurations (quad, 5.1, etc), basically overriding the internal decoder for specific output configurations. If you want something different, you'll need to have OpenAL Soft output the ambisonic mix to an external decoder instead.

I do intend to add the ability to specify more generic output configurations for OpenAL Soft, to allow for decoders that output to a general assortment of channels unrelated to known configurations (e.g. a generic 8-channel output that's not 7.1, or a generic 16-channel output), but it's not possible for now.

[RennMekka]

Thank you for all the detailed descriptions!

I do intend to add the ability to specify more generic output configurations for OpenAL Soft, to allow for decoders that output to a general assortment of channels unrelated to known configurations (e.g. a generic 8-channel output that's not 7.1, or a generic 16-channel output), but it's not possible for now.

3D-surround is moving in that direction anyway. The max config for 3D-Spatial (Dolby, Microsoft) at the moment is 8.1.4.4.
To hear sounds from below and above is crucial in the future of gaming, I believe.
I don't think that it's necessary to have the max configuration, considering the expense/usage ratio, the 6.1.3.3 respectively the 6.1.4.4 should be sufficient (360°/60°=6 speakers, 60° is maximum angle between speakers, and for top and bottom I hope 3 speakers are enough too, because I don't like to mount too many height speakers). Do you think that we can have such a configuration (without HDMI and Receiver) in OpenAL-Soft in the not to near future?

[kcat]

3D-surround is moving in that direction anyway. The max config for 3D-Spatial (Dolby, Microsoft) at the moment is 8.1.4.4.

AFAIK, modes like 8.1.4.4 only work through headphones/virtual surround sound. From what I remember reading, anyway. Setting up bottom/ground/floor speakers would be pretty difficult for most people, likely even more difficult than ceiling speakers, since people sit pretty close to the floor and things like the sofa and end tables would get in the way (either preventing proper speaker placement, or blocking line-of-sight with the speaker). It's a lot easier to simulate it over headphones with HRTF, than using physical speakers.

From a software perspective, the main issue with configurations like that is lack of system support. Most audio APIs don't have labels for bottom speakers so there's no way to properly address them. Some APIs may let you access output channels without position labels, which leaves the order unspecified (there's no way to say which channel is which, leaving it to the user to fiddle with connections to assign them correctly). So far, the only audio API I'm aware of that allows specifying the appropriate bottom channels is the spatial audio extensions for WASAPI (not even base WASAPI can), which OpenAL Soft only has experimental support for.

That said, it wouldn't be hard for OpenAL Soft to at least support it internally. Such a decoder would even be better and more stable than the 7.1.4 one it currently has. But the availability of using it will be very limited.

[ThreeDeeJay]

@kcat I'm also interested in higher ambisonics output, but for storing it in WAV/AMB format via WaveWriter to use an external decoder/player like Virtual Home Theater or maybe just to have a more precise sound field when visualizing it to see if a game's actually using height or checking if there are reversed axes. Like here's a 1OA recording I made a while ago:

UT2004_FuMa_Ambisonics_recording_to_virtual_7.1_binaural_HRTF.mp4

By the way, is it possible to output to multiple backends simultaneously? Because it'd be neat to be able to hear the game audio while we're recording HOA.

Also, I know this is probably far-fetched so I'm not sure if it should be a whole new issue, but how feasible would it be to record into an object-based format? Not necessarily a completely new format, since there's already LAF (someone's working on an OpenAL Soft-based player though we can already use Cavern), IAMF and MPEG-H 3D (which supports HOA though I'm not sure if it's a free format)

make a build of the latest Git version with the PortAudio backend enabled, which should be able to output to ASIO. You'll need the proper development stuff installed to build OpenAL Soft with support for JACK or PortAudio if you go that route.

What would we need to do to get OpenAL Soft to output via ASIO besides compiling with -DALSOFT_REQUIRE_PORTAUDIO=ON?
perhaps this would come in handy?
Nevermind, figured it out: #682 (comment)

If there's free public development headers and such available to build for using ASIO, I can think about maybe creating a backend to use it directly.

Something like this? Apparently it just requires submitting a license agreement though

For ASIO support, download the ASIO SDK from Steinberg at http://www.steinberg.net/en/company/developer.html . The SDK is free, but you will need to set up a developer account with Steinberg.
https://www.portaudio.com/docs/v19-doxydocs/compile_windows.html

[kcat]

By the way, is it possible to output to multiple backends simultaneously? Because it'd be neat to be able to hear the game audio while we're recording HOA.

No, unfortunately. Can't output to multiple devices in one backend either. Best you could do is set up some kind of virtual splitter cable that can forward the samples to the ambisonic decoder device, and passes a copy to another virtual device that outputs to a file on disk. Or maybe recording software like OBS can capture the audio from the app (making sure it doesn't try to remix/upmix/downmix the channels and keeps them as-is in the recording).

Also, I know this is probably far-fetched so I'm not sure if it should be a whole new issue, but how feasible would it be to record into an object-based format?

It would take a fair bit of work. The mixer would have to be redesigned to allow individual sources/source channels to output to their own channels instead of mixing into the main ambisonic buffer, somehow also passing along the position data. Voice/channel limits would also become an issue, something OpenAL Soft hasn't really had to worry about but these object-based audio systems do.

It's something to keep in mind, but until a practical option becomes available, I don't know if the effort would be worth it.

Not necessarily a completely new format, since there's already LAF (someone's working on an OpenAL Soft-based player though we can already use Cavern)

That is extremely interesting. Particularly the point about "A PCM block is created for each second of audio. [...] For object-based exports, extra PCM tracks are used for object movement data." Does that mean the dynamic object positions only update once a second? That doesn't seem correct, given the atmos demo (and that video's conversion/rendering of it) seems to update more frequently/smoothly. Unless the idea is the sound moves over the course of that second, which would make it more practical to deal with, though pose problems for outputting it in real-time. Quick fine movements would be lost, and there may be a delay in the position updates.

Still, LAF looks like a promising format that OpenAL Soft could play back in some fashion, at least (that video mentions it used their "wip audio renderer based on OpenAL Soft", which I'm not sure what precisely that means; a modified OpenAL Soft, or the guts of OpenAL Soft were ripped out and put into something else, or something on top of an unmodified OpenAL Soft?). And though outputting dynamic channels isn't currently practical, OpenAL Soft could output static channel layouts, including esoteric ones like 3D7.1, 7.1.4.4, etc, since it deals with positions instead of labels. And if Atmos and similar formats are known well enough to convert to it to LAF, then... hmm...

Some LAF samples (and/or Atmos samples that can be converted to LAF) would be nice to look at and play around with.

Something like this? Apparently it just requires submitting a license agreement though

Looks like it could be a problem for the LGPL. Or at least a problem for people making their own OpenAL Soft builds that want support for it.

[ThreeDeeJay]

@kcat here's response from the LAF dev:

The updated positions are written to extra PCM tracks, which means, the update frequency is dependent on the sample rate. One such track holds positions for 16 objects (for the next 16 or less, another track is created, and so on), and one update takes 3 samples (X, Y, Z coords with the precision of the selected bit depth). This results in an object update every 48 samples, so 1000 updates every second at 48 kHz, which is 32 times faster than Atmos.

The updates happening every second are related to track availability blocks. They disable PCM export for tracks containing only silence for the next second. Objects playing audio are re-enabled. This saves a lot of space when dealing with hundreds or thousands of objects that rarely play audio.

For a reference implementation of exporting already created playback environments, see LimitlessAudioFormatEnvironmentWriter.cs.

BTW forgot to mention someone else made an object-based audio scene editor/player, also using OpenAL Soft (app+sample, WASD to move, QE for height or enter/exit reverb area) that uses an XML-based format to store metadata for listener and emitter positions over time and even environment effects, which I think would get lost in translation to LAF.

Some LAF samples (and/or Atmos samples that can be converted to LAF) would be nice to look at and play around with.

Here's Universe Fury and Test Tones.
Generally, LAF files are converted from Dolby Atmos (Master or Digital Plus, though not TrueHD), which you can get from here or here and convert to LAF using Cavernize+ffmpeg then you can play it in Cavern

Looks like it could be a problem for the LGPL. Or at least a problem for people making their own OpenAL Soft builds that want support for it.

This person suggests it's ok to distribute binaries with ASIO as long as the SDK itself isn't included (in the codebase or release binaries, I presume), but not according to this GPL project. However, FlexASIO downloads the SDK during CI and after complying with license requests, it seems to be in the clear, though it's (modified) MIT. So are flexible licenses the reason why some projects are allowed to distribute binaries of ASIO-based projects? Or perhaps all it takes is to reach out to Steinberg to get explicit permission while adhering to their license requests?
I found interesting info in other projects like JUCE, jamulus and GrandOrgue.

WASAPI Exclusive might be easier to implement since there's already a proof of concept and fixes, though in my experience, it seems to have similar latency to ASIO, but it's more prone to crackling at low buffer sizes.

BTW Have you looked into WDM/Kernel Streaming? I think it's what ASIO uses so we might as well just cut the middle-man 🤔

[kcat]

@kcat here's VoidXH/Cavern#186 (comment):

Hmm, that seems a bit of an obtuse way to encode the position over time, interleaving it between each sample frame. Seems rather limiting (:P) as well, if you wanted to use proper compression like FLAC or Opus instead of raw PCM samples (which any user-oriented format should handle) since you presumably don't want to compress position vectors and you can't put them between PCM frames when it's compressed like that. Also unfortunate that the format doesn't specify sizes for headers; I guess you just have to hope a custom header won't have the words TAGS or HEAD for some reason (and you have to read all the custom headers, even the ones you don't handle, since you have no way to know where the HEAD marker will appear). There's also no accommodation for ensuring the sample data is aligned, making reading less efficient.

The more I look at it, the less I really like the format without some updates to support proper compression and have more robust structure.

As for playback with OpenAL Soft, it seems the "proper" way to do it would be with a loopback device where you control the number of samples rendered between updates to source positions. Otherwise, the best that can be done is to keep positions buffered as they're read in, and continuously check the source offset and set the proper positions based on the current time being processed for each source. Pretty crude and inexact, prone to late or missed movements, but it's probably good enough for just listening to most things. More sophisticated options for specifying source movement at set times would be needed for being more precise and accurate with normal playback.

This person suggests it's ok to distribute binaries with ASIO as long as the SDK itself isn't included (in the codebase or release binaries, I presume), but not according to this GPL project. However, FlexASIO downloads the SDK during CI and after complying with license requests, it dechamps/FlexASIO#222 (comment), though it's (modified) MIT. So are flexible licenses the reason why some projects are allowed to distribute binaries of ASIO-based projects?

Perhaps. I think it would probably depend on what exactly is in the headers, and whether there's any free/libre alternatives to the official ASIO headers. You can build against non-free headers and still be GPL-compliant, otherwise you couldn't distribute builds of (L)GPL code made with MSVC using MS's headers (the system library exception I don't think says anything about headers, just the DLLs), but MinGW comes with a mostly complete and compatible free/libre alternative to the official C/C++ Windows SDK so users have options to build the project without relying on non-free stuff, even if it's not the same exact/official SDK.

BTW Have you looked into WDM/Kernel Streaming? I think it's what ASIO uses so we might as well just cut the middle-man 🤔

I didn't think that was still a thing after Windows XP. If it is, it's probably internal Windows stuff and not stable (as in API/ABI stable) across versions, and why there are things like ASIO and WASAPI exclusive mode to reduce the overhead and provide a stable interface.

[ThreeDeeJay]

Perhaps. I think it would probably depend on what exactly is in the headers, and whether there's any free/libre alternatives to the official ASIO headers.

Sadly I've looked at several projects and I'm yet to find a FLOSS alternative to ASIO.

You can build against non-free headers and still be GPL-compliant, otherwise you couldn't distribute builds of (L)GPL code made with MSVC using MS's headers (the system library exception I don't think says anything about headers, just the DLLs), but MinGW comes with a mostly complete and compatible free/libre alternative to the official C/C++ Windows SDK so users have options to build the project without relying on non-free stuff, even if it's not the same exact/official SDK.

It seems the key here is Steinberg's license directly conflicting with GPL, like in the case of Audacity:

If ASIO support were distributed in Audacity builds this would either violate Steinberg's licence agreement if the code were included, or conversely would violate Audacity's GPL Licence if the code were withheld. There are persistent rumours of Steinberg opening up licensing, but without any apparent movement.
https://manual.audacityteam.org/man/asio_audio_interface.html

So if FLOSS isn't a viable option, would OpenAL Soft's license allow not including ASIO SDK code/headers in the repo while still providing binaries that do contain ASIO (added only during CI)? Perhaps @dechamps could comment on whether it'd be feasible to add ASIO here like in FlexASIO 👀

I didn't think that was still a thing after Windows XP. If it is, it's probably internal Windows stuff and not stable (as in API/ABI stable) across versions, and why there are things like ASIO and WASAPI exclusive mode to reduce the overhead and provide a stable interface.

ASIO4ALL uses it and supports "any Windows OS since Win98SE". Also it has a C++ API and sample

ASIO4ALL is a hardware independent low latency ASIO driver for WDM audio devices. It uses WDM Kernel-Streaming and sometimes even more sophisticated methods to achieve its objectives.
https://asio4all.org/about/

Audio Repeater can also use Kernel Streaming to get low latency when using a virtual audio device for HeSuVi

[dechamps]

The primary problem with outputting the internal ambisonic mix on Windows is that WASAPI seems limited to 8 channels for 7.1 output.

I don't think that's true. I remember dechamps/FlexASIO#100 from a few years back where it was demonstrated that WASAPI is able to open a 10-channel output device just fine, and you can check that for yourself using emulated software WDM drivers such as Virtual Audio Cable. IIRC that is true even in shared mode, as long as the channel count is correctly configured in the Windows control panel settings for the audio device.

Of course, the bigger issue is that actual WDM audio devices that expose this many channels seem to be extremely rare - most many-channel audio interfaces typically expose pairs of channels as Windows audio endpoints, such that you end up with N/2 stereo endpoints, not a single N-channel endpoint. With these devices, typically the only way to get them to expose a single device with N channels is to use ASIO.

Or maybe I can enable JACK or PortAudio for future Windows binary builds (lower priority than the normal Windows audio APIs so they have to be expressly selected in the config file) to have a way to output to ASIO.

I would strongly recommend against enabling ASIO support in PortAudio due to PortAudio/portaudio#696. Especially in a library. You would run the risk of compromising the integrity of the application process, even if the user does not intend to use ASIO at all. I would strongly recommend using ASIO directly instead, without going through PortAudio.

BTW Have you looked into WDM/Kernel Streaming? I think it's what ASIO uses so we might as well just cut the middle-man

It's not really correct to say that "ASIO uses WDM/KS". Some ASIO drivers may be implemented using WDM/KS internally (most notably ASIO4ALL and FlexASIO in WDM/KS mode, but it's conceivable some manufacturer-specific ASIO drivers do that as well), but there is nothing stopping anyone from developing an ASIO driver that interfaces with the hardware in a completely different way.

BTW Have you looked into WDM/Kernel Streaming?

I didn't think that was still a thing after Windows XP.

It is definitely still a thing - it is what the Windows Audio Engine (which runs in user mode) uses to talk to the underlying WDM audio device driver. It forms the interface between user mode and kernel mode for audio.

If it is, it's probably internal Windows stuff and not stable (as in API/ABI stable) across versions

It's complicated. Nowadays, Microsoft mostly sees WDM/KS as the interface between the Windows Audio Engine (i.e. WASAPI) and the WDM audio device driver. Microsoft does not advertise nor recommend WDM/KS as an application API, but in practice there is nothing stopping an application from using WDM/KS directly. I doubt Microsoft will break applications using WDM/KS, because that would mean breaking ASIO4ALL, which is quite popular, therefore such a move would piss off quite a lot of Windows users.

The WDM/KS ABIs are documented and very stable, because it is the ABI that WDM audio device drivers have to implement. Microsoft cannot break these ABIs without breaking audio drivers. That said, there have been cases in the past where Microsoft introduced new WDM/KS "modes" (the most prominent example being WaveRT, introduced in Vista), and over time new WDM audio device drivers dropped support for pre-Vista and ended up only supporting WaveRT, breaking any WDM/KS client code that did not support WaveRT. These things take many years to happen though.

BTW Have you looked into WDM/Kernel Streaming?

I wouldn't recommend attempting to write a WDM/KS client. WDM/KS is an atrociously complicated and error-prone API with lots of device-specific sharp edges (e.g. workarounds for driver bugs) that require extensive hardware testing to sort out. To give an idea, the PortAudio WDM/KS client is 7 KLOC and despite that is still quite buggy/unreliable. I would strongly recommend using WASAPI Exclusive instead, which is basically just a wrapper around WDM/KS in practice (I mean that quite literally - if you use WASAPI Exclusive, your app ends up making WDM/KS calls directly from the application process behind the scenes).

So if FLOSS isn't a viable option, would OpenAL Soft's license allow not including ASIO SDK code/headers in the repo while still providing binaries that do contain ASIO (added only during CI)? Perhaps @dechamps could comment on whether it'd be feasible to add ASIO here like in FlexASIO 👀

I am not a lawyer so am just speculating here, but my understanding is you are bound to Steinberg licensing terms as soon as you use the ASIO SDK in any way. I believe one possible way to work around that could be to not use the ASIO SDK at all but instead enumerate and call ASIO drivers directly. My understanding (again, I am not a lawyer) is that this is protected activity in many legal jurisdictions, where providing interoperability is a valid legal excuse for using APIs you don't own (see also this famous case). I know of several ASIO Host Applications that do not use the ASIO SDK anywhere in their build process: they just enumerate drivers in the same way the ASIO SDK would (it's basically just listing some entries in the Windows Registry), and then instantiate ASIO driver COM classes directly and call the relevant methods using their own declarations in their own headers. NAudio is one such example. This is not particularly difficult to do: the code in the ASIO SDK is very small and trivial to reimplement.

[kcat]

I am not a lawyer so am just speculating here, but my understanding is you are bound to Steinberg licensing terms as soon as you use the ASIO SDK in any way. I believe one possible way to work around that could be to not use the ASIO SDK at all but instead enumerate and call ASIO drivers directly. My understanding (again, I am not a lawyer) is that this is protected activity in many legal jurisdictions, where providing interoperability is a valid legal excuse for using APIs you don't own (see also this famous case).

Yeah, as far as I understand (also as a non-lawyer), APIs aren't copyrightable. As long as new headers and such can be created in a clean room manner, whatever license there may be with the original SDK isn't relevant to code that doesn't use it and uses clean alternatives instead. And projects like wineasio provide a FLOSS driver implementation that the headers would provide access to, so it wouldn't be the case that the interface could only be used for proprietary/closed source implementations either.

What could be an issue is using the ASIO names/trademarks where not otherwise necessary, though. MESA used to have a similar issue, where even though they were effectively an OpenGL implementation, implementing their own headers and libs with gl* functions and GL_ macros as needed for API/ABI compatibility, they couldn't actually say they were an OpenGL implementation without permission by the trademark holder (which needed certification). So I could likely add an ASIO-compatible host backend, but I don't know how far I could go in calling it an ASIO backend without permission.

I know of several ASIO Host Applications that do not use the ASIO SDK anywhere in their build process: they just enumerate drivers in the same way the ASIO SDK would (it's basically just listing some entries in the Windows Registry), and then instantiate ASIO driver COM classes directly and call the relevant methods using their own declarations in their own headers. NAudio is one such example. This is not particularly difficult to do: the code in the ASIO SDK is very small and trivial to reimplement.

That is informative, and may help me implement my own interface header. Having sample code that uses the API to play/record audio would be helpful too (I tried looking at PortAudio's source, but I couldn't find the code for their ASIO backend).