WASAPI exclusive or ASIO devices have no input channels; why?

I’m working on using JUCE as the implementation of a P/Invokable DLL to be used from a Unity app. So I’m familiarizing myself with AudioDeviceManager, AudioProcessorPlayer, and AudioProcessorGraph as my main DLL is not going to be a ContentComponent (e.g. no UI). I’m just using JUCE as a sound engine basically.

I have a modified version of the “Processing Audio Input” JUCE tutorial that works with the Windows Audio (e.g. default) device, using an AudioProcessorGraph for the input-to-output routing. This all runs fine on my FocusRite Scarlett 2i2 external USB interface:

But it has minimum latency of 144 samples and I can hear audible latency when tapping the mike. So I wanted to try both WASAPI exclusive mode and ASIO.

I did that in this branch:

The problem is that with either “Exclusive” or “ASIO” as the matchString (e.g. as the selected device), I get a maxInputChannels of 0. It’s as though neither WASAPI Exclusive nor ASIO devices can connect to the inputs, or even detect that there are any.

TL;DR: why would WASAPI normal mode show two input channels, but WASAPI exclusive and ASIO both show zero?

Thanks for any info whatsoever,
Rob

Following myself up: I finally downloaded Ableton Live Lite and verified it was able to use ASIO just fine. So I properly debugged my way through the JUCE code and wound up finding the problem with no input channels being available:

Hope it makes sense, happy to discuss :slight_smile:

I went back and edited some unnecessary detail from the post above for clarity.

Cheers!

Can you try building with this commit from a couple of days ago? If I’m understanding your issue correctly it should be fixed with this change as the default input device name won’t be added to the AudioDeviceSetup if you haven’t requested any input channels so the audio device will be recreated as expected in the initialiseWithDefaultDevices() call.

@ed95 I agree that would address my issue. But what about the case of calling initialiseWithDefaultDevices with a different number of channels than currently exist? What should the behavior be in that case?

With my PR, doing so will recreate the device along with the correct inputChannels and outputChannels values in the AudioDeviceManager. But as of the commit you linked, it looks like that won’t happen, and num{In,Out}putChansNeeded will wind up out of sync with the values in {in,out}putChannels.

Am I wrong? In general initialization / lifecycle is some of the toughest aspects of an API to document and implement, so maybe the answer is “that’s not expected to work” or “you should close the device manager first” or something?

This commit on the develop branch will ensure that the input/output channels are updated whenever the setAudioDeviceSetup() method is called, and should ensure that they are always kept in sync.

Can you test it out and see if it fixes your issue?

Yes, it fixes my issue. I’ll abandon my PR and include a link to this thread. Thanks so much, glad this feedback helped the product! I’ll try to debug future issues to this level as well.

Cheers!

1 Like