JUCE and macOS 11 / ARM

[RolandMR]

@benschmitz

I couldn’t get AAX versions to build as UBs due to errors in the SDK

This is pretty easy to fix, you just need at add some defines for macos and arm.

@benschmitz

I’ve heard some stirrings elsewhere online however about Universal Binaries not working on macOS versions earlier than 10.12 Sierra.

I will test this a get back to you.

[RolandMR]

I just tested on 10.9, 10.10 and 10.11

Fat binary DAW works on all of them
Fat binary plugin works on 10.10 and 10.11

[benschmitz]

Thanks so much! Just curious if the ones you tested were Notarized, I’m curious if that might have an effect as well since the issue I heard about seemed to stem from code signatures.

[RolandMR]

Yes, they were signed and notarized. They were release candidate builds, so they were exactly the same builds / installers the users would get.

[DavidCNAntonia]

@ttg

It sounds more like some threading/concurrency issue.
Did you try running with thread sanitizer? I don’t yet have access to an ARM machine. but it might even just be Logic threading is different or order execution that shows up more easily on that specific setup.

Unfortunately, I can’t get anything to actually run in debug with logic when thread sanitiser is enabled. I used standalone to get rid of any issues that could point out with the threading. I am now managing to get it through AU validation. Here are the results I get from the console…

Without thread sanitiser enabled:

2020-11-16 16:40:00.777959-0800 Logic Pro[2458:115901] [audiocomp] AUv3Instance.mm:817 Invalid property id 1098015046 (scope 0, element 0)

With thread sanitiser enabled:

2020-11-16 16:38:12.849887-0800 Logic Pro[2427:113602] [AUHostingService] AUHostingServiceClient.mm:231 [AUHostingService Client] connection interrupted.
2020-11-16 16:38:12.849970-0800 Logic Pro[2427:113663] [audiocomp] AUNSExtension.mm:542 Failed to open AudioUnit remotely: Error Domain=NSCocoaErrorDomain Code=4097 “connection to service on pid 2437 created from an endpoint” UserInfo={NSDebugDescription=connection to service on pid 2437 created from an endpoint}
2020-11-16 16:38:12.850062-0800 Logic Pro[2427:113663] [audiocomp] APComponent.mm:274 error 4097 returned from OpenAsync for aufx/PLUGINID/MANUID/0x1c/0x0

I guess this latter error is down to the fact that thread sanitiser is running and it just doesn’t like it - AU val fails when it is enabled. No idea what the invalid property id is about though as it works everywhere else. Not quite sure where to find “AUv3Instance.mm” to work out this oddity.

@hill-matthew

You may like to see what happens for that plugin with the Reaper build that supports Apple Si, check for the arm64_notarized.dmg builds here .

After some fixes to the above threading issues, it appears to work in Reaper thank you. I assume it will be loading the ARM version rather than the intel build?

[PluginPenguin]

@DavidCNAntonia

it appears to work in Reaper thank you. I assume it will be loading the ARM version rather than the intel build?

I would not be too sure about that.

I just played around with that Reaper build on my DTK running Mac OS 11.0.1. Reaper is able to load AU and VST plugins compiled for x86_64 only, with AU being silently bridged by some layer obviously supplied by Apple (Logic uses the same) and VST being a bit more obviously bridged by Reapers own implementation that was already available to bridge e.g. 32 Bit x86 plugins running in a 64 Bit x86_64 environment. You can see that AU bridge in the activity monitor, look for AUHostingCompatibilityService (Reaper) there.

I also managed to run a universal binary VST3 natively in Reaper, but I’m not sure if in case Reaper detects that the ARM part of a UB cannot be launched, the bridge is being used silently in the background?

[pflugshaupt]

Weird, when I tested with the Reaper ARM build, it loaded my universal plugins as ARM versions for all three plugin formats.

[DavidCNAntonia]

It doesn’t appear that AUHostingCompatibilityService is running - the only difference to my setup is that I am running Big Sur Beta 5 (I’m downloading the release version as I type). The only thing reaper in activity monitor is saying that it is running as “Apple” rather than “Intel” in the “Kind” column.

