Issue with Audio Unit on 10.11

Audio Plugins
61

Hmm, if there hasn’t been a second update fixing the first one, I think it’s very likely that already affected machines will stay affected. If I find time to test this I’ll let you know.

The test machine we set up to reproduce this didn’t have any connected iOS devices, but the relevant itunes update was on there.

1 Like
62

Can confirm this works on a 10.12.6 install

It was a clean install, followed by installing all available updates, including “Device Support Update”, “iTunes 12.8.2” and “iTunes Device Support Update”

Following those updates, running Auval would say:
FATAL ERROR: OpenAComponent: result: -1,0xFFFFFFFF

After removing the link to CoreAudioKit and resigning the plugin, it works again, without changing any MobileDevice.framework etc.

2 Likes
63

I just tried it and now my plugin won’t load on 12.2.1. I didn’t bother to test on 10.11

validating Audio Unit Nexus by reFX:

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

--------------------------------------------------
VALIDATING AUDIO UNIT: 'aumu' - 'NEXU' - 'reFX'
--------------------------------------------------
Manufacturer String: reFX
AudioUnit Name: Nexus
Component Version: 4.0.9 (0x40009)

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


validation result: couldn’t be opened
64

Any update on this? We got several customers with the same issue on 10.11.

65

Has anyone found a solution with CMake that is similar to the ProJucer patch I posted above? I’m relatively new to the Juce CMake solution and excluding CoreAudioKit.framework at the end of the process is harder than I thought and it might needs a patch somewhere. Or maybe I’m just not understanding the process well enough - I don’t see where the frameworks list is stored when CMakeLists.txt is executed.

66

“We’re going to wait for a response from Apple before we add complexity to the build system. Optional dependencies like this cause real pain integrating with package managers, and we’d like to avoid it if possible.”

Any responses from Apple yet? This continues to be an ongoing issue. A few Valhalla customers per day report this issue to us, and we’d love to have a solution.

4 Likes
67

Answering my own question… I found a way to prevent linking to CoreAudioKit.framework when using CMake. It requires patching a function in JuceModuleSupport.cmake:

function(_juce_link_frameworks target visibility)
    foreach(framework IN LISTS ARGN)
        if(CMAKE_SYSTEM_NAME STREQUAL "Darwin")
++          if (NOT framework STREQUAL "CoreAudioKit")
                find_library("juce_found_${framework}" "${framework}" REQUIRED)
                target_link_libraries("${target}" "${visibility}" "${juce_found_${framework}}")
++          endif()
        elseif(CMAKE_SYSTEM_NAME STREQUAL "iOS")
            # CoreServices is only available on iOS 12+, we must link it weakly on earlier platforms
            if((framework STREQUAL "CoreServices") AND (CMAKE_OSX_DEPLOYMENT_TARGET LESS 12.0))
                set(framework_flags "-weak_framework ${framework}")
            else()
                 set(framework_flags "-framework ${framework}")
            endif()

            target_link_libraries("${target}" "${visibility}" "${framework_flags}")
        endif()
    endforeach()
endfunction()

This will prevent adding the framework to any target. Due to how CMake works with the modules, I couldn’t find a way to prevent adding the framework for just some plugin formats like with ProJucer.
This does break Standalone and probably AUv3 (not tested) as CoreAudioKit is required for Bluetooth midi pairing. If Bluetooth support is disabled by patching juce_mac_BluetoothMidiDevicePairingDialogue , Standalone can be built again without bluetooth midi support. Which is what I’ll do until Apple does fix this for real - or 10.11 and 10.12 have become really obsolete. I don’t believe there will be an official fix :frowning: .

68

We have had some responses from Apple and we will update this thread when we have information we can share. It looks like progress is being made. Apologies for the vagueness.

7 Likes
69

Any news?

5 Likes
70

I can confirm this fixed it for a user.

What’s the down side of this?

1 Like
71

At the moment, none that I know of.
But tomorrow’s a new day and Apple might add an assertion that a library isn’t loaded twice, which will cause this to fail.

1 Like
72

Is there still hope that this will be fixed by apple? Still getting bug reports because of this.

1 Like
73

I’ve not heard any new information since my last update, sorry.

3 Likes
75

Mind sharing the source for the script?

77

Oh my… How can one possibly and seriously think about sending something like that to customers…

display dialog "
OSX Logic Validation: Validate All AUs v1.0



INSTRUCTIONS: close Logic, click on Enable, type your password and when finished launch Logic and re-scan the AUs you want to be validated. If you want to go back to normal, re-launch this app and click Disable. 

The previously validated AUs will remain validated till you re-scan them :) Use this app every time you want to validate any AUs, getting rid of the [Incompatible] menu voice and the initial dialog warning you about Incompatible AUs!


USE AT YOUR OWN RISK! Tested on OSX 10.8, Logic X and Logic 9 (32bit & 64bit)



" buttons ["Enable Validate All AUs", "Disable Validate All AUs (back to normal)", "Quit"] default button 3

if button returned of result is "Enable Validate All AUs" then
	
	do shell script "if [ ! -f /usr/bin/auvaltoolBCK ]; then mv /usr/bin/auvaltool /usr/bin/auvaltoolBCK; echo '#!/bin/bash' >> /usr/bin/auvaltool; echo 'echo Authorizing..' >> /usr/bin/auvaltool; echo 'exit 0' >> /usr/bin/auvaltool; chmod +x /usr/bin/auvaltool; fi" with administrator privileges
	display dialog "Audio Units Validation: Validate All AUs enabled" buttons ["OK"]
	
else if button returned of result is "Disable Validate All AUs (back to normal)" then
	do shell script "if [ -f /usr/bin/auvaltoolBCK ]; then rm /usr/bin/auvaltool; mv /usr/bin/auvaltoolBCK /usr/bin/auvaltool; fi" with administrator privileges
	display dialog "Audio Units Validation back to normal" buttons ["OK"]
	
else
	
	stop
	
end if
79

I not only consider this a security risk because it’s brutally bypassing the auvaltool by replacing the binary with a dummy one, but I’m sorry to say I also find everything else very suspicious. First post and you “recommend” to distribute such a terrible hack?

1 Like
80

Additionally this doesn’t solve the issue. As long as the OS can’t load MobileDevice.framework the AUs won’t properly load even if they “pass” validation using this validation bypass hack.

83

FYI - this is pretty much our number one issue at the mo. Would be great to get a proper fix somehow !

85

Apple got back to me on this with the following advice

After reviewing your feedback, we have some additional information for you, or some additional information, or action is necessary for this issue: 

Please verify this issue with macOS 13 beta and update your bug report with your results by logging into https://feedbackassistant.apple.com/ or by using the Feedback Assistant app.

macOS 13 beta (22A5266r)
https://developer.apple.com/download/
Posted Date: June 6th, 2022

If the issue persists, please attach a new sysdiagnose captured in the latest build and attach it to the bug report. Thank you.

I don’t see how MacOS13 beta could fix this or it’s related to next Xcode

86

Copy&paste developer support - feels a bit disappointing for the $99/year.