Alfons Adriaensen wrote:
>On Wed, Jun 29, 2005 at 03:43:39PM +0200, Florian Schmidt wrote:
>
>
>
>>This has a subtle bug afaict. Let's assume the host called several
>>process() with numframes != 512 first, then one with numframes == 512, i.e.:
>>
>>1. 123
>>2. 432
>>3. 234
>>4. 512
>>
>>The 4th process call disregards data already in the ringbuffer which has
>>been put there by previous calls with numframes != 512. There needs to
>>be an additional test for whether the ringbuffer is empty.
>>
>>
>
>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.
>
>
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.
>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.
>
>
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
Received on Thu Jul 7 16:16:15 2005
This archive was generated by hypermail 2.1.8 : Thu Jul 07 2005 - 16:16:16 EEST