ASIO call to reloadChannelNames eats up memory, crashes computer


#1

Running the Juce Plugin Host on Windows 10, using the 2nd Gen Scarlett series interface with focusrite 2.3.4 driver/software with ASIO driver selected, if the device becomes disconnected from the computer(either powered down or physically unplugged), a call to reloadChannelsNames() will crash the computer.

In this block of code from juce_win32_ASIO.cpp:

    void reloadChannelNames()
    {
        if (asioObject != nullptr
             && asioObject->getChannels (&totalNumInputChans, &totalNumOutputChans) == ASE_OK)
        {
            inputChannelNames.clear();
            outputChannelNames.clear();

            for (int i = 0; i < totalNumInputChans; ++i)
                inputChannelNames.add (getChannelName (i, true));

The call to getChannels succeeds but somehow leaves the totalNumInputChans and totalNumOutputChans unset or sets them to crazy numbers.

I’m guessing this is a focusrite bug, but is there some way to avoid this issue?


#2

We could check that they are less than, let’s say, 256?


#3

Yeah, that would probably do the trick.

For some reason, even though these variables are initialized to 0 to begin with, reinitializing them before the getChannels call avoids the issue. Unclear to me why or what’s happening here.


#4

Well that’s probably it then: totalNumInputChans, totalNumOutputChans could have been non-zero when reloadChannelNames is invoked.

I’ve just fixed this on develop with commit 4ebfb32. As I don’t have the hardware (2nd gen Scarlett), can you check if that commit fixes the bug or if a channel-count-is-sane check is still necessary?


#5

Hi Fabian,

I tested the changes on develop and it doesn’t actually make a difference. I think given that its retrieving random channel counts, sometimes it works out and sometimes it doesn’t. Also, it seems to mostly work correctly when I run it in debug mode. So, I think was just mistaken that reinitializing would fix it.

I think there’s some other issue around refreshing the connection to the interface within the JUCE code. I’ve noticed this in general, though it doesn’t typically crash the computer, on both OSX and Windows, when the device becomes disconnected the selected device in the audio settings does not update to <none>. And if you turn the interface back on, the device remains selected but is not actually connected. In order to reconnect you have to toggle between <none> and the device.

I tested in Ableton with the same interface and driver and Ableton gracefully alerts you that the device has been disconnected.

Its a little beyond my expertise so any help is appreciated.


#6

Forgot to mention that I also tried adding in a check to make sure the channel counts were less than 256, but it basically just moved the crash to a different part of the code. Somewhere, the bogus ASIO device instance is returning something bad. I wasn’t able to track it down because I couldn’t recreate it while in debug mode.