Re: [linux-audio-dev] jack_convolve-0.0.10, libconvolve-0.0.3 released

On Mon, 27 Jun 2005 14:24:36 +0000 GMT "Chris Cannam" <chris.cannam(a)ferventsoftware.com> wrote: There are some problems with wrapping partitioned convolution into a ladspa/dssi. One of them is that ladspa/dssi do not garantee a chunk size in which the processing needs to be done. Partitioned convolution, like many other fft based algos operates with a fixed chunk size. It basically looks like this: 0] initialization phase ("loading a response file"): split the response file into chunks. zero pad them and fft them. store the fft'ed chunks somewhere.. then for every chunk of audio: 1] zero pad and fft the input chunk 2] store the fft'ed chunk in a ringbuffer (which has space for as many chunks as the response has, too) 3] multiply the fft'ed input chunks from the input ringbuffer to the corresponding fft'ed response chunks and add all these. 4] ifft the result from step 3] 5] save overlap, add previous overlap So, the partition/chunk size is determined in the initialization phase and all processing later on happens in chunks of this size. Now ladspa/dssi make no garantees about the buffer size with which the processing is done. Thus there would need to be done some extra buffering. But to distribute the load (assuming partition size is bigger than ladspa/dssi processing size) it would be nessecary to either a] split the above algorithm into pieces (which is rather difficult due to the different phases each depending on the result of the previous phase) b] use threading Both methods are kinda ugly or work intensive. Another reason is that it is impossible to dynamically change the number of input/output ports of a ladspa/dssi which would restrict the loadable responses to stereo files if the ladspa/dssi has i.e. two outputs. this would then require seperate versions for different channel counts. All in all and as i am an energy saver (mostly my own though) i will refrain from implementing a ladspa/dssi plugin. libconvolve isn't soo hard to use though, so someone else might give it a shot. Contact me though. The api might still change abit in the future (as i'm adding/removing experimental features like for example looped responses). After a discussion with Mario Lang i think i will OSC'ify jack_convolve though and make the qt gui only an OSC controller for jack_convolve. Flo -- Palimm Palimm! http://affenbande.org/~tapas/