[yfede]

@RolandMR

Fat binary plugin works on 10.10 and 10.11

Out of curiosity, what happens on 10.9 for plug-ins? they aren’t even scanned? or they are scanned but crash on loading?
Also, does this apply to the Stand-alone version too, or that one does also run on 10.9?

[RolandMR]

@yfede

Out of curiosity, what happens on 10.9 for plug-ins? they aren’t even scanned? or they are scanned but crash on loading?
Also, does this apply to the Stand-alone version too, or that one does also run on 10.9?

They fail scanning. I believe loading the dylib is failing.

Standalone should be fine.

[DavidCNAntonia]

Finally got this working. I had to enable “Runtime Exceptions: Disable Library Validation” for the plugin to pass AU validation with the release build. Not 100% sure why but it now works. Give it a go if your ARM builds are not validating in logic.

[benschmitz]

@DavidCNAntonia

I had to enable “Runtime Exceptions: Disable Library Validation” for the plugin to pass AU validation with the release build.

Was running into this issue myself and this was helpful! After some digging around on the Apple forums I also discovered that library validation is only available for macOS 10.9 and up. I was able to get my AUs to run in ARM mode by including the Runtime Exception you suggested, but changing the OS target to 10.9 or higher also fixed the problem without needing that exception.

Im wondering now why this is only an issue with the ARM builds, if library validation doesn’t work when you target 10.8 why isn’t that an issue for Intel builds? Seems like we might keep discovering some back compatibility quirks with these Universal Binaries for a while.

[DavidCNAntonia]

@benschmitz

but changing the OS target to 10.9 or higher also fixed the problem without needing that exception.

It’s interesting you find it works with 10.9 and higher as I target 10.11 so by that theory it doesn’t quite match up, there must be something else going on.

[yfede]

@zabukowski

Currently i don’t have arm machine in front of me, so i can’t really try preferences one by one and find the problematic one(s). Will do when possible.

I’m in the same situation as you have been (plug-in failing when rescanning in Logic because of complaint regarding “arm64e” architecture, and manually launching “auval -comp” says that it couldn’t find the component)

Have you been able to find the problematic settings that cause that?

(might have to spawn a new topic about that shortly if I cannot find a solution soon)

[zabukowski]

I think removing QTKit framework from Xcode project will do the trick. Don’t forget to clean project before building (for a start, i suggest you to manually delete existing/non-working component file as well).

[yfede]

Thank you, but the fact is that QTKit has never been in the project so that can’t be the cause.

I’m seeing the same problems with a plug-in compiled from a default plug-in project just created with Projucer. Time to create a specific topic on the subject

[yfede]

Done so, the new topic for that specific issue is: Default AU from Projucer fails auval on Apple Silicon Big Sur (DTK) [SOLVED]

I’d be interested if @zabukowski (or whoever is happily validating AUs on their ARM64 macs) could comment there with the version number of auval that they have (and possibly of macOS, I guess that might be a factor too)

EDIT: I’ve solved the issue, visit the linked topic for the detailed description of what the problem was

[pflugshaupt]

@benschmitz

Im wondering now why this is only an issue with the ARM builds, if library validation doesn’t work when you target 10.8

How are you able to target 10.8? The min Xcode version for ARM is 12 and the lowest possible target sdk appears to be 10.9 or am I missing something?

[benschmitz]

My mistake, I set the target in Projucer to 10.8 but this didn’t carry over to XCode and it instead was 10.9

[graeme-2]

Just picked up a new arm machine and with Xcode 12.2 I’m finding Time Profiler will not show symbols for DemoRunner (and my own app). If I go to Instruments -> File -> Symbols -> Expand “DemoRunner” is says “Permission to profile this process was denied. Applications you wish to profile must be signed with a developer code”. Changing signing options however doesn’t seem to have any effect. For testing sake I created a blank swift project in Xcode and that had no issues with symbols despite having no code signing options set. Wondering if anyone’s seen this. Searching google for that error message brings up zero results.