On 10/20/2012 01:44 PM, Fons Adriaensen wrote: > ConvoLV2 uses libzita-convolver, but in a very inefficient way,
Yes, we are aware of that. At this point in time we favor clean design over efficiency. The choice to use a fixed blocksize comes from the fact that we do not want libzita-convolver to spawn addtional threads nor makes use the semaphores in libzita's process callback. >> This plugin is intended to provide latency-free synchronous convolution, >> which inherently requires these restrictions. > > This is simply not true. [..] The plugin uses a single non-threaded libzita-convolver Convproc instance which imposes those restrictions. > Thirdly, for the use case of reverbs, the whole latency issue is > just irrelevant. quite so. But not all convolution is reverb. The real issue we have is small block-sizes in general. Effect processing in cycles smaller than 64 ffp are not too unusual. The current block-size limitation in Convproc does not allow an even distribution of the CPU load across process cycles. Nor does using background threads and thread sync methods in the process callback. This becomes particular important for very small cycles. The current sync mechanism in libzita convolver can not guarantee to process N samples in time. There are small subtleties WRT to synchronization in particular because the LV2 process callback can be used in both realtime and offline rendering mode, which may change without prior notice. Currently these shortcoming are a feature. We wanted a LV2 plugin that demonstrates new LV2 features - in particular a plugin that demos instantiation options. One of those being frames-per-process cycle limitations that the plugin can impose. For a later, user-centric release, we're planning to use the hybrid direct FIR + FFT (libzita) approach that you suggested and things will change. We very much appreciate your feedback. Should you become bored on one of those upcoming Italian winter nights, we'd very much appreciate some insight regarding a lockless, threadless implementation possibility. ciao, robin _______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev