How to run basic tests via command line?

[binarykitchen]

Do you have any examples hand how to run tests via command line? Just the very simple ones.

So that I can verify if compilation was successful.

Thanks :)

[swh]

You just need a command line LADSPA host, I think the LADSPA SDK used to ship with one.

I can't remember the syntax I'm afraid.

[binarykitchen]

how then can you develop software when unable to run tests??

[maxim-belkin]

@swh: what files (libraries) should 100% be present upon installation of the SWH Plugins?

[swh]

I no long actively develop this software, when I did the tests we're extremely complex (and required listening), so were never checked into the public repo, I have no idea what happened to them. They're probably lost.

[swh]

@maxim-belkin sorry, no idea, but the auto* stuff should tell you that, no?

[plater]

ladspa_sdk builds 3 binaries, analyseplugin, listplugins and applyplugin. I've never used applyplugin but analyseplugin is a good way of picking up errors.

[tresf]

This utility (ecasound) claims to support what is being requested, something such as a command line method for LADSPA effect testing. It appears from the documentation that this too requires the LADSPA SDK to be installed and available.

https://ecasound.seul.org/ecasound/Documentation/examples.html#effects

[plater]

Any package that builds against ladspa requires the libs and headers ladspa is built from the sdk tarball simply install the devel package. ecasound is available in most distributions. In openSUSE you get it from Packman, don't know why, maybe a license issue.

[tresf]

@plater thanks for the information.

In regards to the OP's request, I would like to fulfill this request for unit testing capabilities. My first step is to generate a LADSPA effect-modified sound. Here is my progress so far, Ubuntu 14.04.

1. Compile swh from source and install it to a temporary directory.

2. Export the LADSPA_PATH variable to force ecasound to look there instead of the standard search location.

   # make install --prefix=$HOME/ladspa
   export LADSPA_PATH=$HOME/ladspa/lib/ladspa

3. Install ecasound and ladspa sdk

   sudo apt-get install ecasound ladspa-sdk

4. Using a known .wav file, pass it through ecasound using the specified LADSPA name or ID

   # by name (-el:<name>)
   ecasound -i:/usr/share/sounds/alsa/Noise.wav -o:$HOME/Desktop/Noise-imp.wav -el:imp,1 
   
   # by id (-eli:<id>)
   ecasound -i:/usr/share/sounds/alsa/Noise.wav -o:$HOME/Desktop/Noise-1199.wav -eli:1199,1 

Where LADSPA_PATH is the location of the recently built LADSPA shared object files.

Finally, validate your output by hashing it. This hash value should remain the same for this effect with these parameters. A matrix of values to hashes can validate the plugins are working properly.

The hash is obtained using sha256sum Noise-imp.wav:

File Name	Hash
Noise.wav	0d897df[...]
Noise-imp.wav	9a08431[...]

[plater]

Running ladspa's listplugins I see "Warning: You do not have a LADSPA_PATH environment variable set". Try setting this to the plugins installation path. In openSUSE x86_64 this is /usr/lib64/ladspa. This can't be set on installation because it is a per user path. Looking at rosegarden and likely other apps that use ladspa I see that it does a path search if LADSPA_PATH isn't set. This can easily be patched in ladspa_sdk/src/search.c to look in common paths.

[tresf]

@plater perfect, that did the trick.

# make install --prefix=$HOME/ladspa
export LADSPA_PATH=$HOME/ladspa/lib/ladspa

ecasound -i:/usr/share/sounds/alsa/Noise.wav -o:$HOME/Desktop/Noise-imp.wav -el:imp,1

sha256sum /usr/share/sounds/alsa/Noise.wav
sha256sum $HOME/Desktop/Noise-imp.wav

File Name	Hash
Noise.wav	0d897df
Noise-imp.wav	9a08431

In this case, the hash differences are proof that the file contents are different. The hash of the modified sound should always remain the same so long as the same input parameters are given to the same plugin.

This should qualify as a basic LADSPA unit test.

[swh]

When I started working on these plugins 20(!) years ago I had a test suite of sorts, but I don't think I ever checked it in anywhere. I probably still have the source in a backup somewhere, but it was focussed more on checking for leaks and correctness to the spec that audio processing. E.g. making sure they didn't emit denormals under stress, and that they behaved themselves with different buffer sizes.

N.B. several plugins are non-deterministic, so hashing the output won't work in all cases.

If I ever have a day free I might write a test system, though I've not written any C for 5 or 6 years, so I'm a bit rusty.

[swh]

If instead of binary hashing the PCM signal there was a LSH of the FFT spectrum, that might work better for plugins that inject noise into the signal.

[tresf]

E.g. making sure they didn't emit denormals under stress, and that they behaved themselves with different buffer sizes.

Although not proper unit tests, (and no fuzzing)... downstream we're working to capture these denormals as well. https://github.com/LMMS/lmms/pull/3687

Which has helped us discover these (PR coming soon).

N.B. several plugins are non-deterministic, so hashing the output won't work in all cases.

If instead of binary hashing the PCM signal there was a LSH of the FFT spectrum, that might work better for plugins that inject noise into the signal.

👍

[swh]

Nice one :+1:

[tresf]

A recommended tool from @softrabbit: https://github.com/cth103/plugin-torture

[swh]

Perfect!