[LAD] Plugin buffer size restrictions
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.
More information about the Linux-audio-dev