[LAD] Plugin buffer size restrictions

Stefano D'Angelo zanga.mail at gmail.com
Sun May 27 20:16:59 UTC 2012


2012/5/27 David Robillard <d at drobilla.net>:
> On Sun, 2012-05-27 at 21:59 +0300, Stefano D'Angelo wrote:
> [...]
>> In practical terms, especially w.r.t. LV2, there may be a third way:
>> let the host pass a limited number of future parameter samples at each
>> run() (could be negotiated at instantiation time), so that the plugin
>> doesn't have to add latency to the audio streams in any case. Would be
>> only supported by "offline hosts". If the block sizes are variable,
>> future block sizes should be passed as well (argh?). But I don't know
>> if this really makes sense or has downsides... ideas, folks?
>
> Or just send time-stamped ramped controls (value now is 1.2, value at
> some point in the future past this block is 3.9, and so on).  This could
> be done even online in the case of automated parameters, though of
> course not things being actively twiddled by the user live.
>
> I suppose the host could just indicate whether it can send future
> control values, so plugins that interpolate can avoid adding control
> latency when they don't need to.  This maps nicely to a feature, though
> it'd be a questionable decision to require it and make a plugin that
> doesn't work at all without receiving parameters from the future, since
> it'd be impossible to use live.  One could argue the host always has to
> do the latency part if necessary, I guess.
>
> In terms of API, these can thankfully be tacked completely independently
> (even though they impact each other in terms of what plugins actually do
> with them).  Block size restriction stuff is one thing, a way of getting
> more expressive control values into a plugin is another.  The former is
> easier and more pressing.

Sure, it's all sound and nice. I was only wondering whether there is a
smarter way to do things.

Stefano



More information about the Linux-audio-dev mailing list