I configured a new partition today to run the latest Sequoia, Xcode 16.4, and JUCE 8.0.7.
I compiled and ran the AudioPluginHost in Debug.
You get this “Hang Risk” warning when you open the Plugins Window and “Scan for new or updated AudioUnit Plugins” (scan mode is “In-Process”):
/Users/stephen/Development/JUCE/modules/
juce_audio_processors/format_types/juce_AudioUnitPluginFormat.mm:878
[Internal] Thread running at User-interactive quality-of-service class
waiting on a lower QoS thread running at Default quality-of-service class.
Investigate ways to avoid priority inversions
Also, is it normal to be seeing this many console error messages?
For the priority inversion, is it possibly due to one specific plugin? can you narrow it down at all? maybe remove all the plugins and perform the scan again, does it still happen? If not, gradually add them back in, if you have lots of plugins try a binary search.
This happens on the first scan (of AU plugins) of an absolutely virgin Sequoia installation, with a freshly compiled APH. I just tried it with the new 8.0.8 release. There is no AudioPluginHost.settings preferences; not a single installed plugin other than the AUs that Apple includes.
If this is an Apple issue, then nothing for me to worry about. I only reported it because it seemed like it might be an APH issue.
Thanks for this detail. The warning is emitted when destroying certain plugin instances. In this case, after trying each Apple plugin individually, I discovered that the warning seems to be caused by the “AUSpeechSynthesis” component, augn ttsp appl. Creating an instance of this plugin and then right-clicking and selecting “Delete this filter” causes the warning to be shown. The warning only seems to trigger once for each plugin, so you may need to quit and relaunch the APH to force the error to reappear.
I see the same warning when destroying some UAD plugins, but not when destroying Xfer OTT or other preinstalled Apple plugins. Therefore, I’m confident that the issue is caused by specific plugins.
Based on the text of the error message, I’m guessing that the problematic plugins spin up background threads, and wait for these threads to exit cleanly before allowing the plugin instance to be disposed. JUCE needs to destroy AU instances on the main thread, which runs at “user interactive” QoS, and I’d expect worker threads to have a lower QoS.
While investigating this issue, I discovered a real JUCE bug where cancelling an in-process AU plugin scan could deadlock the host application. I’ve put together a fix for this new issue, and I’ll update this thread once the change is public.
