Re: AUEventListeners dies
Re: AUEventListeners dies
- Subject: Re: AUEventListeners dies
- From: Hidetomo Katsura <email@hidden>
- Date: Thu, 28 Oct 2004 11:44:38 -0700
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