Re: AUEventListeners dies
Re: AUEventListeners dies
- Subject: Re: AUEventListeners dies
- From: Urs Heckmann <email@hidden>
- Date: Sat, 4 Jun 2005 12:19:29 +0200
Thanks,
that was the info I was looking for 8-)
Cheers,
;) Urs
Am 03.06.2005 um 19:51 schrieb William Stewart:
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