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/

On Tue, 28 Jun 2005 21:38:32 +0100 Chris Cannam <cannam(a)all-day-breakfast.com> wrote: Yeah, you definetly are right. I wonder though: Why stop at garanteeing a fixed buffer size for the whole runtime. The thing with the partitioned convolution is that, when used purely as an effect for recorded material (i.e. not playing realtime through it, in a host that can compensate for plugin delay), then large buffers definetly are desirable. Even larger than i.e. the maximum period size of my soundcard (which is 2048 frames). So it would be cool, if the plugin could use a fixed buffer size which also differs from the buffer size used by the underlying audio system (i.e. jack). For this the host would have to do some extra work (setup an extra thread to process the plugin (with a slightly smaller priority than the jack audio callback thread for example, to even the load), ringbuffers to feed/consume data to/from it), latency compensation for tracks sent through it. Or should the plugin do this internally and simply report to the host that it needs a fixed buffer size (which then corresponds to the audio system's buffer size).. Are dssi/ladspa's allowed to do threading? Without i wouldn't know how to do it. And even if it were allowed to do threading, how would the dssi know which priorities to use, etc (on a RP kernel it should have prio higher than i.e. hd and net irq's, but lower than the jack audio thread). Plus i wonder whether the (then fixed) buffer size should be user configurable in any way or would the plugin simply report "16k frames is what i want" :) Sometimes it does make sense to use it in realtime mode (with the same buffer size as the audio system), if you have the cpu power or the responses are short enough. Regards, Flo -- Palimm Palimm! http://affenbande.org/~tapas/

My suggestion is to handle buffering in the convolution plugin and accept any buffer size from the host. I'd do it without threading to ensure the lowest possible latency. For example: assume we run convolution at 512 samples. use a ringbuffer structure (eg like RingBuffer.h in LinuxSampler). http://cvs.linuxsampler.org/cgi-bin/viewcvs.cgi/*checkout*/linuxsampler/src… (the process() in the example below is just a pseudo plugin API , input and output is mono) process(float *input,float *output, int numframes) { if(numframes == 512) { convolve(input, output, 512); return; } ringbuffer->write(input, numframes); while(numframes >0) { if(ringbuffer->read_space() >= 512) { ringbuffer->read(temp_buf, 512); convolve(temp_buf, output, 512); // does convolution and writes to the output array numframes -= 512; } else { write_silence(output,512); numframes -= 512; } } } This approach has the advantage that if the host supplies the convolution plugin with 512 frames then the added latency due to buffering is zero since if(numframes == 512) then it calls convolve() and returns without messing with ringbuffers. Otherwise, with the above approach both the number of frames used in the convolver and number of frames supplied by the host can be completely arbitrary. Drawbacks of the approach: especially on high CPU usage plugins (and convolution IS cpu hungry, especially at low buffer sizes), since the host will run the process() callbacks in RT mode, CPU spikes could introduce xruns and other bad stuff. Assume a 512 frames convolution will take 80% of the CPU on a certain machine. At 44.1kHz 512 frames = 11msec. 80% of 11msec =9.2msec If we run the above code in a host enviroment that uses eg 256 frames (5.5msec buffers), the first time process() is called the >=512 condition is not satisfied and thus a 0 filled buffer is returned (silence). At the second process() call, the >=512 condition is satisfied (there are exactly 512 frames in the buffer). And the convolve() function is called, eating 9.2msec of CPU. Since 9.2msec > 5.5msec ... sh*t happens ... XRUN. If numframes supplied by the host is bigger than 512 then there are no CPU spike problems. For example if the host supplies 1024 frames, the above code would call convolve() 2 times outputting 1024 frames. (eating 2x9.2msec out of the 22msec available) It would be a bit inefficient because if the plugin knows that the host supplies at least 1024 frames then you could run the convolution at 1024 achieving greater efficiency. If the host guarantees that it always supplies the same number of frames then the convolver could adjust it's internal framesize to to achieve optimal CPU usage. If not then a scheme like the above one is unavoidable. Just for curiousity, does anyone know that's the current status of the variable/fixed buffer sizes scenarios supplied to plugins by hosts on various plugin platforms like VST, AU etc ? The above code does some memory bouncing (only when numframes supplied by the host does not match the number of frames used in the convolver): it first copies the input to the ringbuffer's own buffer and then back to temp_buf. So some memory bandwidth is wasted but I think as long as you don't run hundreds of convolution plugins (impossible on today's machines) the added overhead is negligible since convolution is so CPU heavy. I think with an approach like the above you achieve the best of both worlds, no added latency if the host calls the plugin with numframes = power of 2 (matching the internal convolver's buffer size), and some added latency if the host does not use powers of 2. Regarding the CPU spikes, if the convolver uses less than 50% of CPU then you can run the host with the half convolver's numframes without getting XRUNs. eg if the convolver uses 40% CPU at 512 frames then running it in a host with 256 frames then the convolver will still use an average of 40% CPU but it will experience 80% CPU spikes. (eg 80% 0% 80% 0% etc ...). This is not so good because if we want to add an other plugin that has a constant CPU usage of 40% which would lead to an average 80% CPU usage we can't because during the 80% CPU spike we have only 20% of CPU headroom left. Florian, since we would like to add convolution to LinuxSampler over time it would be cool if you could add the above ideas to libconvolve so that one can use the lib without worrying about supplying the right buffer sizes etc, and in plugin hosts enviroments it would be handy too since we don't always know what the host will do. cheers, Benno http://www.linuxsampler.org Florian Schmidt wrote

On Wed, Jun 29, 2005 at 03:43:39PM +0200, Florian Schmidt wrote: There's another subtle bug here in that the plugin assumes that an output buffer of 512 samples is made available by the host, even if the host is using a fixed smaller period size. This is a hidden form of buffering at the output, and in fact, when your plugin algo uses a fixed block size internally but you want to call it with another value, fixed or not, you will always need buffering at both the input and the output. I wrote a convolver library / JACK app similar to Florian's at about the same time (which is why it was never released). Main differences are that the API is a bit more general, it's C++, and it has the required I/O buffering built-in right into the data structures of the convolver engine, so there is no extra overhead in copying. The API it such that the extra delay can be easily avoided if the conditions permit it. -- FA

Alfons Adriaensen wrote: amazing how many bugs a few lines of code can have :) You are completely right. I forgot the issue since I concentrated on the input buffering side but forgot that you can output only numframes supplied to the process() function. So a 2nd output ringbuffer buffer would be required. Nice. It would be cool if you and Florian could join forces to make such a general convolution lib which contains the goodies described in this thread like no added latency if the host buffer sizes matches the plugin's buffer size and provides the automatic input and output buffering in case of odd frame sizes. Given the ever increasing CPU power, convolution reverbs are probably going to become the common way to do high quality reverbs and such a convolution lib would avoid to have several developers reinventing the wheel all over again committing the same bugs etc. thanks, Benno

