Just FYI - unfortunately I don’t know the answer -
See also: https://forum.juce.com/t/mac-m1-thread-priority-audio-workgroups/52188
and https://forum.juce.com/t/fr-thread-priority-vs-efficiency-performance-cores/49025
There is a description on how to retrieve the workgroup here:
https://developer.apple.com/documentation/audiotoolbox/workgroup_management/adding_parallel_real-time_threads_to_audio_workgroups
It mentions retrieving directly from the HAL API - I’m not sure if that’s what the code example is doing with 'workgroup = auHal.osWorkgroup; - I’m just not familiar with any of that code or Objective C.
I’m really hoping the support for audio workgroups just gets integrated into JUCE Thread as a generic option when creating a thread (e.g. some kind of ‘try to join/associate to the ‘AudioProcessor’ audio callback workgroup’ flag/option) - or whatever is the better way to do that.
It’s not just standalone hosting apps that can need multi-threaded real-time audio processing quite a few more powerful synths with multiple layers and large polyphony counts can greatly benefit from it - both as plugins or standalone builds.
Fingers crossed from my side that JUCE devs can take it on soon, because I’m also not keen on figuring out the Objective C side of it and how to integrate it with JUCE Thread, and I’m getting customer complaints about load spiking/audio glitching on M silicon systems - especially those with only 2 e-cores (where it seems some audio threads got demoted to e-cores). I also know of one other developer who maintains a popular plugin hosting app based off JUCE that is getting the same issues.
Cheers,
Paul.