29 Jun
2005
29 Jun
'05
2:32 p.m.
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