The tag for the private DTK forum shows up in the menu that appears when you click on your profile avatar in the top right-hand corner (when logged into an account that was granted access). At least, that seems to be the case for me... :)

Some testing on actual hardware seems to indicate that the IOProcs (which default to the workgroup of their respective device) seem to end up on the performance cores. If I could force the scheduler to run my benchmark either on the same cores as the IOProcs will, *or* force it to the efficient cores (that way I will have increased latency but at least it wouldn't matter where the actual IOProcs are scheduled, I will always have enough leeway). But as far as I'm aware, macOS doesn't have any "core affinity" APIs. As my benchmark is triggered in response to a UI interaction, I'd assume it runs w/ high QoS (as it's user-interactive), so currently it's probably also on the performance cores...

Blind shot: Do you have microphone access permission?

Thanks. As far as I can see (from following in Console.app after kickstart coreaudiod), this happens when "the system" is enumerating or activating the available audio devices, but who is actually responsible for that query is not clear (the logs seems to be spit out in bulk after CoreAudio has finished all its device queries). Can anyone else replicate the noted behavior running Apple's NullAudio device? Because right now I cannot even clearly identify *which device* the failed query is associated with...