[linux-audio-dev] Arbitrary bufsizes in plugins requiring power of 2 bufsizes, Was: jack_convolve-0.0.10, libconvolve-0.0.3 released

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