Default AU from Projucer fails auval on Apple Silicon Big Sur (DTK) [SOLVED]

Audio Plugins
1

I’m having the following problems with AU on the DTK (hence Big Sur and Apple Silicon).

I’ve tested with a default plug-in project, newly generated with Projucer, and it exhibits the same issues, which may or may not be correlated.

Problem number 1:

EDIT: auval -comp seems to fail also for plug-ins that load perfectly well in Logic on ARM64, therefore it’s not related to the problem #2 described below. It might even be that validating with the -comp switch is not supported on ARM64 (yet)

EDIT2: the Apple webisite confirms that the Component Manager API, the one that’s tested with -comp, is no longer supported on ARM64. See my post below.

The command

auval -comp -v Plug Ids Here

fails with this output:

    AU Validation Tool
    Version: 1.7.0 
    Copyright 2003-2019, Apple Inc. All Rights Reserved.
    Specify -h (-help) for command options

--------------------------------------------------
VALIDATING AUDIO UNIT: 'aufx' - 'Lpqp' - 'Manu'
  ** As Component **
--------------------------------------------------
Manufacturer String: yourcompany
AudioUnit Name: NewProject
Component Version: 1.0.0 (0x10000)

* * PASS
--------------------------------------------------
TESTING OPEN TIMES:
FATAL ERROR: didn't find the component

I have attempted:

  1. deleting the build folder
  2. changing the version number of the plug-in before rebuilding
  3. restarted the computer and killed AudioComponentRegistrar before attempting rescan

But none of the above worked.

Problem number 2:

When launching Logic Pro 10.6, a window appears saying that there are invalid plug-ins and prompts to open the Plug-in Manager. There the plug-in is listed with a “crashed validation” message.

Selecting it and clicking “Reset & Re-scan selection” opens a window that reports the following error:

validating Audio Unit NewProject by yourcompany:
arch: Unknown architecture: arm64e

validation result: crashed validation

What is working:

Please note that the problematic auval command has the -comp switch to test the AU as Component.

The “default” scan of auval -v Plug Ids Here completes successfully, but that’s not what I’m after.
The original project was passing both types of validation on Intel Catalina and I suspect that, if it passes auval -comp on Big Sur Arm64, that could also solve problem #2 with Logic. EDIT: thanks to the responses below, it appears this has nothing to do with the ability of the plug-in to satisfy Logic validation criteria

Also about Logic, in the Plug-in Manager I checked the box in the “Use” column to use the plug-in anyway and (after restarting Logic, otherwise it doesn’t pick it up), the plug-in appears in the Audio-Unit menu (under a sub-menu named [Incompatible]) and it works flawlessly when instantiated.

So both above problems seem to be specifically related to auval rather than Logic.

Details:

I’m on the current JUCE develop (several commits after 6.0.4)

This is a DTK still with its original Big Sur 11.0 beta version (20A5299w). I’m afraid to update it because I’ve heard horrific stories about bricked devices.

All projects have been built on the DTK, for arm64 architecture only (i.e. Rosetta has not a role in all of the above), using the Xcode beta that came with it: Version 12.0 beta (12A8158a)
I have been unable to run on it a more recent version of Xcode (e.g. 12.2): it bounces a few times in the dock then crashes. But that’s a different issue, possibly due to the fact that the OS is not up to date with the latest beta.

Questions:

I’m aware that similar issues have been reported in the main topic JUCE and macOS 11 / ARM by @zabukowski, but in contrast with his experience, a default generated project from Projucer doesn’t pass auval in my case.
Perhaps his attempts at executing auval from the command line didn’t include the -comp switch?
But even in that case, the issue #2 with Logic remains in my case, where in his it looks it was being correctly recognized and that error window regarding arm64e stopped appearing.

Neither my original project nor the default one have QTKit or OpenGL frameworks.

Has anyone had similar problems?

2 Likes
2

I have auval 1.7.0 as well on Catalina
so I suspect the auval you have don’t support arm64.

3

Hmm, some support for arm64 should be there because running auval without the -comp switch does actually validate the AU, and that’s still a plug-in built only for arm64.

But that’s a good point, I’d be interested in knowing what auval (and macOS) version have those people for which it seems to work.

4

Is your plugin compiled as arm64e or arm64 ? I have to say I am a bit confused with these two architectures, it seems many big Sur binaries are arm64e (auvaltool for example), but I can’t run an arm64e program that I compile myself.

My plugin (and the juce AudioPluginDemo arm64) both load in Logic 10.6 (and pass its validation), while they also both fail at “auval -comp” (I was not aware this option existed). This is with auvaltool 1.7 , which is a x86_64/arm64e binary.

5

Mainly arm64.
I have attempted at building the default projucer project also as arm64e but got the same results.

Surprisingly, that also includes the fact that (after checking the “Use” column to force its availability) I have been able to load the arm64e plug-in in Logic (but did not try with the stand-alone honestly)

6

I’m running Big Sur 11.1 beta on DTK. My plugin fails validation with -comp but validates fine without and in Logic. My auval version is also 1.7.0 and it is a fat binary with x86-64 and arm64e

7

Thanks.
Ok, there is more and more evidence that validating with -comp on ARM64 is not required for a plug-in to successfully validate in Logic.

Perhaps that option is not even supported on ARM64 (yet) despite the fact that it’s listed in auval -h help.

At least I only have problem #2 to concentrate on

8

The more I try, the more I am wondering whether it’s my particular setup that’s showing an unusual behavior.

