On Wed, Oct 12, 2011 at 02:58:40PM -0700, Aaron Heller wrote: > http://threadingbuildingblocks.org/ > > I haven't studied zita-convolver in any detail, so I don't know how > amenable it would be to that kind of approach.
Not very much probably. Zita-convolver is not designed to optimize the use of multiple CPUs, although it will do this if you run multiple instances, even if they a have a sequential data dependency. One of the design goals was to run long multichannel convolutions (e.g. AMB reverbs) efficiently *and* wihout processing delay. For this it uses multiple partition sizes, in a sequence determined by the number of input and outputs, the maximum length of any IR, and the density of the matrix. A second design goal was to run mixed-size convolutions efficiently. Imagine a 3-D matrix, the two first dimensions are the inputs and outputs, the third is the time axis - a sequence of individual partitions. Each cell of this matrix takes CPU time only if there is some IR for the input, output and time range it corresponds to. FFTs are optimized in a similar way, and the logic controlling all of this is very lightweight. An absolute requirement was also that the convolver should be a 'well behaved' processing unit, one that takes a constant time for each call processing a block of samples, even if that block size is a small fraction of the longer partition sizes used. So you don't e.g. call a 1024 point FFT in each 16th call processing 64 samples. This is in fact the main reason why zita-convolver is multithreaded at all. All of this means that you want rather explicit control over how things are scheduled. Ciao, -- FA _______________________________________________ Sursound mailing list Sursound@music.vt.edu https://mail.music.vt.edu/mailman/listinfo/sursound
