On Wed, Jun 29, 2005 at 05:45:12PM +0200, Benno Senoner wrote: > So a 2nd output ringbuffer buffer would be required.
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. > 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. 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. > 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. 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