I’ve attached the component that I obtained from building the “Hello World” plug-in generated with Projucer (arm64 only).
Can you (@RolandMR or @jpo) try to load it in Logic in the DTK?
I’m desperate to know if the problem is in the plug-in or in the my system at this point.
Thanks in advance if you are willing to carry out this test.

NewProject.component.zip (3.8 MB)

9

Your component is not signed, that’s why it fails to load in Logic – once I sign it with “codesign -s - NewProject.component” it loads in logic.

10

For a moment I hoped we found the issue, but unfortunately even after signing it, using exactly the same command line, Logic is showing the same messages and marking it as “crashed validation”.

I also tried increasing the version number and then signing the result, forcing Logic to re-scan it as a new plug-in. Still no joy.

I would have been surprised however, because it’s true that this test plug-in is unsigned, but my original project is, and shows the same issue.

May I ask what messages/behavior did you witness in your Logic, when you first loaded my unsigned plug-in? Perhaps that’s a different issue.

11

When not signed, both auval and logic are refusing to validate it:

validating Audio Unit NewProject by yourcompany:

    AU Validation Tool
    Version: 1.7.0 
    Copyright 2003-2019, Apple Inc. All Rights Reserved.
    Specify -h (-help) for command options

--------------------------------------------------
VALIDATING AUDIO UNIT: 'aufx' - 'Lpqp' - 'Manu'
--------------------------------------------------
Manufacturer String: yourcompany
AudioUnit Name: NewProject
Component Version: 1.0.2 (0x10002)

* * PASS
--------------------------------------------------
TESTING OPEN TIMES:
COLD:
FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF


validation result: couldn’t be opened

Are you using the official Logic Pro 10.6.0 or a beta version ?

12

I needed to do this.

13

So far my plugins loaded fine on ARM without making this change. Do your plugins include additional frameworks that maybe are not signed?

14

I’ve solved the problem, in this case it had nothing to do with signing nor the Frameworks linked in the final binary.

The real culprit was the “arch” command.

I knew nothing about it until I found it mentioned in the error message I mentioned earlier.

arch: Unknown architecture: arm64e

Quickly I’ve found out that it’s the command to be used in the Terminal to run a specific architecture within an Universal Binary.

So for example:

arch -x86_64 auval -a

Executes “auval -a” forcing its “x86_64” side to run, even on an ARM machine, thanks to Rosetta.

It also has another mode, in which you don’t need to pass the architecture explicitly as a parameter, but instead you can specify a list of architectures in order of preference via an environment variable named ARCHPREFERENCE.

My system didn’t have an ARCHPREFERENCE environment variable globally set, but since they can easily be prepended on the command line, I bet the Plug-in Manager within Logic does its validation on a ARM machine by running a command similar to:

ARCHPREFERENCE=arm64e,arm64,x86_64 auval -v Xxxx Yyyy Zzzz

Which means “invoke auval running its arm64e binary if it has one, otherwise invoke the arm64 as a second choice, if both are absent resort to x86_64”.

Which is very clever, UNLESS for the fact that the “arch” command in my DTK didn’t know a thing about an architecture named “arm64e”, with the result of tragically quitting before even trying, at the sole appearance of that name in ARCHPREFERENCE (I’ve tried it myself on the command line).

The funny thing is that the “arch” binary is itself a Universal Binary made of a x86_64 and a arm64e implementation.

My DTK was running macOS 11.0 Beta, never updated, so I guess this was a slight oversight quickly fixed in later versions of Big Sur.
In fact, the “arch” command on the (Intel) computer of a colleague of mine, which is running Big Sur 11.0.1, behaves well when presented with the “arm64e” architecture, i.e. it doesn’t die but keeps trying the following architectures if the binary to be run doesn’t have it.

So I updated my DTK to Big Sur 11.1 Beta as it prompted me to, crossing my fingers after reading horrible stories of DTKs bricked by updates and… it worked.

Now Logic is happily validating the default plug-in created by Projucer without a complaint, and it does also for my original project as well. Yay!

3 Likes
15

Congrats on solving the issue. I guess I was lucky then. I always did all updates to my DTK and never had any issues.

1 Like
16

I’ve also found an answer to problem #1 regarding the failure to validate with auval -comp on ARM64:

from: Porting Your Audio Code to Apple Silicon | Apple Developer Documentation

For the arm64 architecture, always use the Audio Component API to load Audio Units, codecs, and other code modules into your app. The Audio Component API is the modern way to search for loadable code modules, and it’s available in macOS 10.6 and later. Apps that target the arm64 architecture or link against the macOS 11 SDK cannot use the legacy Carbon Component Manager API to open Audio Units. If your app uses the Carbon Component Manager, plan to migrate off of it when porting your app.
If you develop Audio Units or codecs, update your code to support the Audio Component or Audio Unit Extension APIs if you haven’t already done so. When you link an Audio Unit or codec against the macOS 11 (or later) SDK, use one of these modern APIs instead of the Carbon Component API.

Note:
To preserve compatibility, apps that link against the macOS 10.15 (or earlier) SDK may continue to use the Carbon Component Manager to load Audio Units and codecs. Similarly, Audio Units and codecs built using the macOS 10.15 (or earlier) SDK may continue to include separate resources and entry points to support older APIs.

The -comp switch instructs auval to test the AU using the old, deprecated, Component Manager API, which is the one that’s no longer supported on ARM64, whereas auval without that switch tests the AU using the current, more modern Audio Component API, available since macOS 10.6.

2 Likes