ASIO Devices crashing in 64bit

Hi
I have reports, and have tested, several ASIO devices that crash the PluginHost demo when compiled and run as 64bit on windows. For instance the Focusrite Scarlett crash after the device has been started, seems to be around the first callback. Strangely enough Tracktion 64bit works just fine with this, (of course so does other none Juce host on my system)
Are there any special things to do when using the asio sdk with 64bit juce?
I have tried commenting out code here and there and stepped through the asio ā€œstartupā€ process several times, looking for hints.

Without a stack trace itā€™d be hard to know whether thatā€™s just a mistake in the plugin host demo, or something in ASIOā€¦ (I actually suspect itā€™s probably just a race condition in the demo rather than anything more fundamental)

Hi
Thank you for getting back to us on this, and sorry for not providing more info on the issue.
From visual studio output: At the actuall crash:

FocusriteUSBAsio64.dll!00000001800021d5() Unknown
FocusriteUSBAsio64.dll!0000000180001c48() Unknown
[External Code]

In the Juce Message Thread:

[External Code]	

Plugin Host.exe!juce::thread::sleep(int millisecs) Line 191 C++
Plugin Host.exe!juce::ASIOAudioIODevice::openDevice() Line 1243 C++
Plugin Host.exe!juce::ASIOAudioIODevice::ASIOAudioIODevice(juce::ASIOAudioIODeviceType * ownerType, const juce::String & devName, const _GUID clsID, const int slotNumber) Line 351 C++
Plugin Host.exe!juce::ASIOAudioIODeviceType::createDevice(const juce::String & outputDeviceName, const juce::String & inputDeviceName) Line 1526 C++
Plugin Host.exe!juce::AudioDeviceManager::setAudioDeviceSetup(const juce::AudioDeviceManager::AudioDeviceSetup & newSetup, bool treatAsChosenDevice) Line 539 C++
Plugin Host.exe!juce::AudioDeviceManager::initialiseFromXML(const juce::XmlElement & xml, bool selectDefaultDeviceOnFailure, const juce::String & preferredDefaultDeviceName, const juce::AudioDeviceManager::AudioDeviceSetup * preferredSetupOptions) Line 358 C++
Plugin Host.exe!juce::AudioDeviceManager::initialise(int numInputChannelsNeeded, int numOutputChannelsNeeded, const juce::XmlElement * xml, bool selectDefaultDeviceOnFailure, const juce::String & preferredDefaultDeviceName, const juce::AudioDeviceManager::AudioDeviceSetup * preferredSetupOptions) Line 267 C++
Plugin Host.exe!MainHostWindow::MainHostWindow() Line 84 C++
Plugin Host.exe!PluginHostApp::initialise(const juce::String & formal) Line 55 C++
Plugin Host.exe!juce::JUCEApplicationBase::initialiseApp() Line 275 C++
Plugin Host.exe!juce::JUCEApplication::initialiseApp() Line 88 C++
Plugin Host.exe!juce::JUCEApplicationBase::main() Line 234 C++
Plugin Host.exe!WinMain(HINSTANCE
* formal, HINSTANCE * __formal, char * __formal, int __formal) Line 133 C++
[External Code]

The output log: with #define JUCE_ASIO_DEBUGGING 1 in appConfig (Donā€™t know why it logs double)

