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

Audio Plugins
1

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

2

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.

3

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

4

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

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

Cheers, Yair

5

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

6

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.

7

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.

8

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