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: Robert Abernathy <email@hidden>
- Date: Fri, 7 Dec 2007 10:40:06 -0700
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