M1 / Apple Silicon (AAXWrapper / AUv2)

Hi everyone,

Here are two questions:

  1. Has anyone successfully compiled the aaxwrapper lib in the SDK? It seems like the current AAX SDK version 2.3.2 is not ready for the new arm64 platform.

  2. While it’s possible to compile the auwrapper (v2) lib for arm64, it seems like universal plugin builds are bridged to x86_64 in arm64 native hosts such as GarageBand or the latest REAPER beta. Is it possible that the AUv2 protocol isn’t supported on the new Silicon platform anymore so we need to use the new AUv3 wrapper instead?

Best,
Ray

Avid needs to release a compatible SDK for AAX.
For AUv2 you may have to ask Apple about it. We don’t know.

2 Likes

Thanks for the swift response, Arne. Makes total sense.

Big thanks to you and your crew for being prepared for arm64 with your SDK already.

1 Like

I was able to compile the au v2 wrapper for Apple Silicon and it’s working

1 Like

Thanks for your feedback, olilarkin. Yep, I also find that AUv2 seems to run on arm64 natively.

Regarding AAX: You can build a universal binary and sign it using the EDEN SDK Lite 5.3.x tools, just build the aaxwrapper lib for x86_64 only and remove the aaxLinkAnchor reference when your target is being built for arm64 depending on the respective preprocessor macro. This is a good preperation for the next version of Pro Tools IMO.

Automation seems broken in AUv2 wrapper on ARM Logic/Garageband. It works on intel

I can confirm that parameter changes are only reported to the host but not vice versa in GarageBand arm64 AUv2. Besides automation that also affects reaction to touch bar events. I have no possibilty to test logic but I assume it’s the same there.

It seems to be GarageBand/host specific though, REAPER arm64 works just fine in that regard.

Best,
Ray

@ray3 how did you generate your arm64 AUv2 plugin? Are you using Jamba or a different mean? I know @olilarkin has reported this issue for Jamba audiounit automation on ARM Logic · Issue #9 · pongasoft/jamba · GitHub and I am trying to figure out whether it is a Jamba issue and/or if there is anything I can do to fix it.

i think its an auwrapper issue… but i am still trying to track it down. I was just using jamba to test… i have the issue in my plugin virtualcz which doesn’t use jamba

Hi,

I’m using the libs compiled out of the box using CMake and the latest VST3 SDK. On top of that I have my own framework, so I’m sure it isn’t related to jamba.

Best,
Ray

I am a little skeptical that the issue is the auwrapper implementation. Why should the same code behave differently when compiled for another target platform except for maybe due to different endianesses? It also works fine in REAPER arm64 as AUv2, so I’m sure the issue is in the GarageBand/Logic implementation.

Best,
Ray

I also think that this looks more like a host issue than a wrapper issue if it works in Reaper. Does automation work with other AUv2 plug-ins in Garageband/Logic?

yes, it seems like a host issue and I have reported to Apple

1 Like

Hi Arne,

I think I know what’s going on here: VST3’s AUv2 wrapper uses AUListenerCreate() to set up a listener via paramChangedListenerProc. I have an info from Apple that native M1 systems will use the dispatch queue which needs to be set up using AUEventListenerCreateWithDispatchQueue().

Can we expect a patch here?

Also did you see my PR regarding the offline state in AUv2 on GitHub: Report offline rendering state to the underlying VST3 in AUv2Wrapper by raygit83 · Pull Request #34 · steinbergmedia/vst3_public_sdk · GitHub ?

Thanks!

Best,
Ray

Interesting information. Sure we will make this change in the next SDK (also including the offline PR). If you like you can ask your Apple contact to find out why we see this issue with AUV3? It looks like you get this information more likely than us!

Thanks Arne! Will do.

Hello Arne
Any updates?

It will be released with the next update, scheduled before years end.