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

Florian Schmidt mista.tapas at gmx.net
Mon Jan 29 16:51:32 UTC 2007

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

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:


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)..


Palimm Palimm!

More information about the Linux-audio-dev mailing list