A few ASIO questions/observations on 4.0-preview (Windows, RME)

[TommiIversen]

Hi ModernMube,

Thanks for OwnAudioSharp, and for taking on the Rust rewrite in 4.0 — really nice to
see it coming together. I'm looking at it for a multichannel recording setup and spent
a bit of time trying the ASIO path on Windows. Ran into a few things, and figured it'd
be more useful to write them down in one place than to keep guessing. Quite possibly
I'm holding something wrong, so feel free to set me straight.

Environment

• OwnAudioSharp 4.0.0-preview.28, .NET 10, Windows 11 (x64)
• RME MADIface (ASIO driver "ASIO MADIface USB"); The RME is working fine right now in TotalMix and in another ASIO host, so the driver/hardware side looks healthy.

1. HostApi.Asio seems to return WASAPI devices
With AudioEngine.Create(HostApi.Asio) + EnumerateInputDevices() I get the same list
as HostApi.Wasapi — the Windows endpoints (stereo "Analog (1+2)", webcams, etc.), not
the registered ASIO drivers like "ASIO MADIface USB". CoreAudio and Alsa correctly
throw "not available", so Asio is accepted but then seems to fall back to the default
host for the listing. Is that expected in the preview, or am I missing a step?

2. 32-channel limit
Channels look capped at 32 (AudioConfig.Validate() returns false above 32, and there's
a Guard.InRange(channels, 1, 32) around the stream config). That's a tricky one for pro
audio — a lot of RME interfaces go well past 32: MADI alone is 64 in / 64 out, and the
larger Fireface/Digiface units expose even more. I think the same 32-channel limit was
around in the 3.1.x line too, so it's not a new regression — just something I'd love to
see lifted with the new engine. Any chance that limit could be made configurable or raised?

3. Couldn't open an ASIO input stream
Through the high-level engine (after OwnaudioNet.Initialize()) with HostType = ASIO,
opening fails with "stream configuration not supported by device (code 3)" for every
channel count I tried, at 48 kHz / F32. Since the enumeration above didn't give me an
ASIO device to inspect, I couldn't tell what sample rate / format / buffer size the
driver actually expects — so this one might just be me not finding the right config.
If you can point me at the intended ASIO capture flow, that'd be a big help.

For what it's worth, WASAPI capture worked without any trouble.

I completely understand ASIO is marked optional/experimental in the preview, so no
pressure at all — mainly wanted to share what I saw and check whether 1 and 2 are things
you'd want to look at.

Thanks again for the work on this!

Cheers,
Tommi

[ModernMube]

Hi!

Thank you for the detailed analysis!
I will look into the problem, there are still many things to fix before the final version.
Please be patient, I will deal with all errors!

[ModernMube]

Hi!

The package with the fix has been uploaded to nuget!
ASIO works in a very unique way on Windows! It always initializes with the default device! The only host is the one in all the public, where you can't solve the on-the-fly device switching! If you want to change the input and output device of ASIO, which in the case of ASIO can only be done together! You have to stop the engine and re-initialize it. You can't use different devices for input and output, unlike with multiple hosts! I wrote this just so that you wouldn't be surprised by the API's behavior!

Channel limit: changed to 256 channels

Device switching only works this way with ASIO!

var selectedDevice = inputDevices[deviceIndex];
Console.WriteLine($"Selecting device: {selectedDevice.Name}");

// Rebuild with the device in the config; ASIO can't switch a running engine.
OwnaudioNet.Stop();
OwnaudioNet.Shutdown();

config.InputDeviceId = selectedDevice.Name;
OwnaudioNet.Initialize(config);
OwnaudioNet.Start();

[TommiIversen]

Hi ModernMube,

I tried preview.35 on the same setup as before (RME MADIface USB, Windows 11, .NET 10), and this is a big step forward - thanks for turning it around so quickly.

What works now

1. ASIO enumeration is fixed. HostApi.Asio returns the actual ASIO drivers ("ASIO MADIface USB", 68 in / 68 out) — no more WASAPI fallback.
2. Channel limit: a 68-channel input stream opens and captures without any tricks.
3. Signal verified, not just frame counts: a 1 kHz loopback test (physical cable from analog out 1 to analog in 1) came back on the right channel with correct content, at basically 100% of expected frames at 48 kHz. Both through the Safe layer and the high-level IAudioEngine.Receives path.
4. The old "code 3" mystery is solved - it was the buffer size all along ("supported range 1024..=1024", the driver's fixed ASIO buffer). With that buffer everything opens, and reading the actual value back via FramesPerBuffer is handy. The device-in-config-before-Initialize() flow works as you described.

One new thing: ASIO output goes silent if opened before the input stream

I tried to narrow this down as far as I could, sitting with TotalMix open while testing:

• Duplex, output opened first: the output callback runs at the expected rate and PollErrorState reports no errors, but nothing reaches the driver - no meters, nothing on the loopback. Capture keeps working fine at the same time.
• Output only (no input stream): plays fine.
• Duplex, input opened first, then output: everything works - the loopback tone round-trips at the expected level.

So "open input before output" is a working workaround. If I'm reading RustAudioEngine.Initialize right it opens output before input when both are enabled, which would also explain why the high-level Send() path was silent for me - but I may well be misreading it, and the real cause could sit deeper in the ASIO buffer handling. Happy to re-test whenever you push something.

Two smaller wishes

Feel free to ignore these - capture is what I needed and that works:

• Driver latencies: as far as I can tell, cpal's asio-sys already exposes Driver::latencies() publicly, it just isn't surfaced through the engine API. Having input/output latency on the device info would let me do proper timestamp compensation on recordings.
• Per-channel names: asio-sys seems to read ASIOChannelInfo internally (which carries the channel name, e.g. "Analog 1" / "MADI 1") but doesn't expose it. RME users navigate by those names, so having them on the device info would be very welcome in multichannel setups.

And one cosmetic thing: the assembly informational version still reports 3.4.0+<sha> on the 4.0.0-preview packages.

Thanks again - from where I sit the Rust engine went from "blocked" to "working 68-channel capture" in one release. Very nice :)

Cheers,
Tommi