It seems that Mackie ASIO driver is not seen by JUCE - two of our users (of TruePianos) reported that. Other applications can see and use the driver.
I located the potential source of the problem, and it seems to be the checking for existence of InprocServer32-valued file name in the ASIO enumerator (checkClassIsOk function).
The older version of JUCE (which had non-functional checking via OpenFile) worked fine, could see and use the driver, as it seems. So I wonder - it looks like the file can be missing, however the object/driver being loaded fine. It could be about WOW64 filesystem virtualisation. I could not reproduce this on my own machine or get the exact information from our users yet, but I believe this might be possible, if the file is placed inside System32.
Confirmed. After I reverted the logic to OpenFile (essentially, no check, since I think, comparison against zero is incorrect) - everything started to work properly.
The reason I changed the code to File(path).exists() is because the old OpenFile call was broken! Bizarre that it can still work correctly when the file is missing or inaccessible, but I suppose some kind of wacky Windows virtual file system shenanigans could cause that!
I guess my preferred fix would be this:
if (RegQueryValueEx (pathKey, 0, 0, &dtype, (LPBYTE) pathName, &dsize) == ERROR_SUCCESS)
ok = String (pathName).isNotEmpty();
…just to make sure that there’s a path specified, but not checking it.
Interestingly enough, native Steinberg ASIO SDK has the same faulty OpenFile logic in it (by which earlier Juce was inspired, I suppose).
So if Steinberg fixes the error, then Mackie ASIO drivers will suddenly stop working for all applications that use it.
We didn’t get any other reports except for Mackie ASIO so far, so I wonder, if something like “if description contains ‘Mackie’ then skip check” logic would be more appropriate in this case, along with a report to Mackie developers (since Tracktion was written by you, contacting them should be simple?).
TBH I think that the file existence check is probably unnecessary anyway. I’ve now changed it to what I suggested above - as long some kind of filename is specified, it’ll assume the device exists. The only difference this should make would be if somebody has deleted their device driver without also clearing out its registry settings, in which case the device will still be listed, but will obviously fail to open.
I don’t know if this can be related to what has been said above (probably not), but using the latest tip on Windows with the Mackie ASIO drivers for a Mackie device, this is the error message I get whenever the object asioObject is used in juce_win32_ASIO.cpp
if I click the “continue” button the message pops up a total of two times every time it is triggered, but the program continues to work as expected.
Not something I’d heard of, but I assume it’s just an internal exception in the driver, which you normally wouldn’t be aware of when not using the debugger?
