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. 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) _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
