[LAD] Test app for LADSPA plugins
Hi,
I've been having problems with a few LADSPA plugins recently, so I've
written a little test app that loads all LADSPA plugins, connects the
ports and runs them for one cycle. (I've attached it here.)
I've run it on the plugin packages I have installed, using valgrind, and
the results are:
amb crashes
blopmemory errors (patches sent for some of the errors)
calfmemory errors in Flanger & MultiChorus plugins
capsmemory errors in 3 plugins
cmt memory errors (patches sent)
fil OK
ladspa memory errors in Sine plugin (mismatched free/deletes)
mcp OK
rev OK
swh crashes
tap memory errors in 5 plugins
vco OK
Note that not all memory errors are bugs, but most are. (There's also a
chance that my test app is buggy, rather than the plugins.)
I've sent a few patches for cmt and blop, and will probably try to track
down the bugs in a few other packages. If others want to help
(especially the owners of the above packages!) that would be good.
Damon
/*
* Test app to load & run all LADSPA plugins for one cycle.
*
* Compile with:
* gcc `pkg-config --cflags --libs gmodule-2.0` -lm -o test-ladspa test-ladspa.c
*
* Simply run it with './test-ladspa' to test all plugins.
* Run it with './test-ladspa -p PACKAGE' to test a particular package.
* (Run ./test-ladspa --help to see the list of known packages.)
*
* Run it with 'valgrind --tool=memcheck ./test-ladspa' to spot memory errors.
*/
#include
#include
#include
#include
#include
/* The default places to look for LADSPA plugins, if LADSPA_PATH isn't set. */
#define DEFAULT_LADSPA_PATH "/usr/lib/ladspa:/usr/local/lib/ladspa"
/* The sample rate to pass to the plugins. We don't output audio so it's not
too important. */
#define SAMPLE_RATE 48000
/* The number of samples to use for the run. Again, not too important. */
#define NUM_SAMPLES 256
static char *package = NULL;
static char **file_list = NULL;
/* These are the lists of files containing the plugins in the various
packages. I got most of these using 'rpm -ql '. There may be
more packages around that I haven't got installed at present. */
static char *amb_file_list[] = { "ambisonic1.so", "ambisonic2.so", NULL };
static char *blop_file_list[] = {
"adsr_1653.so", "adsr_1680.so", "amp_1654.so", "branch_1673.so",
"dahdsr_2021.so", "difference_2030.so", "fmod_1656.so",
"interpolator_1660.so", "lp4pole_1671.so", "parabola_1649_data.so",
"product_1668.so", "pulse_1645.so", "quantiser100_2029.so",
"quantiser20_2027.so", "quantiser50_2028.so", "random_1661.so",
"ratio_2034.so", "sawtooth_1641_data.so", "sawtooth_1641.so",
"sequencer16_1677.so", "sequencer32_1676.so", "sequencer64_1675.so",
"square_1643_data.so", "square_1643.so", "sum_1665.so",
"sync_pulse_2023.so", "sync_square_1678.so", "tracker_2025.so",
"triangle_1649.so",
NULL
};
static char *calf_file_list[] = { "calf.so", NULL };
static char *caps_file_list[] = { "caps.so", NULL };
static char *cmt_file_list[] = { "cmt.so", NULL };
static char *fil_file_list[] = { "filters.so", NULL };
static char *ladspa_file_list[] = { "amp.so", "delay.so", "filter.so",
"noise.so", "sine.so", NULL };
static char *mcp_file_list[] = { "cs_chorus.so", "cs_phaser.so",
"mvchpf24.so", "mvclpf24.so", NULL };
static char *rev_file_list[] = { "g2reverb.so", NULL };
static char *swh_file_list[] = {
"alias_1407.so", "allpass_1895.so", "am_pitchshift_1433.so", "amp_1181.so",
"analogue_osc_1416.so", "bandpass_a_iir_1893.so", "bandpass_iir_1892.so",
"bode_shifter_1431.so", "bode_shifter_cv_1432.so", "butterworth_1902.so",
"chebstortion_1430.so", "comb_1190.so", "comb_1887.so",
"comb_splitter_1411.so", "const_1909.so", "crossover_dist_1404.so",
"dc_remove_1207.so", "decay_1886.so", "decimator_1202.so", "declip_1195.so",
"delay_1898.so", "delayorama_1402.so", "diode_1185.so", "divider_1186.so",
"dj_eq_1901.so", "dj_flanger_1438.so", "dyson_compress_1403.so",
"fad_delay_1192.so", "fast_lookahead_limiter_1913.so", "flanger_1191.so",
"fm_osc_1415.so", "foldover_1213.so", "foverdrive_1196.so",
"freq_tracker_1418.so", "gate_1410.so", "giant_flange_1437.so",
"gong_1424.so", "gong_beater_1439.so", "gsm_1215.so", "gverb_1216.so",
"hard_limiter_1413.so", "harmonic_gen_1220.so", "hermes_filter_1200.so",
"highpass_iir_1890.so", "hilbert_1440.so", "imp_1199.so", "impulse_1885.so",
"inv_1429.so", "karaoke_1409.so", "latency_1914.so", "lcr_delay_1436.so",
"lowpass_iir_1891.so", "ls_filter_1908.so", "matrix_ms_st_1421.so",
"matrix_spatialiser_1422.so", "matrix_st_ms_1420.so", "mbeq_1197.so",
"mod_delay_1419.so", "multivoice_chorus_1201.so", "notch_iir_1894.so",
"phasers_1217.so", "pitch_scale_1193.so", "pitch_scale_1194.so",
"plate_1423.so", "pointer_cast_1910.so", "rate_shifter_1417.so",
"retro_flange_1208.so", "revdelay_1605.so", "ringmod_1188.so",
"satan_maximiser_1408.so", "sc1_1425.so", "sc2_1426.so", "sc3_1427.so",
"sc4_1882.so", "sc
Re: [LAD] Test app for LADSPA plugins
[Damon Chaplin] >I've been having problems with a few LADSPA plugins recently, so I've >written a little test app that loads all LADSPA plugins, connects the >ports and runs them for one cycle. (I've attached it here.) If you're using libraries like glib, it would be very kind of you to supply a proper makefile or gcc invocation. Thanks, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, Jul 28, 2009 at 02:06:33PM +0200, Tim Goetze wrote: > >I've been having problems with a few LADSPA plugins recently, so I've > >written a little test app that loads all LADSPA plugins, connects the > >ports and runs them for one cycle. (I've attached it here.) > If you're using libraries like glib, it would be very kind of you to > supply a proper makefile or gcc invocation. See line 5 in test-ladspa.c, it's probably all you need. HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
[Damon Chaplin] >caps memory errors in 3 plugins Thanks for pointing out the make invocation. I haven't used valgrind before so my cluelessness may show again in what follows. Anyway, when running this: $ valgrind --tool=memcheck --leak-check=full --show-reachable=yes ./test-ladspa -p caps I see this in the final summary: ==12021== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 33 from 2) followed by a lot of what I suppose are call traces - are they? If they are, they all involving the g_malloc interface. However, this interface isn't used by caps at all. I do see valgrind complaining about the use of an unitialised variable in some of the plugins (not entirely impossible), but given the memory leak summary I fail to see which plugins if any are affected. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-07-28 at 14:44 +0200, Tim Goetze wrote: > [Damon Chaplin] > >caps memory errors in 3 plugins > > Thanks for pointing out the make invocation. I haven't used valgrind > before so my cluelessness may show again in what follows. > > Anyway, when running this: > > $ valgrind --tool=memcheck --leak-check=full --show-reachable=yes > ./test-ladspa -p caps > > I see this in the final summary: > > ==12021== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 33 from > 2) > > followed by a lot of what I suppose are call traces - are they? > > If they are, they all involving the g_malloc interface. However, this > interface isn't used by caps at all. > > I do see valgrind complaining about the use of an unitialised variable > in some of the plugins (not entirely impossible), but given the memory > leak summary I fail to see which plugins if any are affected. Yes, using uninitialized values is the only problem in CAPS. Not as bad as invalid writes or reads, but often still a bug: Testing 2589: C* ToneStack - Tone stack emulation (caps.so) ==9992== Conditional jump or move depends on uninitialised value(s) ==9992==at 0x4129F9F: DSP::ToneStack::start_cycle(float**, int) (ToneStack.h:103) ==9992==by 0x414432D: void ToneStack::one_cycle<&(store_func(float*, int, float, float))>(int) (ToneStack.cc:80) ==9992==by 0x41443BF: ToneStack::run(int) (ToneStack.h:56) >From looking at the source I'd guess that the "model" variable hasn't been initialised (in dsp/ToneStack.h:103). That may or not matter. Though it's best to initialise it just to avoid the warnings. Testing 2587: C* AmpV - Tube amp (caps.so) ==9992== ==9992== Conditional jump or move depends on uninitialised value(s) ==9992==at 0x412BA10: void AmpV::one_cycle<&(store_func(float*, int, float, float)), 8>(int) (Amp.cc:349) ==9992==by 0x412BF13: AmpV::run(int) (Amp.h:317) Maybe "tone" hasn't been initialised here (Amp.cc:349). Again that might or might not matter. Testing 2592: C* AmpVTS - Tube amp + Tone stack (caps.so) ==9992== ==9992== Conditional jump or move depends on uninitialised value(s) ==9992==at 0x4129F9F: DSP::ToneStack::start_cycle(float**, int) (ToneStack.h:103) ==9992==by 0x412A622: void AmpVTS::one_cycle<&(store_func(float*, int, float, float)), 8>(int) (Amp.cc:508) ==9992==by 0x412AA0F: AmpVTS::run(int) (Amp.h:366) This seems to be the same as the first one. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-07-28 at 14:02 +0100, Damon Chaplin wrote: > Testing 2589: C* ToneStack - Tone stack emulation (caps.so) > ==9992== Conditional jump or move depends on uninitialised value(s) > ==9992==at 0x4129F9F: DSP::ToneStack::start_cycle(float**, int) > (ToneStack.h:103) > ==9992==by 0x414432D: void ToneStack::one_cycle<&(store_func(float*, > int, float, float))>(int) (ToneStack.cc:80) > ==9992==by 0x41443BF: ToneStack::run(int) (ToneStack.h:56) > > >From looking at the source I'd guess that the "model" variable hasn't > been initialised (in dsp/ToneStack.h:103). That may or not matter. > Though it's best to initialise it just to avoid the warnings. > > > Testing 2587: C* AmpV - Tube amp (caps.so) > ==9992== > ==9992== Conditional jump or move depends on uninitialised value(s) > ==9992==at 0x412BA10: void AmpV::one_cycle<&(store_func(float*, int, > float, float)), 8>(int) (Amp.cc:349) > ==9992==by 0x412BF13: AmpV::run(int) (Amp.h:317) > > Maybe "tone" hasn't been initialised here (Amp.cc:349). Again that might > or might not matter. I can confirm that initializing the "model" and "tone" variables does fix the problems in CAPS. Though I'm not sure what they should be initialized to, so I'll leave that to you! Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
[Damon Chaplin] >I can confirm that initializing the "model" and "tone" variables does >fix the problems in CAPS. Though I'm not sure what they should be >initialized to, so I'll leave that to you! Thanks, that is rather helpful, and the issue may have been the cause of real problems for some users. There are a few other issues with caps and more recent g++ versions that have been standing for too long now. Hope I can fix them in the near future and release a fixed version. Thanks again, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-07-28 at 12:39 +0100, Damon Chaplin wrote: > Hi, > > I've been having problems with a few LADSPA plugins recently, so I've > written a little test app that loads all LADSPA plugins, connects the > ports and runs them for one cycle. (I've attached it here.) > > I've run it on the plugin packages I have installed, using valgrind, and > the results are: > > amb crashes > blop memory errors (patches sent for some of the errors) > calf memory errors in Flanger & MultiChorus plugins > caps memory errors in 3 plugins > cmt memory errors (patches sent) > fil OK > ladspa memory errors in Sine plugin (mismatched free/deletes) > mcp OK > rev OK > swh crashes > tap memory errors in 5 plugins > vco OK I've just discovered that the crashes in the amb and swh packages are caused by activating certain plugins before connecting the ports (which I think is allowed by the LADSPA spec). If the ports are connected first, the amb package is OK, but the swh package has memory errors in 3 plugins. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
A quick update - fixes have been found for blop, caps & cmt, and the ladspa Sine plugin problem is fixed in the latest version. So the current status is: amb OK blopOK calfmemory errors in 2 plugins capsOK cmt OK fil OK ladspa OK mcp OK rev OK swh memory errors in 3 plugins tap memory errors in 5 plugins vco OK Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, Jul 28, 2009 at 11:54 AM, Damon Chaplin wrote: > > A quick update - fixes have been found for blop, caps & cmt, and the > ladspa Sine plugin problem is fixed in the latest version. Damon - fantastic work. really great stuff. I'd just like to remind LADSPA (and LV2) plugin authors that use of init() for module-level initialization has been deprecated for some time. Plugins should mark the module-level init function with __attribute__((constructor)) and the cleanup function formerly known as fini() as __attribute__((destructor)) failure to do this pretty much guarantees plugin crashes on OS X and other platforms that dropped init+fini support years ago. --p ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 28 Jul 2009 16:54:23 +0100 Damon Chaplin wrote: > > A quick update - fixes have been found for blop, caps & cmt, and the > ladspa Sine plugin problem is fixed in the latest version. > > So the current status is: > > amb OK > blop OK > calf memory errors in 2 plugins > caps OK > cmt OK > fil OK > ladspa OK > mcp OK > rev OK > swh memory errors in 3 plugins > tap memory errors in 5 plugins > vco OK > > > Damon Hi Damon, thanks for your efforts. How does your test compare to the ladspa demolition thing? Are you sure you use the latest version of each? Ultimately the authors should test themselves, but.. Some ladspas you missed: acweight autotalent invada-studio-plugins njl vcf Regards, Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, Jul 28, 2009 at 12:20:44PM -0400, Paul Davis wrote: > I'd just like to remind LADSPA (and LV2) plugin authors that use of > init() for module-level initialization has been deprecated for some > time. Plugins should mark the module-level init function with > >__attribute__((constructor)) > > and the cleanup function formerly known as fini() as > > __attribute__((destructor)) > > failure to do this pretty much guarantees plugin crashes on OS X and > other platforms that dropped init+fini support years ago. Or make sure you don't need any module level init(). At least for LADSPA, all required structs can easily be defined statically. It's done like that in all my plugins, none of them have an init() or equivalent. Regarding calling activate() before the port pointers are valid, it indeed seems like the LADSPA spec does allow this. The AMB set will be modified accordingly. Ciao, -- FA Io lo dico sempre: l'Italia è troppo stretta e lunga. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
[Paul Davis] [...] >and the cleanup function formerly known as fini() as > > __attribute__((destructor)) > >failure to do this pretty much guarantees plugin crashes on OS X and >other platforms that dropped init+fini support years ago. I've added these attributes to _init() and _fini() sometime ago but hopeful users of caps on OSX tell me linking the .so fails: $ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC -shared -o caps.so [list of object files] is answered with ld: could not find entry point "start" (perhaps missing crt1.o) Since you brought OSX up, I thought you might be able to tell me how to resolve this? Thanks, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, Jul 28, 2009 at 1:29 PM, Tim Goetze wrote: > [Paul Davis] > [...] >>and the cleanup function formerly known as fini() as >> >> __attribute__((destructor)) >> >>failure to do this pretty much guarantees plugin crashes on OS X and >>other platforms that dropped init+fini support years ago. > > I've added these attributes to _init() and _fini() sometime ago but > hopeful users of caps on OSX tell me linking the .so fails: > > $ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC > -shared -o caps.so [list of object files] why are you using -nostartfiles? i know what your intent is, but its unwise, i think. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
[Paul Davis] >> I've added these attributes to _init() and _fini() sometime ago but >> hopeful users of caps on OSX tell me linking the .so fails: >> >> $ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC >> -shared -o caps.so [list of object files] > >why are you using -nostartfiles? i know what your intent is, but its >unwise, i think. So will it link on OSX if I remove -nostartfiles? Thanks, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, Jul 28, 2009 at 1:36 PM, Tim Goetze wrote: > [Paul Davis] >>> I've added these attributes to _init() and _fini() sometime ago but >>> hopeful users of caps on OSX tell me linking the .so fails: >>> >>> $ g++ -nostartfiles -O2 -ffast-math -funroll-loops -Wall -fPIC -DPIC >>> -shared -o caps.so [list of object files] >> >>why are you using -nostartfiles? i know what your intent is, but its >>unwise, i think. > > So will it link on OSX if I remove -nostartfiles? i'd suggest copying what swh's makefile does, which is something like this: gcc -flat_namespace -undefined suppress -o .libs/ringmod_1188.so -bundle .libs/ringmod_1188.o -lm -march=i686 -nostartfiles clearly, i was talking out of my rear end about -nostartfiles ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
[Paul Davis] >> So will it link on OSX if I remove -nostartfiles? > >i'd suggest copying what swh's makefile does, which is something like this: > >gcc -flat_namespace -undefined suppress -o .libs/ringmod_1188.so >-bundle .libs/ringmod_1188.o -lm -march=i686 -nostartfiles > >clearly, i was talking out of my rear end about -nostartfiles Thanks, unfortunately I don't feel much wiser now. The developer.apple.com copy of the OSX ld man page simply says -bundle Produce a mach-o bundle that has file type MH_BUNDLE. That isn't entirely helpful, and I don't want to blindly use ld options I do not understand in the vague hope of it working out alright. So, sorry for the OSX users but they'll have to sort this out for themselves. Thanks again, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
Hi Damon, On Tue, 28 Jul 2009, Damon Chaplin wrote: > A quick update - fixes have been found for blop, caps & cmt, and the > ladspa Sine plugin problem is fixed in the latest version. Great job! Did you update your test program? Could you please post it to the list? Thanks, Gabriel ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-07-28 at 14:12 -0500, Gabriel M. Beddingfield wrote:
> Hi Damon,
>
> On Tue, 28 Jul 2009, Damon Chaplin wrote:
> > A quick update - fixes have been found for blop, caps & cmt, and the
> > ladspa Sine plugin problem is fixed in the latest version.
>
> Great job! Did you update your test program? Could you please post it to
> the list?
I've only reordered it so it connects the ports before calling activate,
to avoid the crashes with the amb and swh plugins.
I've attached the new version.
Damon
/*
* Test app to load & run all LADSPA plugins for one cycle.
*
* Compile with:
* gcc `pkg-config --cflags --libs gmodule-2.0` -lm -o test-ladspa test-ladspa.c
*
* Simply run it with './test-ladspa' to test all plugins.
* Run it with './test-ladspa -p PACKAGE' to test a particular package.
* (Run ./test-ladspa --help to see the list of known packages.)
*
* Run it with 'valgrind --tool=memcheck ./test-ladspa' to spot memory errors.
*/
#include
#include
#include
#include
#include
/* The default places to look for LADSPA plugins, if LADSPA_PATH isn't set. */
#define DEFAULT_LADSPA_PATH "/usr/lib/ladspa:/usr/local/lib/ladspa"
/* The sample rate to pass to the plugins. We don't output audio so it's not
too important. */
#define SAMPLE_RATE 48000
/* The number of samples to use for the run. Again, not too important. */
#define NUM_SAMPLES 256
static char *package = NULL;
static char **file_list = NULL;
/* These are the lists of files containing the plugins in the various
packages. I got most of these using 'rpm -ql '. There may be
more packages around that I haven't got installed at present. */
static char *amb_file_list[] = { "ambisonic1.so", "ambisonic2.so", NULL };
static char *blop_file_list[] = {
"adsr_1653.so", "adsr_1680.so", "amp_1654.so", "branch_1673.so",
"dahdsr_2021.so", "difference_2030.so", "fmod_1656.so",
"interpolator_1660.so", "lp4pole_1671.so", "parabola_1649_data.so",
"product_1668.so", "pulse_1645.so", "quantiser100_2029.so",
"quantiser20_2027.so", "quantiser50_2028.so", "random_1661.so",
"ratio_2034.so", "sawtooth_1641_data.so", "sawtooth_1641.so",
"sequencer16_1677.so", "sequencer32_1676.so", "sequencer64_1675.so",
"square_1643_data.so", "square_1643.so", "sum_1665.so",
"sync_pulse_2023.so", "sync_square_1678.so", "tracker_2025.so",
"triangle_1649.so",
NULL
};
static char *calf_file_list[] = { "calf.so", NULL };
static char *caps_file_list[] = { "caps.so", NULL };
static char *cmt_file_list[] = { "cmt.so", NULL };
static char *fil_file_list[] = { "filters.so", NULL };
static char *ladspa_file_list[] = { "amp.so", "delay.so", "filter.so",
"noise.so", "sine.so", NULL };
static char *mcp_file_list[] = { "cs_chorus.so", "cs_phaser.so",
"mvchpf24.so", "mvclpf24.so", NULL };
static char *rev_file_list[] = { "g2reverb.so", NULL };
static char *swh_file_list[] = {
"alias_1407.so", "allpass_1895.so", "am_pitchshift_1433.so", "amp_1181.so",
"analogue_osc_1416.so", "bandpass_a_iir_1893.so", "bandpass_iir_1892.so",
"bode_shifter_1431.so", "bode_shifter_cv_1432.so", "butterworth_1902.so",
"chebstortion_1430.so", "comb_1190.so", "comb_1887.so",
"comb_splitter_1411.so", "const_1909.so", "crossover_dist_1404.so",
"dc_remove_1207.so", "decay_1886.so", "decimator_1202.so", "declip_1195.so",
"delay_1898.so", "delayorama_1402.so", "diode_1185.so", "divider_1186.so",
"dj_eq_1901.so", "dj_flanger_1438.so", "dyson_compress_1403.so",
"fad_delay_1192.so", "fast_lookahead_limiter_1913.so", "flanger_1191.so",
"fm_osc_1415.so", "foldover_1213.so", "foverdrive_1196.so",
"freq_tracker_1418.so", "gate_1410.so", "giant_flange_1437.so",
"gong_1424.so", "gong_beater_1439.so", "gsm_1215.so", "gverb_1216.so",
"hard_limiter_1413.so", "harmonic_gen_1220.so", "hermes_filter_1200.so",
"highpass_iir_1890.so", "hilbert_1440.so", "imp_1199.so", "impulse_1885.so",
"inv_1429.so", "karaoke_1409.so", "latency_1914.so", "lcr_delay_1436.so",
"lowpass_iir_1891.so", "ls_filter_1908.so", "matrix_ms_st_1421.so",
"matrix_spatialiser_1422.so", "matrix_st_ms_1420.so", "mbeq_1197.so",
"mod_delay_1419.so", "multivoice_chorus_1201.so", "notch_iir_1894.so",
"phasers_1217.so", "pitch_scale_1193.so", "pitch_scale_1194.so",
"plate_1423.so", "pointer_cast_1910.so", "rate_shifter_1417.so",
"retro_flange_1208.so", "revdelay_1605.so", "ringmod_1188.so",
"satan_maximiser_1408.so", "sc1_1425.so", "sc2_1426.so", "sc3_1427.so",
"sc4_1882.so", "sc4m_1916.so", "se4_1883.so", "shaper_1187.so",
"sifter_1210.so", "sin_cos_1881.so", "single_para_1203.so",
"sinus_wavewrapper_1198.so", "smooth_decimate_1414.so", "split_1406.so",
"step_muxer_1212.so", "surround_encoder_1401.so", "svf_1214.so",
"tape_delay_1211.so", "transient_1206.so", "triple_para_1204.so",
"valve_1209.so", "valve_rect_1405.so", "vynil_1905.so",
"wave_terrain_1412.so", "xfade_1915.so", "zm1_1428.so",
NULL
};
static char *tap_file_list[] = {
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-07-28 at 19:08 +0200, hollun...@gmx.at wrote: > Hi Damon, thanks for your efforts. > > How does your test compare to the ladspa demolition thing? They're pretty similar actually. Unfortunately I hadn't heard of demolition - maybe it should be mentioned on ladspa.org or go in the SDK. It looks like it does a bit more testing of the plugin interface than my simple test app. I hope plugin maintainers run that on their plugins as well. > Are you sure you use the latest version of each? Ultimately the authors > should test themselves, but.. I think I have the latest versions. I've built most of them from source now to get the debugging info. > Some ladspas you missed: > acweight > autotalent > invada-studio-plugins > njl > vcf acweight is OK autotalent 0.1 is OK invada 0.3.1 is OK vcf is OK njl 0.2.1 has an Invalid Write. in "Continuous Risset Scales" instantiate:122 It looks like: float *tbl = malloc(sizeof(float) * TBL_SIZE + 1); should be: float *tbl = malloc(sizeof(float) * (TBL_SIZE + 1)); Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On 28 Jul 2009, at 19:04, Tim Goetze wrote: > [Paul Davis] >>> So will it link on OSX if I remove -nostartfiles? >> >> i'd suggest copying what swh's makefile does, which is something >> like this: >> >> gcc -flat_namespace -undefined suppress -o .libs/ringmod_1188.so >> -bundle .libs/ringmod_1188.o -lm -march=i686 -nostartfiles >> >> clearly, i was talking out of my rear end about -nostartfiles > > Thanks, unfortunately I don't feel much wiser now. The > developer.apple.com copy of the OSX ld man page simply says > > -bundle Produce a mach-o bundle that has file type MH_BUNDLE. It's a looong time ago I figured out those options, but if I remember correctly it's required to let you build real .so files. Because of the way the Mach kernel loads libraries, OSX libraries are not generally Mach-O bundles (.so-s), which are what you need to dynamically load objects. They're usually .dylib files - some other sort or Mach object. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
Hi, I've tracked down all the issues spotted by my test app and emailed all the maintainers. So hopefully they'll get fixed. I've tried the demolition test app as well. The output isn't too clear so I've summarised the major issues spotted: Demolition Findings CALF 34049 "Calf MultiChorus LADSPA" all input controls FLOAT MAX: Watchdog timeout 33924 "Calf Phaser LADSPA" all input controls FLOAT MIN: Segfault 33918 "Calf Reverb LADSPA" all input controls FLOAT MAX: Assertion failure CMT 1226 "Phase Modulated Voice" all input controls FLOAT MAX: Watchdog timeout 1849 "Logistic Map Control Generator" all input controls FLOAT MIN: Watchdog timeout 1221 "Analogue Voice" all input controls FLOAT MAX: Watchdog timeout SWH 1605 "Reverse Delay (5s max)" all input controls FLOAT MAX: Segfault 1208 "Retro Flanger" all input controls +Inf: Watchdog timeout 1905 "VyNil (Vinyl Effect)" all input controls zero: Watchdog timeout 1211 "Tape Delay Simulation" all input controls +Inf: Watchdog timeout 1904 "GLAME Butterworth Highpass" instantiate/cleanup: Segfault 1903 "GLAME Butterworth Lowpass" instantiate/cleanup: Segfault 1902 "Glame Butterworth X-over Filter" instantiate/cleanup: Segfault 1894 "Mag's Notch Filter" instantiate/cleanup: Segfault 1890 "Glame Highpass Filter" instantiate/cleanup: Segfault 1891 "Glame Lowpass Filter"instantiate/cleanup: Segfault 1892 "Glame Bandpass Filter" instantiate/cleanup: Segfault 1893 "Glame Bandpass Analog Filter"instantiate/cleanup: Segfault "Watchdog timeout" means the run function takes too long - maybe an infinite loop. "instantiate/cleanup" means the plugin's instantiate function was called and then the cleanup function, with nothing else. That sort of thing can happen with modular synths. I'm not sure we should worry about problems with controls set to "Inf", but all normal values should probably be handled OK. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
Damon Chaplin wrote: > Hi, > > I've tracked down all the issues spotted by my test app and emailed all > the maintainers. So hopefully they'll get fixed. Great work! We need good plugins! :) Regards. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Thu, 30 Jul 2009 11:49:42 +0200 Grammostola Rosea wrote: > Damon Chaplin wrote: > > Hi, > > > > I've tracked down all the issues spotted by my test app and emailed > > all the maintainers. So hopefully they'll get fixed. > Great work! We need good plugins! :) > > > Regards. > > \r Definitely. There currently are a number of problems with ladspa and lv2 plugins. I did I test where I only loaded each of them in ardour which caused lots of crashes. It can be found in form of two or the bugreports in the ardour tracker. The problem with that test was that it was hard to tell whether it was ardours or the plugins fault (or both). Now having some QA on the plugin side helps quite a bit. Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Thu, 2009-07-30 at 11:55 +0200, xmag wrote:
> Hi,
>
> I wrote all the Glame* filters, did you send me an email, and if, where
> did you send it :-)
I sent Steve Harris an email about some issues in the swh plugins, but
no problems were spotted in the Glame* filters by my test app.
> What is your testapp doing?
> I guess, your probably just calling instantiate and then cleanup.
Just this:
if ((handle = instantiate(descriptor, SRATE))) {
descriptor->cleanup(handle);
}
> The structs are initialized within the activate function. I don't know
> whether it is mandatory to call this function or not.
I don't think it is mandatory. I can't see that in the spec.
> A quick look in my code shows, that in util/iir.h the function
> free_iirf_t does not check if the pointers are different from NULL
> before freeing them. This probably causes the segfault.
> Maybe this should be fixed :)
Yep, that fixes all of them, in iir.h and iir.c.
Thanks.
Damon
--- iir.h.orig 2006-08-08 16:53:50.0 +0100
+++ iir.h 2009-07-30 11:09:59.0 +0100
@@ -63,9 +63,11 @@ static inline iirf_t* init_iirf_t(iir_st
static inline void free_iirf_t(iirf_t* iirf, iir_stage_t* gt) {
int i;
- for(i=0;iavailst;i++){
- free(iirf[i].iring);
- free(iirf[i].oring);
+ if (gt){
+ for(i=0;iavailst;i++){
+ free(iirf[i].iring);
+ free(iirf[i].oring);
+ }
}
free(iirf);
};
--- iir.c.orig 2003-09-13 12:55:23.0 +0100
+++ iir.c 2009-07-30 11:12:45.0 +0100
@@ -85,10 +85,12 @@ void combine_iir_stages(int mode, iir_st
void free_iir_stage(iir_stage_t *gt){
int i;
- for(i=0;iavailst;i++)
- free(gt->coeff[i]);
- free(gt->coeff);
- free(gt);
+ if (gt){
+ for(i=0;iavailst;i++)
+ free(gt->coeff[i]);
+ free(gt->coeff);
+ free(gt);
+ }
}
/* center: frequency already normalized between 0 and 0.5 of sampling
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On 30 Jul 2009, at 10:34, Damon Chaplin wrote: > > CMT > 1226 "Phase Modulated Voice" all input controls FLOAT MAX: Watchdog > timeout > 1849 "Logistic Map Control Generator" all input controls FLOAT MIN: > Watchdog timeout > 1221 "Analogue Voice" all input controls FLOAT MAX: Watchdog timeout > > SWH > 1605 "Reverse Delay (5s max)" all input controls FLOAT MAX: Segfault > 1208 "Retro Flanger" all input controls +Inf: Watchdog > timeout > 1905 "VyNil (Vinyl Effect)" all input controls zero: Watchdog > timeout > 1211 "Tape Delay Simulation" all input controls +Inf: Watchdog > timeout I'll look at those. > 1904 "GLAME Butterworth Highpass" instantiate/cleanup: Segfault > 1903 "GLAME Butterworth Lowpass" instantiate/cleanup: Segfault > 1902 "Glame Butterworth X-over Filter" instantiate/cleanup: Segfault > 1894 "Mag's Notch Filter" instantiate/cleanup: Segfault > 1890 "Glame Highpass Filter" instantiate/cleanup: Segfault > 1891 "Glame Lowpass Filter"instantiate/cleanup: Segfault > 1892 "Glame Bandpass Filter" instantiate/cleanup: Segfault > 1893 "Glame Bandpass Analog Filter"instantiate/cleanup: Segfault Those are difficult to fix. They were ported from a different plugin system with different rules. > I'm not sure we should worry about problems with controls set to > "Inf", > but all normal values should probably be handled OK. According to the specs, you're supposed to handle that case. It would see a bit antisocial on the part of hosts though. - Steve ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
2009/7/30 Steve Harris : > On 30 Jul 2009, at 10:34, Damon Chaplin wrote: >> 1904 "GLAME Butterworth Highpass" instantiate/cleanup: Segfault >> 1903 "GLAME Butterworth Lowpass" instantiate/cleanup: Segfault >> 1902 "Glame Butterworth X-over Filter" instantiate/cleanup: Segfault >> 1894 "Mag's Notch Filter" instantiate/cleanup: Segfault >> 1890 "Glame Highpass Filter" instantiate/cleanup: Segfault >> 1891 "Glame Lowpass Filter" instantiate/cleanup: Segfault >> 1892 "Glame Bandpass Filter" instantiate/cleanup: Segfault >> 1893 "Glame Bandpass Analog Filter" instantiate/cleanup: Segfault > > Those are difficult to fix. They were ported from a different plugin > system with different rules. I think I already contacted you on these... yeah, here's what I wrote you some time ago: If you instantiate and then cleanup, cleanupBandpass_iir() calls free_iirf_t() with two NULLs as parameters, which are then derefenced by the last function. HTH, Stefano ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 28 Jul 2009 21:31:42 +0100 Damon Chaplin wrote: > > On Tue, 2009-07-28 at 14:12 -0500, Gabriel M. Beddingfield wrote: > > Hi Damon, > > > > On Tue, 28 Jul 2009, Damon Chaplin wrote: > > > A quick update - fixes have been found for blop, caps & cmt, and > > > the ladspa Sine plugin problem is fixed in the latest version. > > > > Great job! Did you update your test program? Could you please > > post it to the list? > > I've only reordered it so it connects the ports before calling > activate, to avoid the crashes with the amb and swh plugins. > > I've attached the new version. > > Damon One more that could use testing: guitarix (when you build the application it also builds ladspa plugins) Philipp ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
Damon Chaplin schrieb: > Hi, > > I've been having problems with a few LADSPA plugins recently, so I've > written a little test app that loads all LADSPA plugins, connects the > ports and runs them for one cycle. (I've attached it here.) > > I've run it on the plugin packages I have installed, using valgrind, and > the results are: > > amb crashes > blop memory errors (patches sent for some of the errors) > calf memory errors in Flanger & MultiChorus plugins > caps memory errors in 3 plugins > cmt memory errors (patches sent) > fil OK > ladspa memory errors in Sine plugin (mismatched free/deletes) > mcp OK > rev OK > swh crashes > tap memory errors in 5 plugins > vco OK > > Note that not all memory errors are bugs, but most are. (There's also a > chance that my test app is buggy, rather than the plugins.) > > I've sent a few patches for cmt and blop, and will probably try to track > down the bugs in a few other packages. If others want to help > (especially the owners of the above packages!) that would be good. > > Damon > This testing is great stuff. It would be cool to have a buildbot (http://buildbot.net) and run this regularly. Ideally test-tools would be part of ladspa/lv2 sdk and the plugin-packages add running the test tools as part of make check. Bonus points for rerunning tests on success under valgrind memcheck once again. Stefan ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote: > Damon Chaplin schrieb: > > Hi, > > > > I've been having problems with a few LADSPA plugins recently, so I've > > written a little test app that loads all LADSPA plugins, connects the > > ports and runs them for one cycle. (I've attached it here.) > > > > I've run it on the plugin packages I have installed, using valgrind, and > > the results are: > > > > amb crashes > > blopmemory errors (patches sent for some of the errors) > > calfmemory errors in Flanger & MultiChorus plugins > > capsmemory errors in 3 plugins > > cmt memory errors (patches sent) > > fil OK > > ladspa memory errors in Sine plugin (mismatched free/deletes) > > mcp OK > > rev OK > > swh crashes > > tap memory errors in 5 plugins > > vco OK > > > > Note that not all memory errors are bugs, but most are. (There's also a > > chance that my test app is buggy, rather than the plugins.) > > > > I've sent a few patches for cmt and blop, and will probably try to track > > down the bugs in a few other packages. If others want to help > > (especially the owners of the above packages!) that would be good. > > > > Damon > > > > This testing is great stuff. It would be cool to have a buildbot > (http://buildbot.net) and run this regularly. Ideally test-tools would be part > of ladspa/lv2 sdk and the plugin-packages add running the test tools as part > of > make check. Bonus points for rerunning tests on success under valgrind > memcheck > once again. ++ -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote: > This testing is great stuff. It would be cool to have a buildbot > (http://buildbot.net) and run this regularly. Ideally test-tools would be part > of ladspa/lv2 sdk and the plugin-packages add running the test tools as part > of > make check. Bonus points for rerunning tests on success under valgrind > memcheck > once again. Here's my latest test apps for LADSPA and LV2. I've ported most of the demolition tests over to both of them. If people want to put them in the LADSPA/LV2 SDKs and add extra tests etc. that would be fine. Damon test-lv2.c.gz Description: GNU Zip compressed data test-ladspa.c.gz Description: GNU Zip compressed data ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-08-04 at 12:59 +0100, Damon Chaplin wrote: > On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote: > > > This testing is great stuff. It would be cool to have a buildbot > > (http://buildbot.net) and run this regularly. Ideally test-tools would be > > part > > of ladspa/lv2 sdk and the plugin-packages add running the test tools as > > part of > > make check. Bonus points for rerunning tests on success under valgrind > > memcheck > > once again. > > Here's my latest test apps for LADSPA and LV2. I've ported most of the > demolition tests over to both of them. > > If people want to put them in the LADSPA/LV2 SDKs and add extra tests > etc. that would be fine. I'd be happy to include the LV2 one in SLV2 if you'd like and there's nowhere better for it to go... (there's no LV2 SDK) Cheers, -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] Test app for LADSPA plugins
On Tue, 2009-08-04 at 10:07 -0400, David Robillard wrote: > On Tue, 2009-08-04 at 12:59 +0100, Damon Chaplin wrote: > > On Sat, 2009-08-01 at 23:16 +0300, Stefan Kost wrote: > > > > > This testing is great stuff. It would be cool to have a buildbot > > > (http://buildbot.net) and run this regularly. Ideally test-tools would be > > > part > > > of ladspa/lv2 sdk and the plugin-packages add running the test tools as > > > part of > > > make check. Bonus points for rerunning tests on success under valgrind > > > memcheck > > > once again. > > > > Here's my latest test apps for LADSPA and LV2. I've ported most of the > > demolition tests over to both of them. > > > > If people want to put them in the LADSPA/LV2 SDKs and add extra tests > > etc. that would be fine. > > I'd be happy to include the LV2 one in SLV2 if you'd like and there's > nowhere better for it to go... (there's no LV2 SDK) Yep, that sounds good. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