On Wed, Jun 29, 2005 at 05:45:12PM +0200, Benno Senoner wrote: Yes. In my lib, the two ringbuffers are part of the convolver, and the FFT and MAC operations operate directly on them. The API to write/read them is similar to ALSA's memory mapped buffer interface using *_prepare(), *_pointer() and *_commit() calls. This is AFAICT the most flexible interface you can have to circular buffers, enabling direct access. To disable the added delay when using a period size N equal to the convolver's, just call output_commit(N) once before starting the loop. Diversity is a good thing IMHO, and it's probably not bad to have both C and C++ versions. Both are (or will be in my case) GPL, so they will cross-fertilise anyway. For 'natural' reverb that will be the case. For 'effect' reverb, probably an algorithmic system wil provide much more flexibility and parameters. But you could even combine the two. The main problem with convolution based reverb is to obtain high quality impulse responses. It's not technical, but a matter of organisation, and of obtaining the permission to capture them and make them publicly available. WAVES has a number of very good ones (captured by Angelo Farina), but you first have to buy their reverb software to get access to them, even if most of them were recorded at places sponsored by public money (opera houses and churches). -- FA

fons adriaensen wrote: Another very useful feature would be tail extension (combine convolution with traditional reverb processing to lighten the CPU load) one commercial product that implements it: read the "Lighten the load on your CPU" section: http://www.tascam.com/Products/GigaPulse.html That way you can run for example a softsampler with more reverb instances (for multi part setups) and lower latencies (thus playable in real time) without killing the CPU. I'm not expert on the matter .... Fons, Florian do you think such a cpu load decreasing trick (without any/only a little audio degradation) would be doable without too much troubles ? cheers, Benno

On Wed, 29 Jun 2005 23:07:24 +0200 fons adriaensen <fons.adriaensen(a)skynet.be> wrote: To avoid the echo like character one could do some preprocessing. Take a chunk of the tail and make it constant volume (if it is decaying exponential, this should be possible). Then fiddle some more with it to make it loop cleanly. Then use that as response and apply gain and do the feedback delay thing. This would allow arbitrary envelopes on the tail. Regards, Flo -- Palimm Palimm! http://affenbande.org/~tapas/