ASIO: opening device: Focusrite USB ASIO
ASIO: opening device: Focusrite USB ASIO
ā€˜Plugin Host.exeā€™ (Win32): Loaded ā€˜C:\Program Files\FocusriteUSB\FocusriteUSBAsio64.dllā€™. Cannot find or open the PDB file.
ā€˜Plugin Host.exeā€™ (Win32): Loaded ā€˜C:\Windows\System32\setupapi.dllā€™. Cannot find or open the PDB file.
ā€˜Plugin Host.exeā€™ (Win32): Loaded ā€˜C:\Windows\System32\wintrust.dllā€™. Cannot find or open the PDB file.
ā€˜Plugin Host.exeā€™ (Win32): Loaded ā€˜C:\Windows\System32\msasn1.dllā€™. Cannot find or open the PDB file.
ā€˜Plugin Host.exeā€™ (Win32): Loaded ā€˜C:\Windows\System32\crypt32.dllā€™. Cannot find or open the PDB file.
ASIO: 2 in, 2 out
ASIO: 2 in, 2 out
ASIO: 16->1024, 128, 8
ASIO: 16->1024, 128, 8
ASIO: Rates: 44100 48000 88200 96000 176400 192000
ASIO: Rates: 44100 48000 88200 96000 176400 192000
ASIO: Latencies: in = 282, out = 282
ASIO: Latencies: in = 282, out = 282
ASIO: creating buffers (dummy): 4, 128
ASIO: creating buffers (dummy): 4, 128
ASIO: Latencies: in = 282, out = 282
ASIO: Latencies: in = 282, out = 282
First-chance exception at 0x00000001800021D5 (FocusriteUSBAsio64.dll) in Plugin Host.exe: 0xC0000005: Access violation reading location 0x000000004FAFF840.
Unhandled exception at 0x00000001800021D5 (FocusriteUSBAsio64.dll) in Plugin Host.exe: 0xC0000005: Access violation reading location 0x000000004FAFF840.

Last lines of code that runs, win32_ASIO.cpp lines 1238 and on:

                    // start and stop because cubase does it..
                    err = asioObject->start();
                    // ignore an error here, as it might start later after setting other stuff up
                    JUCE_ASIO_LOG_ERROR ("start", err);

                    Thread::sleep (80);
                    asioObject->stop();

Seems like that is some kind of workaround, if I comment it out, it just crashes in the same way at a later call to asioObeject->start()

Hope this helps

Got one more device on the bench now, a Dante PCIe card (Audinate develops these, and they are branded as Focusrite Rednet, Yamaha Dante, etc)
It also crashes the demo host, but not tracktion.
However it does not crash at the same place as the Scarlet card.
Should I open a separate post for this?

Stack:

FocusriteRednetPCIeASIO_x64.dll!00007ffa7dc458e7()	Unknown

Plugin Host.exe!juce::ASIOAudioIODevice::createDummyBuffers(long preferredSize) Line 1059 C++
Plugin Host.exe!juce::ASIOAudioIODevice::openDevice() Line 1235 C++
Plugin Host.exe!juce::ASIOAudioIODevice::ASIOAudioIODevice(juce::ASIOAudioIODeviceType * ownerType, const juce::String & devName, const _GUID clsID, const int slotNumber) Line 351 C++
Plugin Host.exe!juce::ASIOAudioIODeviceType::createDevice(const juce::String & outputDeviceName, const juce::String & inputDeviceName) Line 1526 C++
Plugin Host.exe!juce::AudioDeviceManager::setAudioDeviceSetup(const juce::AudioDeviceManager::AudioDeviceSetup & newSetup, bool treatAsChosenDevice) Line 539 C++
Plugin Host.exe!juce::AudioDeviceSettingsPanel::comboBoxChanged(juce::ComboBox * comboBoxThatHasChanged) Line 358 C++
Plugin Host.exe!juce::ListenerList<juce::ComboBox::Listener,juce::Array<juce::ComboBox::Listener * __ptr64,juce::DummyCriticalSection,0> >::callChecked<juce::Component::BailOutChecker,juce::ComboBox * __ptr64>(const juce::Component::BailOutChecker & bailOutChecker, void (juce::ComboBox *) * callbackFunction, juce::ComboBox * param1) Line 182 C++
Plugin Host.exe!juce::ComboBox::handleAsyncUpdate() Line 642 C++
Plugin Host.exe!juce::AsyncUpdater::AsyncUpdaterMessage::messageCallback() Line 34 C++
Plugin Host.exe!juce::WindowsMessageHelpers::dispatchMessageFromLParam(__int64 lParam) Line 49 C++
Plugin Host.exe!juce::MessageManager::dispatchNextMessageOnSystemQueue(bool returnIfNoPendingMessages) Line 122 C++
Plugin Host.exe!juce::MessageManager::runDispatchLoopUntil(int millisecondsToRunFor) Line 94 C++
Plugin Host.exe!juce::ModalComponentManager::runEventLoopForCurrentComponent() Line 286 C++
Plugin Host.exe!juce::Component::runModalLoop() Line 1730 C++
Plugin Host.exe!juce::DialogWindow::LaunchOptions::runModal() Line 128 C++
Plugin Host.exe!MainHostWindow::showAudioSettings() Line 494 C++

