[LAD] LADSPA dilemma

[Tim Goetze]

Fellow LADSPA developers,

I've been investigating curious bug reports concerning the use of some 
of the CAPS plugins in Ardour.

Most notably, the Eq plugin, a 10-band graphic eq, very often consumes 
an inordinate amount of CPU cycles and more likely than not even 
produces a silent output signal (or even worse one containing only 
samples of inf value).

[I'm talking about Ardour/GTK 0.99.3 (built using 1.4.1 with libardour 
0.908.2 and GCC version 4.1.2 20061007 (prerelease) (Debian 4.1.1-16) 
and CAPS up to and including 0.3.0]

Even after eliminating each and every possible cause of denormal 
numbers in the Eq plugin, the problem persisted.  It turns out that it 
is quite simply caused by invalid control parameter values.  

In order to prevent zipper noise, the Eq unit (like most of the CAPS 
plugins) smoothens control parameter input.  This is done by sweeping 
internal parameters over the duration of an audio block in run() or 
run_adding().

In order to prevent an involuntary parameter sweep during the first 
call to the plugin's run() after it has been activate()d, the plugin 
has to evaluate the current set of control input parameters in 
activate().  To prevent problems with unconnected ports, in CAPS an 
unconnected port points to the lower bound of that port's range.  
Thus, if a host calls activate() before doing connect_port() on all 
control inputs, an involuntary parameter sweep is very likely, but at 
least it's not starting from garbage parameters.

Now, Ardour will first call connect_port() and then activate(), just 
as you'd expect from a well-mannered host (and as is recommended by 
ladspa.h).

However, when Ardour calls activate(), the control inputs point at 
uninitialized memory (ie. garbage data).  A plugin with 10 control 
inputs like Eq thus stands a fair chance of running into a value of 
nan or inf, causing all sorts of computational mayhem including the 
problems described above.

So what to do about this?  ladspa.h says nothing about the value of 
control inputs at plugin activation time.  What it does say is that 
plugins should be able to operate on invalid input data without a 
glitch, and I'm working on making CAPS resolve the issue gracefully.

But still, if control inputs are unconnected or point to a value out 
of bounds, nan or inf at activation time, a plugin cannot perform 
correct parameter smoothing.  Which would be a loss, no?

So, dear LADSPA host authors, estimated Ardour developers, I'd like to 
ask you to make sure your implementation provides plugins with valid 
and useful control input data at activation time, preferably the 
values intended to be used at run() time.

Cheers, Tim

PS: It'd be nice to see a recommendation to this effect in ladspa.h, 
too.