[LAD] ANN: convoLV2 0.2

Fons Adriaensen fons at linuxaudio.org
Sat Oct 20 21:03:44 UTC 2012

On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote:

> 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.

What's the problem with the semas ? They are the simplest and most
efficient way to signal an event. And unless you use the 'sync' mode
(which you should do only when Jack is freewheeling), they are used
only to trigger the lower priority threads, and the thread calling 
Convproc->process() will never wait for a sema or be blocked.

And what's the problem with the threads ? The only one I see is that
LV2 doesn't have any way to pass the required priority parameter, but
there are simple ways around that.
> 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.

CPU load per cycle will be strictly constant if the minimum partition
size is equal to or greater than the period. This was a design requirement.
When you use a period size smaller than 64 frames you have to buffer
up to 64 frames, and indeed in that case you will call Convproc->process()
in some cycles and not in others. But if you use multiple partition sizes
then only a small fraction of the work is done synchronuously, so even if
the load is not strictly constant, the variation will be small compared
to the total load. 



A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)

More information about the Linux-audio-dev mailing list