AUs build with SDK >= 10.9 crash older auval. work-around + request

Hi,

AU plugins built with JUCE or otherwise based on the CoreAudio SDK crash auval on OS X 10.6.8 (bus error / segmentation fault), if they are built using OS X SDK 10.9 or above.

Just run auval -v PLUGINID -r 100 (100 repeats) and it will crash.

This is due to how auval reads the kAudioUnitProperty_HostCallbacks property. This property changed in OS X SDK 10.9 to add the HostCallback_GetTransportState2 callback (https://developer.apple.com/library/mac/releasenotes/General/APIDiffsMacOSX10_9/AudioUnit.html), so the property size (in 32-bits) grew from 16 bytes to 20 bytes.
auval gets the property info telling it that the buffer is 20 bytes, and then gets the property into a 16 bytes buffer, but tells the AU that the buffer is large enough, so the AU overwrites the buffer given to it.

A patch to the CoreAudio SDK to work around this auval bug:

typedef struct {
    void * hostUserData;
    HostCallback_GetBeatAndTempo beatAndTempoProc;
    HostCallback_GetMusicalTimeLocation musicalTimeLocationProc;
    HostCallback_GetTransportState transportStateProc;
} OldHostCallbackInfo;

at AUBase::DispatchGetPropertyInfo:

 case kAudioUnitProperty_HostCallbacks:
     ca_require(inScope == kAudioUnitScope_Global, InvalidScope);
-    outDataSize = sizeof(mHostCallbackInfo);
+    outDataSize = sizeof(OldHostCallbackInfo);
     outWritable = true;
     break;

at AUBase::DispatchGetProperty:

 case kAudioUnitProperty_HostCallbacks:
-    memcpy(outData, &mHostCallbackInfo, sizeof(mHostCallbackInfo));
+    memcpy(outData, &mHostCallbackInfo, sizeof(OldHostCallbackInfo));
     break;

 

I also verified on other parties' plugins and saw that other plugins from several different devs also crash on 10.6.8's auval. Picked ones from new devs or that I guessed that they use new Xcode. Tokyo Dawn Labs TDR Kotelnikov, tunefish4, A1Audio A1StereoControl - all crash too.

 

and a relevant request:

Now that there's no canonical location to put the CoreAudio SDK (as was with really old Xcodes), it would be nice if the location of the SDK was a parameter to Introjucer like the other SDKs. Then I could be sure that there's no confusion and I'm using the fixed CoreAudio SDK from my source dirs..

Cheers, Yair

Incredible. Most of the code that Apple publishes is obviously up to a really high standard - I just don't understand why their AudioUnit stuff is such a total car-crash compared to everything else they do!

Yep, adding a path to the introjucer does seem like a good idea now.

FYI that path should be there now - I've not tried setting it myself, let me know how you get on!

There's a problem with using relative paths for the SDK.

Here's a fix: https://github.com/soundradix/JUCE/commit/198b008762cdd6576d84480857630744e6038599

Cheers, Yair

stupid question, are we still using the SDK-Files, from the Package "Audio Tools for XCode - Feburary 2012", it seems to be the last package which contains the CoreAudio Headers? And is there a overview which patches should be applied? Its a big kuddelmuddel

There's a newer version.

We're using version 1.1 over here where the files have comments saying "Copyright (C) 2014 Apple Inc. All Rights Reserved.", with the patch mentioned in this thread.

There's a newer version.

We're using version 1.1 over here where the files have comments saying "Copyright (C) 2014 Apple Inc. All Rights Reserved.", with the patch mentioned in this thread.

thanks, AHHHHHH, i think i found it , but its its confusing... ;)

If you use this link https://developer.apple.com/library/mac/samplecode/CoreAudioUtilityClasses/Introduction/Intro.html

then --> Download Sample Code, and you get the current headers.....

I always downloaded it from the "additional downloads section" where the least package which contains the headers was February 2012