Re: [linux-audio-dev] LV2 buffersize extensions (was: LADSPA...)

On Monday 29 January 2007 09:08, Steve Harris wrote:

> Ah, well the host is not supposed to change port values during run()
> anyway, the idea in LADSPA (and LV2) is that the host should chop the
> run() block where port values change. In practice not all hosts do
> that, some just pick a suitably small block size, eg. 32 frames and
> quantise the changes to that rate.

Hi, let me chime in because it kidna fits into the subject.

I have defined two (very very simple LV2 extensions):

"The extension’s URI is
http://tapas.affenbande.org/lv2/ext/fixed-buffersize

All that a plugin needs to check is whether a host feature with this URI
exists and the data will be a uint32 containing the buffersize.

The host is only allowed to call the plugin’s run function with a buffersize
equal to the one specified by the host feature.
There’s a second extension:

http://tapas.affenbande.org/lv2/ext/power-of-two-buffersize

which is identical to above but with the additional requirement that the fixed
buffersize has to be a power of two."

I don't need to have the URI point to my site. If you want to integrate it
into the official LV2 standard i'd be more than happy..

For anyone who might ask: "why do we need this"? Well the answer is that some
algorithms (especially fft based) perform much better when the buffer size
is known (because they must operate with a fixed buffersize internally). With
anyone of these two extensions provided by the host, those plugins can avoid
additional delay from buffering, etc..

We discussed on #lad whether a guarantee that the framecount of subsequent run
() calls add up to a fixed buffersize is enough.. I wasn't sure about this.
But i think now, that it's not a good idea. Here's a good counterargument:
Imagine an fft based plugin that uses the host buffer size as internal fft
size. Then with this guarantee it would have to collect data until an fft
buffer is full. While waiting for this and processing subsequent these
smaller buffers, it will have to produce output, but it doesn't have the fft
result yet. Thus causing unavoidable delay (of one total buffersize)..

Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org