Does ASIOAudioIODevice() need MessageManager locked?


#1

Hi,

I’m now making an application which uses ASIO I/O based on Juce 1.34.

When I try to create ASIOIODevice using createDevice(), it was stopped by checkMessageManager in Component::addToDesktop() which is called from the constructor of ASIOIODevice, in the code juce_win32_asio.cpp line 149.

So I modified my code, once lock the MessageManager and then call createDevice().

AudioIODevice* pDevice; m_pDeviceTypeToCheck->scanForDevices(); { MessageManagerLock mLock; pDevice = m_pDeviceTypeToCheck->createDevice(DEVICE_NAME_TO_CHECK); }
However, it was dead locked in the Component::addToDeskTop(). What is the requirement to call createDevice() method? Does it actually need MessageManager locked?

Best regards,
Masanao Hayashi
Korg Inc.


#2

I don’t recommend calling the ASIO create methods from your own thread - I’ve seen some dodgy ASIO drivers out there that just don’t work properly unless you create them on the UI thread. No idea why, but I remember it caused some hassle when I was writing tracktion.

But if you have to do it that way, I guess you could put a lock around just the addToDesktop call:

[code] name = name_;

    {
        MessageManagerLock mml;
        ourWindow.addToDesktop (0);
        windowHandle = ourWindow.getWindowHandle();
    }

    jassert (currentASIODev == 0);

[/code]

I can’t think of any way that would cause a deadlock.


#3

Ah… yes, I create it rom my own thread…

[quote][code] name = name_;

    {
        MessageManagerLock mml;
        ourWindow.addToDesktop (0);
        windowHandle = ourWindow.getWindowHandle();
    }

    jassert (currentASIODev == 0);

[/code][/quote]

I just did it before seeing this comment but it still freezed. So I wondor why the dead lock is happened. It is waiting WaitableEvent::wait() from InternalTimerThread::run() from juce_threadEntryPoint()… So maybe the dead lock is not caused by MessageManager but other locks?

I’m currently using ESI Quata Fire, it uses bridgeCo DM1000 chip and probably be based on the bridgeCo’s standard driver SDK. The chip is most famous one, so there are a lot of similar drivers, I think.

hmm… I will try to call it from UI thread instead.

What I want to do is, searching particular ASIO device by calling scanDevices() every seconds. And if the device is found, open the ASIO device from the worker thread.

You know, ASIO drivers are always there regardless the actual device is connected, so I’m using DirectSound to search the device and once it is found, open the ASIO driver for that device…

Best regards,
Masanao Hayashi


#4

Ah yes, actually that lock wouldn’t work because internally, the window has to be created on the UI thread, and that’d cause a deadlock. Best to stick to doing it on the UI thread. Just use a Timer or something.


#5

So my work around is calling createDevice() in UI thread and call open() in my own thread, now it seems to work fine.

The specification of ASIO is not good, it requires HWND to create the instance…

Thank you for your advice.

Best regards,
Masanao Hayashi
Korg Inc.


#6