Measure and correct plugin delay

Getting Stuff Done How do I .... ?
#1

Hello,

I’d relly like to correct the delay that some plugins generate (some EQs and Lookahead-Compressors p.E.). It would be nice if Ardour could send a dummy sine-signal and measure the time difference until it has passed all plugins.

Than every bus would get assigned a delta time so that all Tracks are played in time.

Is that possible with Ardour? Or do I have to correct that with my own ears and (mouse) klicks?

mfg

  • eth
#2

It would probably be ideal if the dealy of a plugin was determined as part of the build process for LADSPA plugins and then setting that delay as what the plugin reports. (i.e. make this delay testing at build time part of the LADSPA standard)

If I understand correctly, right now the delays reported are optional and they are set according to what the developer determins the delay time will be. However, I’m not sure what good that does, because different build options used when building plugins and their dependencies can drastically effect the delay. (e.g. -ffast-math)

#3

Would it be feasible to create an application that could load and test the runtime performance of plugins in the environment that they run in, then add a tag to the rdf file? Or would information derived this way not be useful at all to Ardour because of the complex arrangements mentioned above?

#4

Sorry but no, and no.

First of all, you can’t determine the latency of a plugin at compile time: the latency caused by the plugin depends on many runtime variables. Most notably the sample rate and input paramters.

Second, you can’t reliable calculate the latency of a plugin with a tester. What would be the latency of a delay plugin?

I’m sorry folks, but the only and by far easiest way for a plugin to report it’s latency automatically is that the author of the plugin (or do it yourself, this is open source!) writes the “latency” port and the relevant code which outputs either the static latency caused by the plugin or writes the algorithm which returns the latency of the DSP in the plugin.

And please remember the artificial latency plugin. It’s really easy to dial in the correct amount of latency compensation using it.

#5

Here’s a not-very-elegant script fumbled together to list all plugins sorted by whether they provide latency info or not. It was a little less simple than I anticipated; something nicer could probably be made in python, but my skills are meager, and I’d have to refer to a lot of documentation. :wink:

I was surprised at the final tally - I thought more plugins were using the latency reporting. Does this means that adding any of the other ones basically un-syncs the track you pile them up on?

#!/bin/bash

reports latency control status of LADSPA plugins.

whitelist=“These plugins report latency:”
blacklist=“These plugins DO NOT report latency:”

for objectfile in listplugins | grep -o '^\/.*\.so'
do
family=analyseplugin -l $objectfile | grep -o '^\w*\>'
for plugin in $family
do
info=analyseplugin $objectfile $plugin
prettyname=analyseplugin -l $objectfile $plugin
has_latency=echo $info | grep '"latency" output, control'
if [ “$has_latency” ]
then whitelist=printf "%s\n\t%s" "$whitelist" "$prettyname"
else blacklist=printf "%s\n\t%s" "$blacklist" "$prettyname"
fi
done
done

echo “$whitelist”
echo
echo “-------------”
echo
echo “$blacklist”

#6

Just a reminder: Not all plugins cause latency. Thus a blacklist automatically generated like that will have falsely blacklisted ones.

#7
Just a reminder: Not all plugins cause latency. Thus a blacklist automatically generated like that will have falsely blacklisted ones.
I only used those terms for fun, in reference to the discussion, not really advocating a real blacklist of all those plugins. The information is interesting, though, and which plugins will cause latency is something I'm trying to get a feel for, being kind of new to this way of doing things. So back to the original poster's question, is there an easier way to get a sense of what's going on short of intense scrutiny?

/me goes searching documentations…

#8

Ardour already compensates for those delays. You sine wave meathod wouldn’t be very useful anyways because plugins aren’t necessarily always linked together in a linear fashion in Ardour. There can be branching and foldback loops, which make it much much more complex to correctly compensate for the delays than just timing the delay of a pulse.

#9

Are you saying that Ardour automatically compensates for this or is there a setting that has to be adjusted?

#10

It automatically compensates. This does not apply though if you are trying to use VST plugins. VST plugins (to my knowlege) offer no means of reporting back their internal delay times.

#11

Reuben, the problem is: many plugins do not report latency. I’ve long advocated a whitelist, of plugins that do in fact report delay times. I wouldn’t know how to do it myself, though…

#12

It’s pretty easy to see whether a ladspa plugin reports latency or not. Use the command line tool “analyseplugin” on the plugins’ .so file (which you can locate via another command line tool “listplugins”). See if the plugin has a control output port called “latency”. If it has, it reports latency.

Example

$ analyseplugin /usr/lib/ladspa/latency_1914.so

Plugin Name: “Artificial latency”
Plugin Label: “artificialLatency”
Plugin Unique ID: 1914
Maker: “Steve Harris steve@plugin.org.uk”
Copyright: “GPL”
Must Run Real-Time: No
Has activate() Function: No
Has deativate() Function: No
Has run_adding() Function: Yes
Environment: Normal or Hard Real-Time
Ports: “Delay (ms)” input, control, 0 to 10000, default 2500
“Input” input, audio
“Output” output, audio
“latency” output, control

(we can’t be sure that the plugins reports the correct latency, though. :wink: )