Re: AUEventListeners dies
Re: AUEventListeners dies
- Subject: Re: AUEventListeners dies
- From: Hidetomo Katsura <email@hidden>
- Date: Thu, 28 Oct 2004 13:08:41 -0700
it's good to know. thanks.
katsura
On Oct 28, 2004, at 12:54 PM, Doug Wyatt wrote:
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