Using CATink (was Re: Shouldn't AudioUnitRemovePropertyListener() accept refcon also?)
Using CATink (was Re: Shouldn't AudioUnitRemovePropertyListener() accept refcon also?)
- Subject: Using CATink (was Re: Shouldn't AudioUnitRemovePropertyListener() accept refcon also?)
- From: Bill Stewart <email@hidden>
- Date: Tue, 27 May 2003 12:12:05 -0700
Yes, but we didn't think about this at the time we defined the API!...
So, there is a slight inconsistency - render notifications can be
specialised on the Proc/RefCon pair - whereas property listeners are
only speicified on the address of the listener proc as you say.
For Render notifications this was extremely important to add because of
the nature of the different objects that can be listening for render
notifications...
For Property Listeners there is a workaround to this - In the SDK code
there's a PublicUtility folder, and in that a CATink.h file - if you
use that technique as part of the process of adding property listeners,
it will create unique Procs each time you add a callback:
// the HAL's listeners have the same restriction - so we use tinks here
as well
CATink<AudioDevicePropertyListenerProc> mDeviceDelegateListener;
Then you register the CATink:
AudioDeviceAddPropertyListener(mDevice, devicChannel, inputOrOutput,
propertyID, mDeviceDelegateListener, this);
Where mDeviceDelegateListener is defined to point to a static method on
the class - MyClass - (and <this> above is the instance of the class)
mDeviceDelegateListener(DeviceDelegateListener),
Here's a sample of what this Delegate Listener does - as you can see it
has the same declaration as the AudioDevice PropertyListener callback
and than just calls through to an instance method on the MyClass
object...
OSStatus AUHAL::DeviceDelegateListener(
AudioDeviceID inDevice,
UInt32 inChannel,
Boolean isInput,
AudioDevicePropertyID inPropertyID,
void* inClientData)
{
OSStatus result = noErr;
MyClass *This = (MyClass *)inClientData;
// delegate
This->PropertyChanged (inPropertyID, /*whatever you need to know...*/);
return result;
}
Bill
On Saturday, May 24, 2003, at 09:50 AM, David Duncan wrote:
>
In AudioUnits/AUComponent.h AudioUnitRemovePropertyListener() is
>
defined as follows:
>
>
EXTERN_API( ComponentResult )
>
AudioUnitRemovePropertyListener(
>
AudioUnit ci,
>
AudioUnitPropertyID inID,
>
AudioUnitPropertyListenerProc inProc)
>
>
while the similar AudioUnitRemoveRenderNotify() is defined as:
>
>
EXTERN_API( ComponentResult )
>
AudioUnitRemoveRenderNotify(
>
AudioUnit ci,
>
AURenderCallback inProc,
>
void * inProcRefCon)
>
>
Assuming (eek!) that these calls work similarly (that is a
>
callback+refcon is considered a specific entity, not just the
>
callback) then shouldn't AudioUnitRemovePropertyListener() also need
>
the refcon to properly remove the callback (such as the case where
>
multiple callbacks are registered with the same proc but different
>
refcons, as you would using a C++ class for example)?
>
--
>
Reality is what, when you stop believing in it, doesn't go away.
>
Failure is not an option. It is a privilege reserved for those who try.
>
>
David Duncan
>
_______________________________________________
>
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.
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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.