> 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