Re: AUEventListenerNotify paramErr for PropertyChange events on Leopard
Re: AUEventListenerNotify paramErr for PropertyChange events on Leopard
- Subject: Re: AUEventListenerNotify paramErr for PropertyChange events on Leopard
- From: William Stewart <email@hidden>
- Date: Fri, 7 Dec 2007 12:18:24 -0800
Yes - good catch, the tech note is wrong (and the code there was never
run I presume!)
It will need to be fixed
Bill
On Dec 7, 2007, at 9:40 AM, Robert Abernathy wrote:
I had run into this same issue when moving to Leopard. I've moved
everything to the PropertyChanged method and things look to be
working fine. But, there is a technical note (TN2104) that
certainly seems to recommend using AUEventListenerNotify for this
case.
http://developer.apple.com/technotes/tn2002/tn2104.html#PROPERTIES
It could easily be that I'm misreading the intent of the technical
note, but, if PropertyChanged is really the right way to go, then
the technical note may need to be updated.
Thanks,
Rob
On 5 Dec 2007, at 20:19, William Stewart wrote:
On Dec 5, 2007, at 6:59 PM, Sophia Poirier [dfx] wrote:
On Dec 5, 2007, at 9:46 PM, William Stewart wrote:
You shouldn't need to make this call from within an AU - all you
need to do there is call the AUBase::PropertyChanged method
(which in turn will turn around and call of the registered
property change listeners iwth the AU).
Oh hmmm, I thought it had to do with not blocking a render thread,
that it was better to call AUEventListenerNotify() if you're
sending the property change from within audio rendering. Am I
incorrect about this and is PropertyChanged() in actually fine for
that?
Its more on the listening end for properties. The property changed
notify is executed on the thread you issue it on, but the real
trouble can start when that callback is executed. So, for instance
a view that is listening for property changes, should definitely be
using the EventListener (otherwise those callbacks would execute on
the render thread in this case).
When you instantiate a listener using the event listener (say your
view), the event listener installs a property listener on the AU.
When that property listener is called, it doesn't call the event
listeners, but rather just registers that the property has changed,
and sets the wheels in motion so that the actual event listeners
will fire on their appropriate threads.
That said, we will look into this (as there's nothing here that
looks obviously wrong to me
Thank you.
We normally don't expect the ListenerNotify to be called from
property changes, so that could be why you are seeing a discrepancy
here
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
_______________________________________________
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