Bug#760758: amb-plugins: spurious LADSPA_PROPERTY_REALTIME

[Frank Heckenbach]

Fons Adriaensen wrote:

> On Sun, Oct 19, 2014 at 11:50:05AM +0200, Frank Heckenbach wrote:
>  
> > LADSPA_PROPERTY_REALTIME indicates that the plugin itself *has* a
> > realtime dependency. That would be the case only for few plugins,
> > not really audio processing plugins, more plugins for I/O.
> 
> We clearly disagree on the interpretation of PROPERY_REALTIME.

Indeed. Maybe we should ask Richard Furse, the author of the LADSPA
specification for clarification.

Then again, you might consider that his own example plugins which
can be found in http://www.ladspa.org/download/ladspa_sdk.tgz all
set LADSPA_PROPERTY_HARD_RT_CAPABLE, but not
LADSPA_PROPERTY_REALTIME, and they're all pure audio processing (and
in one case (sine), an audio generating) plugins.

> For all of my plugins the following is true: if their output
> is cached, or subject to significant latency, they will not
> produce the expected result. Hence this must not be done, 
> and setting the property is required to restrict the host.

Here's an example (not hypothetical, that's almost exactly what my
software will do in some cases): Read an audio file, apply various
effects and write the result to another audio file. For various
reasons, in some cases I don't want to write the output as I go, but
collect the data in memory and write the file at the end. So the
output is cached and subject to possibly significant (if the files
are large) latency. By this logic, it couldn't use any of your
plugins, although looking at what they actually do, there's no
reason they wouldn't work.

> If a user expects to hear a note played on a MIDI keyboard
> without delay, then this requires the entire processing 
> chain to do the right thing, not just the part that is 
> talking directly to the MIDI device. All plugins in such
> a chain have the same real-time dependency.

I disagree. The chain as a whole has a realtime dependency, but this
doesn't mean each of its members has the dependency. As the saying
goes, a chain is as strong as its weakest link, and in this case the
weakest link (WRT realtime dependencies) is the MIDI interface
(whether that's in another plugin or done by the host itself), not
the processing plugins.

Note that the comment says (emphasis mine): "Property
LADSPA_PROPERTY_REALTIME indicates that *the plugin* has a real-time
dependency (e.g. *listens* to a MIDI device) ...". That's not the
case in your example: The plugin doesn't listen to the MIDI
keyboard, it's the host (or another plugin) that does.

> This is most
> obvious  for plugins that implement a synthesiser module,
> e.g. a VCF, but in fact valid for almost all.

In fact in another application I use VCFs which are controlled by
data computed from a function. No realtime dependency here: If I
repeatedly want to apply the same function values, I can just as
well cache the VCF output.

> Exception
> would be plugin that implements e.g. a VU-meter or spectrum
> analyser - it doesn't matter much if the result is displayed
> with some delay (as long as that remains reasonable).

As you say yourself, "as long as that remains reasonable". But the
comment specifically talks about *significant* (i.e. non-reasonable
in your terms) latency. So under your interpretation even these
plugins would need to set the property. And if basically every
plugin needs to set it, the property becomes meaningless.

> Another interpretation, closer to yours, would be that if
> the plugin has REALTIME_PROPERTY set it can not be used in
> any form of batch (non-real-time) processing. But that is
> not what the text in ladspa.h says.

It doesn't mention batch processing explicitly, but "significant
latency", and batch processing generally involves significant
latency.

Frank