Before I got a card to test with, I contacted Audinate on the issue, and they asked if we where doing something outside the ā€œstateā€ diagram" in the asio sdk

First-chance exception at 0x00007FFA809B5096 (FocusriteRednetPCIeASIO_x64.dll) in Plugin Host.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.
Unhandled exception at 0x00007FFA809B5096 (FocusriteRednetPCIeASIO_x64.dll) in Plugin Host.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFFFFFFFFF.

Also related is this:

The Steinberg Multimedia Driver, crashes in the demo around ā€œCreate dummy buffersā€, works in tracktion

I also have reports of line6 products failing in similar ways

We have similar problems with ASIO - it crash in 64 bit applications for some ASIO drivers. 32bit applications work fine with the same driver. Weā€™ve had many reports with Roland Quad-Capture, some Line6 and a few Focusrite. Iā€™ve never been able to reproduce the problem myself as i donā€™t have any of those interfaces.

Recently we switched over to PortAudio because of this.

1 Like

ASIO has always been a total bugger for drivers that crash when functions get called at different times or in different orders than the way the driver writers wrote their test codeā€¦

The fact that Tracktion works implies that itā€™s maybe a timing difference thatā€™s triggering this driver bug.

(And just to be clear here - the stack traces above show that this is absolutely a bug in the driver. Thereā€™s no excuse whatsoever for a driverā€™s own thread to crash in their own code, regardless of what parameters/order/timing the app has used when calling the driverā€™s initialisation functions. Iā€™ve spent a huge amount of time over the years tweaking the ASIO wrapper code to work around driver bugs, but thatā€™s not an admission of guilt in our code!)

Thereā€™s absolutely no difference in what our code does on 32 vs 64 bit systems. The only difference will be in the drivers themselves, so presumably the 64-bit drivers have slightly different bugs to the 32-bit ones.

TBH I bet that the only reason that may have ā€œfixedā€ your issue is most likely just a side-effect of whatever re-writing you needed to do in order to use a different library. Thereā€™s not really much difference between our code and port audio in terms of what it actually does. Maybe by moving around your code to call portaudio in a slightly different order or with slightly different timing is all it took to dodge this bug.

@Nikolai Re: the crash above in ASIOAudioIODevice::openDevice() Line 1243, if you look at the code around that line, youā€™ll see from my comments that I had to painfully copy some seemingly pointless startup/pause/shutdown code because this was something that Cubase did, and failing to do the same thing would trigger other crashes in other driversā€¦ You might want to experiment with removing it (perhaps just for the 64-bit build) as it may be the cause of the problem in this caseā€¦

Hi, thank you for getting back to me
Yes, I am aware that ASIO drivers are very flaky, you would think that the hardware manufactures where able to implement this rather simple api in a stable way. Fix one thing and you break something else. It is an insane amount of work to create something stable

But the situation is what it is, so what are we going to do about it?

Yes I know that technically the issue is inside the driver, but our customers donā€™t care, as it works in 100 other hosts. If it was one rare device, ok, but it applies to multiple devices from different brands.

I have been working with VST/ASIO for 10 years, and the number one reason to switch away from a self maintained ASIO/VST-library and invest time and money in the Juce framework, is the idea that Roli would take on the work making sure our codebase is compatible with all the various audio hardware and plugin formats. So that we can spend time developing the apps.

I would pay double, if someone at Roli would, for instance, go outside, buy or borrow a Focusrite Scarlet 2i2, and figure out why it fails in the current implementation of the host. Also maintain the contact with Focusrite support (Or audinate, or line6, and all the others)

