Re: AUEventListeners dies
Re: AUEventListeners dies
- Subject: Re: AUEventListeners dies
- From: William Stewart <email@hidden>
- Date: Fri, 3 Jun 2005 10:51:25 -0700
We addressed all of the known issues with the Param/Event Listener
APIs in both Tiger . For Panther we took those fixes back as well, so
the CA pieces distributed as part of QT 7's download, also contain
these.
If problems persist in this area with these pieces, please file a bug
report.
Thanks
Bill
On 03/06/2005, at 3:41 AM, Urs Heckmann wrote:
Hiya,
sorry for necrojacking this topic, but I think I have that
situation with a customer now. The guis of my stuff seem to lose
contact to the dsp all out of the sudden. AFAIK this happens only
on his machine.
Is there a fix for Panther meanwhile, i.e. 10.3.9 & QT 7 or something?
Thanks,
;) Urs
Am 28.10.2004 um 21:54 schrieb Doug Wyatt:
I isolated this a couple of weeks ago. It's a bug in an OS layer
below AudioToolbox, and should be fixed in Tiger. Unfortunately
there is no simple workaround.
Doug
On Oct 28, 2004, at 11:44, Hidetomo Katsura wrote:
what's the status on this bug? is there any recommended workaround?
i'm having this problem with AUParameterListenerNotify with my
Cocoa UI AU plug-ins after about five minutes or sometimes much
sooner on PowerBook G4 500MHz but not on G5 Dual 2GHz.
AUParameterListenerNotify returns noErr but the listener never
gets called. in my case, it comes back if i reselect the plugin
in the host app.
regards,
katsura
On Aug 24, 2004, at 11:55 AM, Doug Wyatt wrote:
I wonder if there's a critical region that can cause the timer
that delivers the notification to get into a state where the
AUEventListener mechanism thinks that the timer is scheduled but
actually it's not ... can you please write a bug so this doesn't
slip through the cracks?
Thanks
Doug
On Aug 23, 2004, at 11:32, Marc Poirier wrote:
I'm experiencing behavior where all AUEventListeners in a given
process can just die. I actually first saw this a long time
ago (maybe a year ago), but it's become more of a concern now
that it's happening very reliably with my current project.
Basically, what I see is that, with AUs that have high-density
AUEventListener notifications, eventually, the whole system
just dies. Specifically, what happens is that the registered
AUEventListenerProc stops being called. Calls to
AUEventListenerNotify() still succeed (or at least they return
noErr). And new AUEventListeners can be created without
returning an error (though they won't work at all), like by
creating another instance of the AU.
And that's really an interesting part, once the system dies, it
is really dead. If I have multiple instances of the AU open,
then all instances will stop updating. Even if I deinstantiate
them all and then reinstantiate the plugin, the new instance
will not update. In fact, if I go and instantiate an entirely
different plugin (like my RMS Buddy one, which frequently
notifies for level monitoring), that one won't work either (and
also odd is that RMS Buddy actually uses a parameter listener
to send notifications rather than an AUEventListener, but it
still is affected). Though an even weirder aspect is that I've
experienced the case where, in Logic, I can close the current
song and then open a new one and then new instances of the AU
will work again, without needing to quit Logic, but closing the
song is necessary. I really don't know what changes when the
song is closed in Logic.
Well anyway, in this particular case, I am sending
notifications that are driving some level meters and clip
lights on the custom GUI. This means, for each instance, a
notification happening every 60 ms with a listener installed
with update interval and granularity of 30 ms. Each update
triggers the redrawing of 2 to 5 controls (depending on the
values). I used to have the notifications being sent out about
10 times as often (with every render slice), and then, with 2
instances of the AU open, it would take about 1 to 2 minutes
for the notification system to die. Now that I've slowed it
down, with 2 instances open, it takes about 10 to 15 minutes
before it dies.
I've seen this behavior over the past year occasionally with my
RMS Buddy and EQ Sync AUs http://destroyfx.org/audiounits.html
but now much more with these new ones, which I guess are doing
more work. Has anyone else seen this before? It really
doesn't seem like I'm doing anything wrong in my code, so I'm
wondering if this sounds feasible that the AUEvent system could
get overloaded? Is there something that I need to do to
prevent this? Any insights or tips would be much appreciated...
thanks,
Marc
_______________________________________________
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
--
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
________________________________________________________________________
__
_______________________________________________
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