> > Well, I'll shut up about it. I still think it is a mistake. I haven't heard > > any > > convincing (to me) arguments why an application should not handle variable > > sized callbacks. > > Because it makes certain types of processing viable, which they are not > really in variable block systems (eg. LADSPA, VST). Have a look at an > phase vocoder implementation in LADSPA (e.g. > http://plugin.org.uk/ladspa-swh/pitch_scale_1193.xml) or VST and see how > nasty and inefficient they are.
If I understand that code correctly then you wait for 'FFT frame size' samples to be available and then process that entire FFT frame. This will not introduce a variable amount of processing time/sample and will not work for large FFT frames. Adding en extra FFT frame delay and processing asynchronously would solve this. I'm not saying this is easy, but I don't think an algorithm like this should rely on a callback being one (or more) FFT frame long. > Conversly we haven't heard any convincing arguments about why we should > have variable block sizes ;) I don't think that allowing (some?) USB > devices to run with less latency counteracts the cost to block processing > algorithms. I think is at least as valid an argument as a possible increase in performance for some algorithms on some hardware. > I dont know what EASI xfer is. EASI is a hardware abstraction framework from Emagic. It was meant to be a open alternative to ASIO. It didn't make it and now that Emagic has been acquired by Apple it is no longer supported by Emagic I guess, as I can not find anything about it on their site anymore. http://www.sipkema-digital.com/~msipkema/EASI_99may25.pdf --ms
