ASIO Device List Not Updating

Hi Jules,

Found a bug when using ASIO; when changing the enablement of a device in the list within ASIO4All’s control panel, the list of usable devices is not being updated within JUCE.

Here’s an input device change example with the demo:
[attachment=1]1. ASIO Device Enablement Change.png[/attachment]
[attachment=0]2. Device list not updated.png[/attachment]

Is the Juce ASIO panel re-opened after making changes to the ASIO4ALL panel?
Have you tried to shut down and re-initialize the AudioIODeviceCallback?

Indeed, I have. Forcibly re-initializing the driver (by switchin it to something else, and back to ASIO) gets an updated list… but that is not appropriate.

(JUCE ASIO panel? You mean the device setup component shown in the demo?)

The component is not at fault; hiding/showing/deleting/recreating sadly won’t make a difference. It’s pretty much how I knew there was something up in the first place.

Well, I must confess I am not too intimate with ASIO in all it’s gory details, but I believe this problem should be located more on the ASIO driver side of things than on the Juce side.
If the driver does not or cannot report changes in it’s configuration Juce will not have a chance of knowing about them.

Have you tried the same procedure with one or more other Software products using ASIO (i.e. some DAWs of your choice)?
Do they show the same kind of behaviour?

[quote]Have you tried the same procedure with one or more other Software products using ASIO (i.e. some DAWs of your choice)?
Do they show the same kind of behaviour?[/quote]

Tracktion aside, yes sir I have - in several. All of them update their lists accordingly. (I don’t loosely say there are problems when I post… not usually :slight_smile: )

Well then, at least Jules will have a more precise picture of it now that those obviouse questions are answered.

Oh, I wasn’t going to suggest you were complaining about a non-problem, I was just trying to get a more thorough set of information with regards of what you did do and what of the results.

To be honest, the answers to those questions are implied. It’s not the first time I’ve posted about issues that are similar/relate to driver wrapper stuff.

Too busy to debug myself right now, but would be useful to know what happens inside asioMessagesCallback() when that property changes…

Figured as much. Looking into it as I’m writing…

Don’t get me wrong, but in reporting bugs, implication never works as intended.
It’s always better to be concise and precise, omit nothing and state the blatantly obvious nevertheless.
E.g., from your first post, I cannot even deduce an implication of temporal order, or whether the Device Setup / Device List control was re-opened after changing the device list of the driver or not.
You may have thought that to be obvious, but it isn’t.

No offense, but I guess everyone gains when error reports are verbose.

Possible, not-really-DRY, solution is as follows:

Place this in ASIOAudioIODevice:

void reloadChannelNames()
    long totalNumInputChans = 0;
    long totalNumOutputChans = 0;

    if (asioObject != nullptr
        && asioObject->getChannels (&totalNumInputChans, &totalNumOutputChans) == ASE_OK)

        int i;

        for (i = 0; i < totalNumInputChans; ++i)
            ASIOChannelInfo channelInfo = { 0 };
   = i;
            channelInfo.isInput = 1;
            asioObject->getChannelInfo (&channelInfo);

            inputChannelNames.add (convertASIOString (, sizeof (;

        for (i = 0; i < totalNumOutputChans; ++i)
            ASIOChannelInfo channelInfo = { 0 };
   = i;
            channelInfo.isInput = 0;
            asioObject->getChannelInfo (&channelInfo);

            outputChannelNames.add (convertASIOString (, sizeof (;

        outputChannelNames.appendNumbersToDuplicates (false, true);
        inputChannelNames.appendNumbersToDuplicates (false, true);

In ASIOAudioIODevice (see last LOC in this block of code):

void timerCallback()
    if (! insideControlPanelModalLoop)

        // used to cause a reset
        JUCE_ASIO_LOG ("restart request!");

        if (deviceIsOpen)
            AudioIODeviceCallback* const oldCallback = currentCallback;


            needToReset = true;
            open (BigInteger (currentChansIn), BigInteger (currentChansOut),
                    currentSampleRate, currentBlockSizeSamples);

            reloadChannelNames(); //ADDITION HERE

Seems I forgot to reply to this; the callback occurs correctly with kAsioResetRequest, and is handled appropriately by starting the timer - eventually calling ASIOAudioIODevice::open(). There’s probably a nicer way of updating the list of devices/channels within that method.

Have hacked something together - let me know if it works!

[attachment=0]It’s Alive.jpg[/attachment]

Alright so with the change in place, I’ve found another bizarre issue: for some reason, after enabling a couple devices in the ASIO4All panel, the settings component in the PluginHost doesn’t let me “enable/check” the newly added items. (The Plugin Host’s settings component’s behaviour allows me to enable multiple devices… Mind you, the problem does not appear in the the JuceDemo, probably because I can only tick one channel pair at a time!)