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...

Blind shot: Do you have microphone access permission?

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...

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... :)

If it's during (early) boot, it could be Secure Boot: https://support.apple.com/en-us/HT208330 I don't have any specifics about which servers that uses though. Later on, I suspect a gazillion connection requests will come from all kinds of daemons and apps.

I can think of two potential problems you may be running into: By using /usr/bin/python (which is part of the system), your code is running with SIP (System Integrity Protection) enabled and therefore in a more restrictive environment (certain dyld environment variables filtered out). Maybe python refuses to load / run non-system .dylibs (as otherwise they would be run with the rights of the signed system process)? I seem to recall python loading its extensions fairly restrictively (RTLD_LOCAL among other dlopen-flags, but check the source); maybe that causes havoc with proper enumeration?

I wasn't aware that SystemExtensions were meant to include AudioServerPlugIns. I can only find references to .dext (DriverKit) and .kext (proper kernel extensions, depcrecated) in the SystemExtensions documentation (as well as references to EndpointSecurity and NetworkExtensions).

I have little actual knowledge of this area (and I may be misunderstanding what you're doing), but I feel that if what you're trying to do were possible, then it'd be too easy to phish credentials by overlaying "your own" fake login-window, so maybe it not working is by design?

I'll try to explain again: My app is forwarding audio from one (virtual) input device to (real) output device. This process is driven by the IOProc of the output device. As I want to incur as little latency as possible (i.e. use the most up-to-date data from the input device), I want my IOProc to be scheduled as late as possible while still hitting the deadline (see the documentation for kAudioDevicePropertyIOCycleUsage - https://developer.apple.com/documentation/coreaudio/kaudiodevicepropertyiocycleusage the header docs are more helpful, the web documentation seems useless). But I do have a bit of work to do to the data before it's ready, so I need to figure out what I can set kAudioDevicePropertyIOCycleUsage to and still hit the deadline (from the documentation you get scheduled the entire cycle of the audio duration with the default IOCycleUsage). So far, I've been benchmarking the workload how long my audio fiddling needs (on some synthetic input data) before starting the IOProc, and then multiplied that by a safety factor and adjusted kAudioDevicePropertyIOCycleUsage accordingly. There are no other threads involved in this work (so the AudioWorkGroup APIs shouldn't be needed), but I'm wondering how to best do the estimation of the IOCycleUsage now that differently speedy cores are in play. Either I need to benchmark on the performance cores (and then the IOProc always should run on the performance cores, or I need a safety factor of how much slower the efficiency cores are), or I need to force the benchmarking onto the efficiency cores (that way I'll never be late, but I might leave some latency on the table). Does that make some sense?

You can use KVO to observe AVPlayer.status. Note that this has been broken in Swift for >3 years, see https://bugs.swift.org/browse/SR-5872 . So in that case my work-around was to observe .rate instead.

From what I can tell (as I'm doing the same thing), you don't need a special entitlement because the AudioServerPlugIn is not an app extension but a completely stand-alone plug-in. Whether that plug-in needs to be signed with a Developer ID (or notarized) I'm actually not sure about (because AudioServerPlugIns are already sand-boxed). FWIW, I'm doing that (i.e. signing it) with a normal (paid) Developer ID and it seems to work for other people, although setting up the whole process if fraught with potential for errors. I'm not distributing via the App Store, but if you were, you'd have to install your plug-in using the normal mechanism (Apple Installer, or maybe manually copying it to /Library/Audio/Plug-Ins/HAL), but I'm not sure that's encouraged (allowed?) for AppStore apps.

I did some googling and my current guess is that these channels contain content for Hearing Impaired (with emphasis on dialog) Visually Impaired (audio description) The mention I found was https://www.isdcf.com/papers/ISDCF-Doc4-Audio-channel-recommendations.pdf, which doesn't seem related to the THM format (but documentation for that seems to be rather sparse) but still related to multi-channel audio.

IIRC The compiler treats the pointer returned by malloc as not having any defined value (it is "poison"), so it can remove your test against any *specific* value (as there were no writes). Then it simply has a matching malloc and free, which can be elided, which leaves a loop with the rng whose results are never used, and thus removed as well.

I wonder whether you're running into the same problem as the one here https://developer.apple.com/forums/thread/667459?answerId=650916022#650916022 (which is to say https://bugs.swift.org/browse/SR-5872 ).

Nope, but I hope to be able to do some experiments on real hardware once by DTK replacement arrives.