...and the bottom part: CARP violation: using HAL semantics (AUIOImpl_Base) 3 0x108ffc7e8 AUMultibandCompressorFactory + 3716 4 0x108ffc758 AUMultibandCompressorFactory + 3572 5 0x108fe0cdc AUNewPitchFactory + 16172 6 0x108fe0460 AUNewPitchFactory + 14000 7 0x108fe3e64 AUNewPitchFactory + 28852 8 0x1090b2f00 AUNotQuiteSoSimpleTimeFactory + 21788 9 0x1090b8278 AUNotQuiteSoSimpleTimeFactory + 43156 10 0x18e7b7050 AudioUnitSetProperty + 548 Looks like AUPitchFactory followed by AUMultibandCompressorFactory was the naughty part, but in separate posts they are fine.

The full stack trace: CARP violation: using HAL semantics (AUIOImpl_Base) 0 0x19c3e59cc HandleCARPViolation + 212 1 0x108fdea24 AUNewPitchFactory + 7284 2 0x108fe84f4 AUNewPitchFactory + 46916 ... My code goes here

Thank you, I knew that. The problem is that I'm not setting kAudioDevicePropertyMute. This is an iOS app running on compatibility layer in macOS and iOS does not even have that property available. I am setting kAudioOutputUnitProperty_EnableIO which exists, and is required for starting input. It also seems that no matter which order I set the properties, setting the first one always triggers this error message.

The stack trace would continue, but figuring out which exact part is sensitive language feels a bit too much now.

The full stack trace was flagging the post as sensitive, but let's see if I can post it as comment 0 0x198aad9cc HandleCARPViolation + 212 1 0x10ddaea24 AUNewPitchFactory + 7284 2 0x10ddb84f4 AUNewPitchFactory + 46916 ... and my code shows up here

I asked the developer support, and they confirmed that the permission dialog is always shown when calling AudioDeviceCreateIOProcID for devices that have inputs when the app has audio input entitlement. If the app does not need audio capture, the dialog can be avoided by setting com.apple.security.device.audio-input to false in entitlements file.

I managed to narrow the point where popup is shown down to AudioDeviceCreateIOProcID. Unfortunately this means a chicken and egg problem, because the IOProcID is needed for setting stream usage. The documentation on AudioHardwareIOProcStreamUsage is frustratingly vague: Also, when getting the value of the property, one must fill out the mIOProc field of the AudioHardwareIOProcStreamUsage with the address of the of the IOProc whose stream usage is to be retrieved. sounds like the mIOProc would be pointer to the IOProc function, not IOProcID, but trying to use the function pointer to set stream usage before creating IOProcID produces just kAudioHardwareIllegalOperationError.