Of course after the ā€œfixā€ you would need to double check that other common devices still work. I assume Roli have a nice test-setup for this.

Again you cannot ignore these issues, and simply tell us to fix them, thatā€™s kind of the idea behind investing in a framework. Forget about Android and all the other nice things, get the basics going.

We can arrange a TeamViewer session, to our setup with both Scarlett, and Dante connected.

Also I pretty sure that this crash will happen regardless of how you implement your app.
I think you could call setup.manager->setAudioDeviceSetup (config, true);
Without adding any callbacks or changelisteners or anything and it would stil crash.

Maybe you misunderstood my answer - weā€™re not ignoring it or expecting you to do your own fixes, but for things that we canā€™t reproduce, we often need peopleā€™s help to figure out what the workarounds are. Thatā€™s why I suggested removing the stuff around line 1243, which might be all it takes to sort this out, since that seems to be whatā€™s happening at the time it goes wrong.

I currently have a 64 bit Demo Host (979d3b62) on Windows 10 using a Focusrite Scarlett 2i2 (first gen) with the latest drivers installed. Annoyingly, itā€™s stable.

Does this system setup work for you? What should I change to make a crash more likely?

@jules Sorry, I was a bit harsh there. Yes I have tried commenting out those lines, as well as trying many different combinations of things. To be honest I think the only way to go is to contact the vendor and persuade them to debug it. Iā€™m guessing they wonā€™t fix the bug for us, but at least we could then create a workaround. I tried changing just one little thing and it again broke compatibility with a completely different driver, so (as we all know) this is very touchy. I already got some concat so Iā€™ll keep on pushing.

@t0m, Thank for testing that. Iā€™m testing with the ā€œSecond genā€ devices. I have no idea what the difference is.
But it is not the same driver, I have one ā€œFocusrite USB 2.0 Audio Driverā€ That one works with a itrack-solo, but the second gen. has a driver called ā€œFocusrite Usbā€ and that crashes.

If itā€™s that flakey, then yes, probably would be something the driver guys would need to debug. Itā€™s a pretty painful and thankless task to try to guess-debug things like this from the outside.

Well the 64 bit second generation driver, ā€œFocusrite USB ASIOā€, manages to crash the host sample code in the ASIO SDK, which is pretty damning.

@Nikolai If youā€™ve made contact, could you report this? Iā€™ll chase it up too, but maybe a greater number of voices will speed progress.

I have no idea how Tracktion avoids a crash - thereā€™s no special ASIO handling code thereā€¦

Thanks for looking in to this t0m, the ASIO SDK host was a good idea.
Yes I have made contact with Focusrite, also sent them a compiled version of the Juce Plugin Host Demo.
Their response:

We are already aware of an issue when using the 2nd Generation Scarlett USB driver with [Product Name] - this has been raised with our development team. Unfortunately I canā€™t give a timescale for a fix but I have added your details to our maintenance case so that you can be notified when this problem is rectified.

So now Iā€™m holding my breath, waiting for them to run it under a debugger.
Yes it is very strange that it works in Cubase & Traction. Also this only applies to 64bit
Could it have something to do with pointer sizes 32 vs 64 bit. Something we are feeding it?
shot in the blind

Another data point: The Focusrite driver also crashes the RtAudio https://www.music.mcgill.ca/~gary/rtaudio/ test suite.

Only the Focusrite team could really know for sure. My guess would be timing issues, or uninitialised memory that just happens to be lucky in some circumstances.

@t0m , do you think you could please share your compiled host sample, so that I can do the same test also with other audio devices?
Iā€™ll PM you a dropbox file request

Iā€™ve been in touch with the Focusrite devs and they are releasing a new driver to public beta sometime this week. Iā€™ve not been able to test it yet, but they seem confident that theyā€™ve fixed the issue.

Hi guys, just had a quick flick through this case. If you were finding 64bit standalone apps were crashing with the current release build of the Scarlett 2nd Gen driver (4.12), I would advise testing with our new beta driver (4.14) as this addresses this issue; http://beta.focusrite.com/releases/scarlett_2nd_gen/

1 Like