Re:running certain spectral(?) plugins faster-than-realtime ... issues
Re:running certain spectral(?) plugins faster-than-realtime ... issues
- Subject: Re:running certain spectral(?) plugins faster-than-realtime ... issues
- From: Ian Kemmish <email@hidden>
- Date: Fri, 20 Aug 2010 16:15:54 +0100
On 20 Aug 2010, at 09:18:11, Paul Davis <email@hidden>
wrote:
That operation involves running the plugin faster than realtime - we
deactivate the plugin(s), reset their block sizes, reactivate them and
then run them as fast as the CPU allows. Is there likely to be some
issue that we are triggering that would affect FFT (and thus
presumably thread-using) plugins that has no impact on other plugins?
I can't think or any reason why code that uses FFTs would need to mess
about with threads.
However, code that processes samples in discrete blocks (such as FFT)
might well be more sensitive to the precise way in which you are
changing the maximum buffer size. Since you just say "deactivate" and
"reactivate" it's not clear what precisely you're doing, but it might
be worth checking that you're doing it exactly as Apple recommends.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds
SG18 8HZ
email@hidden Tel: +44 1767 601361 Mob: +44 7952
854387
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
_______________________________________________
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