Re: [LAD] FLTK vs GTKmm

From: Fons Adriaensen <fons@email-addr-hidden>
Date: Tue Aug 11 2009 - 20:54:58 EEST

On Tue, Aug 11, 2009 at 06:50:50PM +0200, Jens M Andreasen wrote:

> That would be four warps
> independently working their way through the variously sized sample
> blocks, each thread execting serial code that looks very much the same
> as jconv itself, including the threading.

Note that the algorithm implemented by libzita-convolver (used by
jconv) when used in real-time mode relies on regular scheduling
(i.e. being called from a Jack process callback) and carefully
set thread priorities.

How to structure a convolution engine to run on a graphics
processor would very much depend on where you want the I/O.
If it remains a Jack app then the easiest way would be to
offload the work done for the larger partition size(s) to
the graphics processor. Timing is absolutely not critical
in that case, but if more than one partition size is moved
in that way, or if you have more than one instance running
you'd still need to respect relative priorities.

Now jconv is a general purpose tool designed to efficiently
handle any convolution matrix, including sparse ones. If you
use it for reverb the matrix size is small (usually 1x2 or
2x2 for stereo). An application that runs e.g. 8 of those
can be structured in a completely different way that could
avoid the use of multiple priorities.
 
> How much jconv would something like a 300Mhz Pentium Pro buy me? (Just
> to get a hunch if this would be a possibility at all)

Almost impossible to tell without trying. It also depends
in a very complex way of the configuration - the ratios
will not be the same on all machines.

Jconv's predecessor, jace, worked by trying to distribute
the work done on large FFTs and MACs as evenly as possible
over callbacks with a shorter period. A condition for doing
this is of course that you can estimate the work to be done
in the first place. It was the impossibility of doing this
for the more general use cases that jconv is supposed to
handle that forced me to adopt the multi-threaded/multi-
priority solution.

Ciao,

-- 
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Aug 12 00:15:03 2009

This archive was generated by hypermail 2.1.8 : Wed Aug 12 2009 - 00:15:03 EEST