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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
