Re: bastardizing AUEventListenerNotify() no longer working?
Re: bastardizing AUEventListenerNotify() no longer working?
- Subject: Re: bastardizing AUEventListenerNotify() no longer working?
- From: William Stewart <email@hidden>
- Date: Thu, 31 Dec 2009 18:03:02 +1100
On Dec 31, 2009, at 7:42 AM, Stephen Davis wrote:
> For a little test project I was abusing AUEventListenerNotify() to send property change notifications from my input render callback to the main thread but, as has been discussed previously, AUEventListenerNotify() no longer lets you send kAudioUnitEvent_PropertyChange notifications.
It doesn't? Can we get a bug report written, as I'm not aware that this has stopped working. The one issue that did come up was that providing NULL for the object parameter was failing (and I'm not sure that this every worked, as I seemed to remember having problems with this myself a while ago)
I also wouldn't call this "abusing" :) - it is really the kind of use that the API was provided for...
> Unfortunately, switching to the kAudioUnitEvent_ParameterValueChange version doesn't seem to work b/c faking the mAudioUnit parameter by casting a non-ComponentInstance pointer into it is failing in the call to AUEventListenerAddEventType() when setting up the listener.
yes - because the event listener is trying to get parameter information about the parameter you've provided
>
> Fair enough, I was abusing the API (test project!). I was doing so because it is a convenient API to use for sending messages from the render thread callback to my main thread, on the assumption that the underlying mechanism was implemented in a "don't take locks on the RT thread if at all possible" way.
Yep - it is :)
Bill
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden