Issue with Audio Unit on 10.11

Audio Plugins
111

Thanks for the patch!

112

so trueā€¦ Iā€™m also finished with this one.

Apple does not care about 10.11 users anymore. Itā€™s annoying because they broke running systems and you would expect that they invest a few hours to repair the damage they did.
On the other side, it is a wrong sign to bring out a patch for a system that is a security risk anyway and is not supported anymore. I also understand that side.

In the worst case, where musicians and producers lose money, they have to take the painful path and revert to the older mobile framework update like described above.

113

I canā€™t believe it. Apple still installs the faulty update to 10.11 systems. They donā€™t stop until all machines have installed this update. No one on a 10.11 system is allowed to make music anymore :crazy_face:

114

Still having customers with this issue. Any more news on it, on any front (ProJucer, Apple, anything)?

We now have a 2016 MBP that is running 10.12, and weā€™re unable to trigger this issue - all the Valhalla plugins are running fine on our 10.12 machine. Does anyone have any consistent steps to replicate this issue on 10.12?

Thanks,

Sean Costello

115

Update: we got things to break. Just had to rescan the plugins in Logic after backing up an iPhone.

Interestingly enough, the MobileDevices.framework that is causing the issue dates from May 27 2022. This is well after folks that work in the audio division of Apple had been notified about this issue, and had said that they would look into fixing this issue. So, this makes me give up hope that we will ever see a solution from Apple.

116

Maybe someone at ADC will have a chance to talk to them in person about this :crossed_fingers:

image
image594Ɨ837 140 KB

7 Likes
117

Hi, I went with the patched projucer solution that was proposed earlier in this thread. It was very hard to test, to reproduce the issue and to confirm the workaround. A colleague had to set up a dedicated mac with a 10.11 or 10.12 install, which was a lot of work, and I ended up debugging on that machine remotely. The thing is that somehow the particular broken framework patch from apple must be installed on the machine, and in general itā€™s very tricky to install old mac os versionsā€¦
Now, with xcode 14 and JUCE7, Iā€™m seriously considering rising minimum OS requirements to 10.13 though, because going through all of this again would probably cost a few days, if itā€™s possible at all: I think I read somewhere that support for 10.11 and 10.12 is EOL in xcode 14.

1 Like
118

For new projects, I agree a higher minimum OS requirement is the right move, but problems can arise for existing plugins that might need a bug fixed without breaking things for people running old OSes. Instead of tedious testing, you can just run

otool -L [PATH_TO_BINARY_INSIDE_PACKAGE] | grep CoreAudioKit

If this doesnā€™t print out anything, the binary is not linked with CoreAudioKit and there is zero chance of this particular problem occurring on any OS version.

1 Like
119

Iā€™ve tried to patch Projucer as explained earlier, but no matter which configuration/target Iā€™m using, Iā€™m always getting this error:

Undefined symbols for architecture arm64:
  "_OBJC_CLASS_$_CABTLEMIDIWindowController", referenced from:
      objc-class-ref in libSprings.a(include_juce_audio_utils.o)
ld: symbol(s) not found for architecture arm64

Our default deployment target is 10.9, but I also tried 10.11 and 10.12.

I found a workaround, if I comment out everything in juce_mac_BluetoothMidiDevicePairingDialogue.mm and compile only in Release mode, it works.
Any idea what I should do to avoid this error?

120

That class seem to belong to the CoreAudioKit framework, are you sure you have that Framework present in your project and marked for linking in your target?

121

Well, the whole purpose of patching the Projucer is to avoid linking to CoreAudioKit, so it makes sense it fails. But I have no idea why that class is being added and from where. Canā€™t find any obvious flag in Projucer.

122

This class is part of the Bluetooth Low Energy Midi support in CoreAudioKit. I have commented those JUCE parts out as well. For plugins, this is absolutely irrelevant, and I think it only gets compiled if you include a ā€œStandaloneā€ build. Itā€™s only needed if you want to support wireless bluetooth midi connections to your standalone version.

Update: I checked my original crude ProJucer patch. Iā€™m sorry I forgot to mention that part. I just did this to disable bluetooth midi support and avoid requiring CoreAudioKit:

bool BluetoothMidiDevicePairingDialogue::open (ModalComponentManager::Callback* exitCallback,
                                                Rectangle<int>* bounds)
 {
-    if (@available (macOS 10.11, *))
+   /* if (@available (macOS 10.11, *))
     {
         new BluetoothMidiSelectorWindowHelper (exitCallback, bounds);
         return true;
     }
+    */
 
     std::unique_ptr<ModalComponentManager::Callback> cb (exitCallback);
     // This functionality is unavailable when targetting OSX < 10.11. Instead,
@@ -173,8 +174,8 @@ bool BluetoothMidiDevicePairingDialogue::open (ModalComponentManager::Callback*
 
 bool BluetoothMidiDevicePairingDialogue::isAvailable()
 {
-    if (@available (macOS 10.11, *))
-        return true;
+ //   if (@available (macOS 10.11, *))
+ //       return true;
 
     return false;
 }
3 Likes
123

Ah, it works now. Thank you so much!

124

Ah right, my bad. I blindly answered the simplest solution, without realizing that this is the topic about that problematic framework. Context is everything :sweat_smile: .

1 Like
125

Eheh no problem at all :slight_smile:

126

Seems I caught this one too, finally. Thanks everyone here for figuring this one out!

Iā€™m looking into removing CoreAudioKit from my CMake builds as well, but having to patch the JUCE submodule messes up my git and versioning concept. So Iā€™ve figured out a solution that works without patching, simply by removing linkage to CoreAudioKit from affected modules after the fact.

Note that this will break Standalone builds, so I only do this for Release builds where I donā€™t build Standalone anyway.

A bit of a hack, but maybe this can be useful to someone else as well:

set( affected_targets
    juce_audio_plugin_client_AU
    juce_audio_utils
)

foreach( tgt IN LISTS affected_targets )
    get_target_property( libs ${tgt} INTERFACE_LINK_LIBRARIES)
    list( FILTER libs EXCLUDE REGEX "CoreAudioKit.framework" )
    set_property( TARGET ${tgt} PROPERTY INTERFACE_LINK_LIBRARIES ${libs} )
endforeach()
1 Like
127

This solution looks great. One question, can I put this at the end of the CMake file?

Edit: It looks like it worked when i paste this at the end of the CMake file. I canā€™t see the dependency anymore with apples otool. Thanks a lot for sharing this.