Where's My Device, ASIO?

Hi Jules,

Several DAWs I use let me enable/disable devices straight from the ASIO4All panel (opening them right away when enabled, and closing them right away when disabled)… And so I would like to point out that with the “extra” JUCE applications, toggling devices to an “enabled” state doesn’t always “open” them, leaving one or many recently enabled devices in an “Idle” state (and therefore not showing up in the “active input/output channels” lists of a AudioDeviceSelectorComponent).

The solution is to switch to another driver, and back to ASIO, to get the device to finally appear…

Here’s an example with the PluginHost.

The debug Output window gives me the following when this situation happens:

ASIO: error: create buffers 2 - Invalid Mode
ASIO: error: create buffers 2 - Invalid Mode
ASIO: error: Can't create i/o buffers - Invalid Mode
ASIO: error: Can't create i/o buffers - Invalid Mode

Messing with the code; it seems the device needs to wholly reopen every reset request to avoid this.

But, another related issue arises: the BigInteger objects used to present active input and output channels don’t get updated in the AudioDeviceManager… where they need to at least reflect the loss of devices. (otherwise things like a Graph still get the wrong number of inputs and/or outputs!)

Here’s a possible series of changes that you can make in order to get the most current list of available channels from ASIO: [diff].

(Ignore the extra semi-colon)

Much obliged! Will have a look at this today…

Dear @jrlanglois

I have posted an issue that was very similar to yours:

Unfortunately the diff you posted here has long since expired. I wonder if you could share any further detail of what did/didn’t work for you solving your issue?

Can you recommend any routes I could try to solve our issue?

Thank you :slight_smile:

Seeing that this is a 7 year old post and that I’ve long since cleaned up my forks, I won’t be able to provide more useful context…

My issue in this particular post looks different than yours though. In here, the device enablement state wasn’t set up properly, therefore the ASIO wrapper wasn’t configuring itself properly. This is in the context of using Asio4All.

Your post appears to be a driver specific thing entirely.

No problem, thank you for your response :slight_smile: