20 Oct
2012
20 Oct
'12
11:03 p.m.
On Sat, Oct 20, 2012 at 07:43:38PM +0200, Robin Gareus wrote:
On 10/20/2012 01:44 PM, Fons Adriaensen wrote:
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.
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. 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.
Ciao,
--
FA
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)