[LV2] Buffersize, Options and Externtion-Data

[David Robillard]

On Thu, 2015-09-10 at 00:43 +0200, Filipe Coelho wrote:
> On 10-09-2015 00:05, 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.
> Let's take a worst-case, sorta real scenario.
> 
> Ardour session with 200 plugins.
> JACK running at 128 buffer size.
> 
> Not all plugins will do allocations, but for the worst-case scenario 
> let's assume they do.
> Also let's assume all plugins are stereo, cause why not.
> 
> That makes 4 bytes/sample * 2 channels * (8192 - 128 samples) * 200 plugins.
> I'm decreasing 128 samples because those actual save useful info.
> 
> That gives a value of 6515712 bytes, which is ~12Mb.
> Which is not much, but all that memory is going to be fragmented.
> The memory copying will likely increase too.

I do not think this situation is very good, either... but plugins should
do what they are told and be prepared for cycles up to whatever maximum
size the host specifies.  Using an overly large static value that may
not be needed is indeed wasteful, but that is the host's decision, and
the host's problem.  The spec can't very well add a "kinda sorta maximum
sometimes but not really" property, because that doesn't even mean
anything.

> There's only 2 things I hope we get with this:
> 
> 1. make the min/max block length documentation state that those values 
> are static for the lifetime of a plugin instance

It's kind of clumsy to bake this into the definition of the properties
themselves, though that was always the intent.  IIRC these properties
predate the dynamic options interface existing at all.

Really, though, the dynamic options interface needs a way to refuse a
change in general.

> 2. add a new property that gets the value we've been discussing here and 
> IRC.
> 
> I don't think it's too much to ask, or is it?

I don't think asking plugins to do what they're told and not cause
dropouts for no good reason is too much to ask.  I certainly don't think
session exports not having big gaps of silence is too much to ask!  I
can't even think of anything that is more reasonable to ask than that,
but gaps in output is precisely what will happen if you use this value
for buffer allocation.

Plugins that drop out because of a block size came along they had the
information to be prepared for are broken amateur nonsense and frankly
I'd like to keep a higher standard around here for things that are so
critically important to users.  Unnecessary dropouts are not okay.
Seriously.

-- 
dr