[LV2] Buffersize, Options and Externtion-Data

David Robillard d at drobilla.net
Wed Sep 9 18:50:01 PDT 2015

On Thu, 2015-09-10 at 00:05 +0200, Robin Gareus wrote:
> On 09/09/2015 11:21 PM, hermann meyer wrote:
> > 
> > Am 09.09.2015 23:15, schrieb David Robillard:
> >> 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.
> >
> > Exactly what I said on IRC, what is it worth to provide this value other
> > then waste resources?
>   8 K/channel * 4 bytes/sample  = 32 KB/channel
> really? if you call this a waste, you save on the wrong end.
> Plugins that require to pre-allocate data are usually samplers,
> reverbs/delays or IR reverbs. Now put this in prespective to a 50MB IR,
> or 2+ GB of samples in RAM, not to mention a few MB of plugin GUIs.
> Anyway, being able to seamlessly play without dropout whenever the
> buffersize changes is well worth 32KB (or more). Taking down a plugin
> instance just to re-allocate a couple of KB is IMHO wrong.
> pre-allocate and run() with whatever buffer-size (as long as it's below
> the max given during instantiation) without interruptions even when the
> size changes.

This is true.  Frankly, the memory doesn't matter much in almost all
cases, and in cases where it does, the host should not pass a large
maximum.  This is a host decision and plugins should just do what they
are told.  Plugins not allocating large enough buffers for the maximum
cycle size => plugins that drop out => crap plugins.

Anyway, this tangent of the discussion just obscures the fact that the
plugin is going to end up allocating that memory at some point once the
host does call run() with a larger-than-"nominal" cycle size, which it
will, because otherwise the maximum would not need to be larger in the
first place.  You gain a dropout and save precisely zero resources.

You "save resources" in the same say you would by allocating a 1 sample
buffer, then immediately dropping out and reallocating everything and
eventually resuming processing when run(1024) is called.  Which is to
say, you saved nothing, but you did cause a big drop-out and screw up
the user's audio for no good reason.

That said, there is a case for this value being used for optimization,
so here you go:


I already know this is going to be abused to do stupid things, but oh
well.  For the record, using this for buffer allocation is definitely
the wrong thing to do, and if you don't like the maximum value given by
some host, take it up with that host.


More information about the Devel mailing list