[Ardour-Users] High number of crashes

Robin Gareus robin at gareus.org
Mon Aug 24 21:34:22 PDT 2015

On 08/25/2015 05:03 AM, jonetsu at teksavvy.com wrote:
> (This time around with actual contents !)
> On Mon, 24 Aug 2015 22:48:25 -0400
> Paul Davis <paul at linuxaudiosystems.com> wrote:
>> Speaking frankly, as a host developer, the entire concept of plugins
>> is really a very disturbing one. Loading arbitrary random bits of
>> executable code into a large, complex program as part of an extension
>> mechanism is an idea that only the proprietary software development
>> world could dream up.
>> It is a necessary evil that we live with, but users need to be clear
>> that the basic idea is really totally broken. In a better world, all
>> plugin source code would be accessible and inspectable, just as the
>> code for ardour (and qtractor, and non) is
> But it is.  At least the plug/ins I use, Calf and more recently Gx.  It
> might sound corny, but a plug-in standard with elaborated tests that
> have to be passed to get certified would be an incentive to have better
> code.  It would at least assure that the plug-ins have passed extensive
> tests. 

It's not only the plugin code. As the fftw issues shows, simply
compiling it with a different set of of libs or different link-flags may
already be enough to produce issues. Bugs may creep in when adding new
features so you'll need to re-evaluate new versions...

falktx has recently promoted himself to LV2 high-inquisitor :) He
tracked down a lot of issues in .ttl descriptions of various LV2 plugins
in the past weeks (and notified upstream).
LV2 itself also comes with with a tool to validate the plugin
description [0]. Still, the number of times I've seen "failed to expand
CURIE" messages is appalling. If one extrapolates that sloppiness to the
DSP code, it's scary.

jack-demolition [1] is another great tool.
As is running plugins under valgrind in jalv (using jackd -d dummy;
jack_freewheel y).

Then there is stoat [2] - a static analyser for realtime safety - and
jack-interposer [3] for runtime RT-safety checks.

Looking at the output of a plugin with a scope is also invaluable,
particularly when automating parameters, but that's rather for assuring
DSP quality not stability in general.

Those tools can help a great deal., but they're just tools and need to
be operated and the output interpreted.
Proper QA takes time, usually more than actually designing the DSP and
writing the plugin. It ought to be done by the plugin developer-team in
cooperation with dedicated beta-testers.

One way for developers to "bless" LV2 plugins after testing them is to
given them an even http://lv2plug.in/ns/lv2core/#minorVersion
Sadly almost no LV2 Host follows the guideline to indicate "developer"

> This would mean a testing framework that factors in real-time
> concerns and perhaps imposing another mode of operation for the
> plug-ins, a testing mode, in which real-time concerns are not
> important.  So that data access et al. can be thoroughly tested.

The problems here: user-interaction, GUI interaction, parameters
parameter-automation,... complexity that comes into play when multiple
instances of the same plugin are used in the same host (shared mem)...
then factor in in various distros (different compilers, libs).

I don't think there's a realistic way of [semi]-automatic evaluation.

One good example is AVLinux, Glen is actually using it for real-studio
work and thereby testing common workflows before release. It may not be
"bug free" but it's very robust for real-world use cases which is what
matters most.


[0] http://lv2plug.in/pages/validating-lv2-data.html
[1] http://plugin.org.uk/releases/jack-demolition/
[2] https://github.com/fundamental/stoat
[3] https://github.com/raboof/jack_interposer

More information about the Ardour-Users mailing list