How to get "OSWorkGroup" on Macs with Apple Silicon

Developer VST 3 SDK
1

For real-time multi-threaded audio programming on Apple Silicon-based Macs, it is necessary to receive OSWorkGrpup from the host DAW and have the generated threads join the OSWorkGroup in order to effectively use E-Core and P-Core.

https://developer.apple.com/documentation/audiotoolbox/workgroup_management/understanding_audio_workgroups?language=objc

I was able to implement it following apple’s guide for the audio unit format plugin, but I don’t know how to get the OSWorkGroup for the VST format plugin.

Does anyone know how to get OSWorkGroup in VST?

By the way, if I set the audio out in Cubase 12 to the same as the default audio in macOS, I can get the OSWorkGroup from the device ID of the default audio, and by joining the thread to the OSWorkGroup, the P-Core and E-Core are balanced. We have confirmed that it can be used well.

2

Hi,
we currently have no API for this available. But we are planning to do so in the future. But no timeframe yet.

3

Thanks for your reply Arne.
I understand that the API is not currently available yet.
However, I am hoping that the API will be implemented soon. Because we want to be happy.

4

Hi,
is there something new to share on this? We’re looking also for this API extension as we can currently only use the DSP thread for real-time processing on Silicon macs with VST/VST3
Thanks,
accSone - builder of crusher-X

5

Hi,
I am still waiting for further information too.
I would like to know just the prospects.

6

We’re currently looking at exposing the os workgroup in JUCE. It would be helpful to know how the VST3 API might look, so that the JUCE API can be compatible with both AU and VST3.

7

Sorry, for the delay. We’ve identified that the issue we’d like to fix with this is not only a macOS issue and thus we will provide a cross platform solution for running tasks inside the process block. We won’t expose the os workgroup via an API. We believe that a plug-in is not the best scheduler for real-time threads and that the host must be responsible for this. Thus the host will be able to provide as many tasks in parallel to the plug-in as currently capable depending on the current processed audio graph and available hardware resources.