[LV2] Buffersize, Options and Externtion-Data

Robin Gareus robin at gareus.org
Fri Sep 11 10:05:59 PDT 2015

On 09/10/2015 03:50 AM, David Robillard wrote:
> That said, there is a case for this value being used for optimization,
> so here you go:
> http://lv2plug.in/git/cgit.cgi/lv2.git/commit/?id=930649e812dc1b03f21be5ef7f412d892d3add1b


To conclude this..

Plugins that previously expected maxBufferLength to be the "current", or
assumed that the "max" can change over the lifetime of a plugin instance
should be updated.

LV2-host authors, please update the host at your convenience if it
supports the buffersize extension.

In short:

 * [optionally] provide min/maxBufferLength to the Plugin as
instantiation option

 * [optionally] provide a opts:interface as extension_data, and set()
the buffersize whenever the block-size of the host changes.

 * if the plugin's run() function cannot cope with arbitrary
sample-counts, fail to instantiate if the host does not provide
min/maxBufferLength information.

 * if the run() function needs to know the current blocksize, implement
an option inteface. The host will call opts_iface->set() in
non-realtime context and block processing until the plugin returns.

Also check during instantiation if the host supports the extension and
fail to instantiate if the DSP depends on it (ideally the DSP
implementation won't need it, but that's a different story).


More information about the Devel mailing list