[LV2] Buffersize, Options and Externtion-Data

[David Robillard]

On Wed, 2015-09-09 at 21:00 +0200, Robin Gareus wrote:
> Hi Filipe, LV2ers,
> 
> (cutting some parts here, please see the original email for references)
> 
> Executive summary: There are two separate issues here:
> 
> 1) Semantics of "maxBuffersize"
> 
>  Is bufsz:maxBlockLength an "all time max" while the plugin is
>  instantiated?
> 
>  Proposed answer is "yes" and we need a new "bufsz:nominalBlockLength"
>  which can change dynamically.
> 
> 
> 2) Options API clarification:
> 
>  Is there a difference if the Option is passed during instantiate vs
>  Pption is passed as extension-data.
> 
> Robin says "yes", during instantiation it's const data.
> Filipe says "no" both are identical.
> 
> If Filipe is right, Robin wants to know why there are two APIs to do the
> same :)

The *mechanisms* are static and dynamic, respectively.  The definition
of a property is the definition of a property and is (in general)
independent of mechanism.

The definition of maxBlockLength is the maximum value that will be
passed to run().

> Since Carla reports the current jack-period as "max", a plugin that uses
> this "max" during *instantiation* to pre-allocate buffers will crash, if
> the buffersize is later increased (jack_bufsize).

It is a host bug to call run() with a larger value than maxBlockLength.

> Plugins that pre-alloccate buffers are a lot more common than plugins
> that need to know the expected "current" (temporary-maximum until
> further notice) buffersize for optimization.
> 
> Hence requiring all plugins to implement dynamic buffer-size changes
> (re-allocate on demand, any time) is the wrong approach.

I agree this is way more trouble than it is worth, and the buf-size
extension should just say it's not expected to be supported.

To not disallow it outright the options interface either needs metadata
to specify what may be changed (annoying), or a return value that
refuses the change (easy).  That should happen, but I don't think in
practice making plugins deal with dynamic change is all that worth it,
since this is usually a "stop the audio world" situation anyway and the
host might as well just reinstantiate the plugin which will works with
all plugins.

> Not usually, but Ardour may indeed do so. Plugin analysis (spectrum
> display) is done on rt-data in larger chunks.

I'm forced to wonder if the efficiency gains of this are really worth
it...

> > PS: Anyone got a suggestion for a "engine realtime maximum" property name?
> 
> see above. I propose: "nominalBlockLength"

I am not a fan of adding weird crap to the spec because ardour uses a
fixed maximum because of analysis.  Plugins will all be allocating 8192
buffers regardless of block size.  Maybe we don't care about memory all
that much these days, but.... ugh.

Yes, okay, I guess some kind of "most typical" block size is at least
kind of reasonable, and adding properties is not a big deal in general,
but this is of very limited use and is surely going to confuse people
even more than it already has.

-- 
dr