[LAD] LADSPA dilemma

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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Received on Fri Jun 15 12:15:01 2007