Re: Parameters & Listeners & Host & Cocoa
Re: Parameters & Listeners & Host & Cocoa
- Subject: Re: Parameters & Listeners & Host & Cocoa
- From: Marc Poirier <email@hidden>
- Date: Tue, 13 Jan 2004 16:19:34 -0600 (CST)
Thanks for the info, Bill. Actually, in between the time when I sent this
message and when you replied (I know, you were on holiday, I'm not
complaining ;), I did a lot of reading up on weak-linking,
cross-development, AvailabilityMacros.h, etc. at ADC and learned more
about this stuff. So while we could all dynamically grab the funtion
pointer out of the AudioToolbox.framework, it's kind of annoying in my
opinion, and I think that it hopefully should be possible to weak-link the
symbol instead. But unlike most of the framework headers,
AudioToolbox.framework/AudioUnitUtilities.h does not use any of the
availability macros. So far as I could determine, there's no way to get
weak-linking happening with Mach-O executables without this. At least I
can't figure out a way to mark an entire framework for weak-linking or
anything like that.
In order to get weak-linking happening for those new functions, I had to
do 2 things:
1) I had to add this build setting to my project:
MACOSX_DEPLOYMENT_TARGET=10.2
(I think there's a GUI pop-up option for this in Xcode, but I'm using PB.)
2) I had to add the WEAK_IMPORT_ATTRIBUTE macro to the end of each
AUEventListener* function prototype (right before the ;), e.g.:
extern OSStatus
AUEventListenerCreate( AUEventListenerProc inProc,
void * inCallbackRefCon,
CFRunLoopRef inRunLoop,
CFStringRef inRunLoopMode,
Float32 inNotificationInterval, // seconds
Float32 inValueChangeGranularity, // seconds
AUEventListenerRef * outListener) WEAK_IMPORT_ATTRIBUTE;
I could have also used the AVAILABLE_MAC_OS_X_VERSION_10_3_AND_LATER,
which maybe makes a little more sense (it's probably not desirable for
Apple to hard-code weak-linking to any of the framework symbols), but
still not necessarily totally appropriate since those functions can exist
in 10.2 systems with QT 6.4. But I'm not sure, maybe Apple should just
ship those headers with the AUEventListener* stuff marked as
10_3_AND_LATER just so that weak-linking is possible? Although...
Another thing that I found while reading up on this stuff was here:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/cross_development/Concepts/cd_how_it_works.html#BABBBGCD
and it said:
QuickTime has a separately distributed SDK that can be installed on any
variant of Mac OS X version 10.2 or 10.3. As a result, certain QuickTime
APIs are not bound to a particular version of the OS. In addition, when
you install a QuickTime SDK, it's installed into your current operating
system, not into any of your developer SDKs. Because a developer SDK does
not necessarily include the headers from the latest software update of
QuickTime, you can't currently use SDK support and the QuickTime SDK
simultaneously.
Note: QuickTime and some related components, such as Core Audio, provide
extensions to the availability macros that tell you which features are
available in particular QuickTime software updates.
So what exactly are these "extensions to the availability macros"? I
couldn't find any more info about this.
Also, does anyone know if it's possible to do any of this weak-linking
stuff with CodeWarrior? WEAK_IMPORT_ATTRIBUTE is only #defined for gcc
3.1 or higher and not any other compilers.
Thanks,
Marc
On Thu, 8 Jan 2004, William Stewart wrote:
>
Marc,
>
>
Yes - running against a pre-QT 6.4/Jag or Panther system, you'd have to
>
do a dynamic load of the AUEvent*** calls as they won't be found in
>
those systems (thus the failure)
>
>
We do this ourselves in a number of places and it is probably good for
>
us to add this to the SDK so you can easily rip this code out and use
>
it.
>
>
Bill
>
>
On 18/12/2003, at 1:24 PM, Marc Poirier wrote:
>
>
> William Stewart wrote:
>
>
>
>> I'd recommend taking Marc's idea and doing both this and the
>
>> AUEventListener begin/end gesture for the meantime, then at some point
>
>> remove the calls to TellListener
>
>
>
> I'm encountering some troubles with this, well, basically I mean
>
> crashing
>
> in pre-10.3 and pre-QT 6.4 systems. Here's a console.log bit from
>
> when I
>
> tried to load one of these plugins in AUH in OS X 10.2.4 with QT 6.0.1:
>
>
>
> 2003-12-18 14:58:52.110 AudioUnitHosting[568] CFLog (21): Error
>
> loading : error code 7, error number 0 (dyld:
>
> /Developer/Examples/CoreAudio/Services/AudioUnitHosting/build/
>
> AudioUnitHosting.app/Contents/MacOS/AudioUnitHosting Undefined
>
> symbols:
>
> /Users/marc/Library/Audio/Plug-Ins/Components/Buffer
>
> Override.component/Contents/MacOS/Buffer Override undefined reference
>
> to _AUEventListenerNotify expected to be defined in AudioToolbox
>
> )
>
> DebugAssert: AUGraphNewNode(mGraph, &inDesc, 0, inClassData,
>
> &mTargetNode)== noErr [-50] exception [line 302, file
>
> AudioUnitHosting.cpp]
>
>
>
> So the error is not that AUEventListenerNotify is being (attempted to
>
> be)
>
> executed when it's not available. It doesn't even get that far. The
>
> error is that the plugin's executable can't even be loaded to start
>
> with
>
> because of the unresolved symbol. So what's up with that? Is it
>
> going to
>
> be no longer to run my plugins without QT 6.4 now that I use
>
> AUEventListenerNotify in my code? I'm conditionalizing any calls to it
>
> with a check to make sure that AudioToolbox 1.3 is available, but as I
>
> said, it's not even getting that far; OpenAComponent is failing. Any
>
> tips would be much appreciated...
>
>
>
> Thanks,
>
> Marc
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.