Re: [LAD] ANN: convoLV2 0.2

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@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun Oct 21 00:15:01 2012