I have a WinUi3 C# application, where I have implemented a juce C++ backend. I basically load a simple juce::AudioProcessor and juce::AudioDeviceManager in a dll and load them into my executable. I link those two via a juce::AudioProcessorPlayer. I initialized JUCE via the juce::initialize_GUI() method.
The Audio Routing and everything works fine. At some point I get issues in my main thread, which is constantly spammed with WM_TIMER (with wparam 1 and lparam 0) events and thus becomes sluggish and “freezes”. In my C++ backend I pinned this down to the juce::AudioDeviceManager::initialiseWithDefaultDevices(..) method call. If I remove this call, the issue does not happen. This also only seems to happen with WASAPI devices. If I just try to initialize a single WASAPI audio device via createAudioIODeviceType_WASAPI(), this still happens.
A step to 100% reproduce this issue is if I change the window resolution, or step out of the S3 sleep mode.
Attaching a WASAPI Device Observer I get multiple callbacks of the OnPropertyChanged(..) callback from devices, which are not active (maybe this triggers something in juce WASAPI handling? ).
Is this by any change a known issue, or do you know what might help here? At this point, I am clueless, since I tried mostly everything to fix this for quite some time now..
Do you see the same problem in any of the JUCE examples? The JUCE AudioPluginHost uses all of the components you mentioned (AudioProcessor, AudioProcessorPlayer, AudioDeviceManager) so I’d recommend testing that application to see whether you also see freezes there. If so, then we can attempt to reproduce and debug the issue; otherwise, the problem might be related to the integration of JUCE with WinUi3.
It might also be interesting to test with JUCE 8 to see whether the problem is still present there, just in case the issue was caused by a JUCE bug that has already been fixed.
I was not able to reproduce this with the examples or the AudioPluginHost. We also tested it with the JUCE 8 version (i don’t know which version exactly, since it has been a couple weeks ago) but the issue still persisted..
It might be linked to the integration inside the WinUI3 app. Is there something I would need to keep in mind? During initialization of the dll where JUCE resides I initialize it with a “dummyApp” which is basically a nullptr and the juce_initializeGui() macro.. Otherwise I would get assertions when trying to lock the MessageManager for the AudioDeviceManager setup. I also tried to remove this initialization and just create an instance of the MessageManager, but it did not change the behaviour.. Is there maybe a better way to do this or something to keep in mind?
I have finally found the issue.. the issue was that the AudioDeviceManager was not initialized on the main thread. The access to the AudioDeviceManager has been locked with the MessageManagerLock due to the assertions in those cases, but the initialize call was not. Dispatching this call to the main thread fixed the issue.
