Cool! Thanks for the tip on Perfetto, I had never heard of that before. I’m going to have to try it when figuring this out. That looks super useful.
Maybe I’m lazy, but I see no reason not to use JUCE::Thread class with ‘startRealtimeThread’ - since it creates the necessary parameters based on a single miliseconds value.
Unfortunately I’m not using JUCE for this project. If I could I would 
If your thread pool is for real-time processing, then no need to measure anything IMO - if your thread pool functions take longer than the available time in the callback then there is going to be a problem anyway (could probably even set this max time to half the callback time).
Good point on this one, I think I’ll have to play around with making the callback time and the thread time different numbers. Right now I have callBackTime == RealtimeConstraint
When creating a threadpool, it may be best to try to limit to the max logical cores (there’s a JUCE function to get that value)
One other thing to note is that in my experimentation with the OS Audio Workgroups I found this function:
os_workgroup_max_parallel_threads That recommends a value for the thread count. On my m1 MBP that’s 8
Thanks for the extremely detailed responses on this. I’ve been banging my head against the wall with these problems and it’s nice to get some external feedback and conversation about it.