Bug#760758: amb-plugins: spurious LADSPA_PROPERTY_REALTIME

[Frank Heckenbach]

Fons Adriaensen wrote:

> On Thu, Oct 16, 2014 at 08:00:15AM +0200, Frank Heckenbach wrote:
>  
> > > > The same seems to apply to vco-plugins, mcp-plugins and rev-plugins.
> > > > Should I submit separate bug reports for each package?
> 
> See ladspa.h:
> 
> /* Property LADSPA_PROPERTY_REALTIME indicates that the plugin has a
>    real-time dependency (e.g. listens to a MIDI device) and so its
>    output must not be cached or subject to significant latency. */
> #define LADSPA_PROPERTY_REALTIME        0x1
> 
> So by removing this property you indicate that the plugin's output
> may be cached or subject to significant latency. There will be
> very few audio processing plugins for which this is true. The only
> ones I could imagine would be those that only produce metering or
> statistics and no audio output at all.
>
> For all of the plugins I ever wrote the user would expect a prompt
> response to control inputs and these may be bound to MIDI controllers
> by the host as well. There is never any reason to add latency or
> cache the output (whatever that would mean for an audio stream).

As I said, it's a bit confusing, since two rather different
properties include the word "realtime", and confusion about what the
plugin itself may do vs. what the user of the plugin (the host) may
do (and the use of the passive voice in the comments doesn't help to
clear the confusion ...)

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. The given
example is a MIDI device, and the restriction here is that when the
player presses say a key on a MIDI keyboard, they expect to hear the
corresponding sound promptly. So the *host* may not significantly
delay the processing, nor cache the output and play it back at a
later time. Whereas for a normal processing plugin, it may do the
processing any time it likes (if no other module in the chain has a
realtime dependency) and it may even cache the result, e.g. to
precompute a series of effects and play back the result at various
times. So this property adds restrictions to the host, and removing
it gives the host more freedom.

OTOH, LADSPA_PROPERTY_HARD_RT_CAPABLE (which you've set correctly)
indicates (among other things) that the plugin will not block and
"will take a [linear] amount of time to execute a run() or
run_adding() call". That means the host can use them in realtime
environments (e.g. JACK callbacks) that must not block and must
finish within the cycle. That's the case for most processing plugins
(unless they need a very variable processing time which cannot be
bound linearly). It would not be the case for a plugin that e.g.
needs to read data from files during run() (because reading might
block) or for I/O plugins unless they use non-blocking I/O or
similar (which they should generally do). So adding the property
gives more guarantees (and therefore more freedom) to the host.

So the upshot is that almost all pure processing plugins should set
LADSPA_PROPERTY_HARD_RT_CAPABLE, but not LADSPA_PROPERTY_REALTIME,
and indeed that's what I see is done in most plugin libraries.

Frank