Hosting x86 Audio Units on Silicon Mac

My app encountered problems when trying to open an x86 audioUnit v2 on a Silicon Mac (although Rosetta is installed).

There seems to be a XPC connection issue with the AUHostingService that I don't know how to fix.

I observed other host apps opening the same plugins without problem, so there is probably something wrong or incompatible in my codes.

I noticed that:

• The issue occurs whether or not the app is sandboxed.
• The issue does no longer occur when the app itself runs under Rosetta.

There is no error reported by CoreAudio during allocation and initialization of the audio unit. The first notified errors appears when the unit calls AudioUnitRender from the rendering callback.

With most x86 plugins, the error is on first call:

kAudioUnitErr_RenderTimeout

and on any subsequent call:

kAudioComponentErr_InstanceInvalidated

On the UI side, when the Cocoa View is loaded, it appears shortly, then disappears immediately leaving its superview empty.

With another x86 plugin, the Cocoa View is loaded normally, but CoreAudio still emits

kAudioUnitErr_NoConnection

from AudioUnitRender, whether the view has been loaded or not, and the plugin produces no sound.

I also find these messages in the console (printed in that order):

• CLIENT ERROR: RemoteAUv2ViewController does not override -<private> and thus cannot react to catastrophic errors beyond logging them
• AUAudioUnit_XPC.mm:641 Crashed AU possible component description: aumu/Helm/Tyte

My app uses the AUv2 API and I suspect that working with the AUv3 API would spare me these problems.

However, considering how my audio system is built (audio units are wrapped into C++ classes and most connections between units are managed on the fly from the rendering callback), it would be a lot of work to convert, and I’m even not sure that all I do with the AUv2 API would be possible with the AUv3 API.

I could possibly find an intermediate solution, but in the immediate future I'm looking for the simplest and fastest possible fix. If I cannot find better, I see two fallback options:

1. In this part of the doc: “Beginning with macOS 11, the system loads audio units into a separate process that depends on the architecture or host preference”, does “host preference” means that it would be possible to disable the “out of process” behavior, for example from the app entitlements or info.plist?

2. Otherwise, as a last resort, I could completely disable the use of x86 audioUnits when my app runs under ARM64, for at least making things cleaner. But the Audio Component API doesn’t give any info about the plugin architecture, how could I found it?

Any tip or idea about this issue will be much appreciated. Thanks in advance!