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
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
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 Filterinstantiate/cleanup: Segfault 1892 Glame Bandpass Filter instantiate/cleanup: Segfault 1893 Glame Bandpass Analog Filterinstantiate/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
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;igt-availst;i++){
- free(iirf[i].iring);
- free(iirf[i].oring);
+ if (gt){
+ for(i=0;igt-availst;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;igt-availst;i++)
- free(gt-coeff[i]);
- free(gt-coeff);
- free(gt);
+ if (gt){
+ for(i=0;igt-availst;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] LV2 test apps?
On Thu, 2009-07-30 at 11:27 +0100, james morris wrote:
Are there any similar testing tools for LV2 plugins?
Although I'm familiar with gdb and valgrind, I don't know how to go
about using these with plugins, and I guess/assume a simple host
(perhaps one specifically designed for testing) would be best for doing
this? Are there any existing tools?
I've done a quick port of my little test app to LV2. I've attached it.
We could add the various control port input tests from demolition later.
My first test results:
calf - memory errors in 2 of the small plugins.
(plus the organ had an unknown port type so was skipped)
ll - OK, except 3 of the plugins couldn't be instantiated.
2 seem to have incorrect URLs in the cpp files.
Not sure about the other one.
swh - crashes (a known bug actually).
Damon
/*
* Test app to load run all LV2 plugins for one cycle.
*
* Compile with:
* gcc `pkg-config --cflags --libs slv2 glib-2.0` -lm -o test-lv2 test-lv2.c
*
* Simply run it with './test-lv2' to test all plugins.
* Run it with './test-lv2 -p PACKAGE' to test a particular package.
* (Run ./test-lv2 --help to see the list of known packages.)
*
* Run it with 'valgrind --tool=memcheck ./test-lv2' to spot memory errors.
*
* Released under GNU General Public License version 2.
* Bits from lv2_jack_host Copyright (C) 2007-2009 Dave Robillard drobilla.net
*/
#include stdlib.h
#include string.h
#include glib.h
#include slv2/slv2.h
/* 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
/* The size of the event buffer. */
#define EVENT_BUFFER_CAPACITY 1024
static char *package = NULL;
static char *uri_prefix = NULL;
static int uri_prefix_len = 0;
static char *plugin_uri = NULL;
static SLV2Value audio_class;
static SLV2Value control_class;
static SLV2Value event_class;
/* LV2_URI_Map stuff. */
#define LV2_URI_MAP_URI http://lv2plug.in/ns/ext/uri-map;
typedef void* LV2_URI_Map_Callback_Data;
typedef struct {
LV2_URI_Map_Callback_Data callback_data;
uint32_t (*uri_to_id)(LV2_URI_Map_Callback_Data callback_data,
const char* map,
const char* uri);
} LV2_URI_Map_Feature;
/* LV2_Event stuff. */
#define LV2_EVENT_URI http://lv2plug.in/ns/ext/event;
#define LV2_EVENT_AUDIO_STAMP 0
typedef struct {
uint32_t frames;
uint32_t subframes;
uint16_t type;
uint16_t size;
} LV2_Event;
typedef struct {
uint8_t* data;
uint16_t header_size;
uint16_t stamp_type;
uint32_t event_count;
uint32_t capacity;
uint32_t size;
} LV2_Event_Buffer;
typedef void* LV2_Event_Callback_Data;
typedef struct {
LV2_Event_Callback_Data callback_data;
uint32_t (*lv2_event_ref)(LV2_Event_Callback_Data callback_data,
LV2_Event* event);
uint32_t (*lv2_event_unref)(LV2_Event_Callback_Data callback_data,
LV2_Event* event);
} LV2_Event_Feature;
/** URI map feature, for event types (we use only MIDI) */
#define MIDI_EVENT_ID 1
uint32_t
uri_to_id(LV2_URI_Map_Callback_Data callback_data,
const char* map,
const char* uri)
{
if (!strcmp(map, LV2_EVENT_URI) !strcmp(uri, SLV2_EVENT_CLASS_MIDI))
return MIDI_EVENT_ID;
else
return 0; // no id for you!
}
static LV2_URI_Map_Feature uri_map = { NULL, uri_to_id };
static const LV2_Feature uri_map_feature = { http://lv2plug.in/ns/ext/uri-map;, uri_map };
/** We don't support type 0 events, so the ref and unref functions just point
to the same empty function. */
uint32_t event_ref_func(LV2_Event_Callback_Data callback_data,
LV2_Event* event)
{
return 0;
}
static LV2_Event_Feature event_ref = { NULL, event_ref_func, event_ref_func };
static const LV2_Feature event_ref_feature = { http://lv2plug.in/ns/ext/event;,
event_ref };
const LV2_Feature* features[3] = { uri_map_feature, event_ref_feature, NULL };
static gboolean
port_is_a (SLV2Plugin plugin,
SLV2Port port,
SLV2Value value)
{
SLV2Values port_classes = slv2_port_get_classes (plugin, port);
gint i, num_classes = slv2_values_size (port_classes);
const gchar *value_string = slv2_value_as_string (value);
SLV2Value class_value;
for (i = 0; i num_classes; i++)
{
class_value = slv2_values_get_at (port_classes, i);
if (!strcmp (slv2_value_as_string (class_value), value_string))
return TRUE;
}
return FALSE;
}
static gpointer
create_buffer_for_port (SLV2Plugin plugin,
gint port_num)
{
SLV2Port port;
SLV2Value def, min, max;
LV2_Event_Buffer *event_buffer;
gfloat *buffer = NULL;
gint i;
port = slv2_plugin_get_port_by_index (plugin, port_num);
if (port_is_a (plugin, port, audio_class))
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
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, 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 stdlib.h
#include math.h
#include glib.h
#include gmodule.h
#include ladspa.h
/* 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 PACKAGE'. 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[] = {
tap_autopan.so, tap_chorusflanger.so, tap_deesser.so, tap_doubler.so,
tap_dynamics_m.so, tap_dynamics_st.so, tap_echo.so, tap_eq.so,
tap_eqbw.so, tap_limiter.so, tap_pinknoise.so, tap_pitch.so,
tap_reflector.so, tap_reverb.so
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] SynthForge - new modular synth builder
On Mon, 2009-06-29 at 14:26 +0200, hollun...@gmx.at wrote: does the build depend on the swh plugins or are they just necessary because you wouldn't be able to do anything without them? In other words: are they a compiletime dependency? No, it should compile fine without them. They are used in the demo, which is loaded at start-up. So that won't work without them. SynthForge uses LADSPA LV2 modules to build the synths, so you need some of those to do anything useful. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [RFC] LADSPA 1.2
On Thu, 2009-06-18 at 20:58 +0200, Stefano D'Angelo wrote:
2009/6/18 Fons Adriaensen f...@kokkinizita.net:
5. Add something like this to the API:
struct {
float value;
const char *name;
} ladspa_port_value_enum;
struct ladspa_port_value_enum * ladspa_get_port_value_enums(unsigned long
descriptor_index, unsigned long port_index);
Would not be backwards compatible as far as I can see.
Uh? Why not? Exporting a new symbol breaks API/ABI???
You mean adding a function outside the LADSPA_Descriptor, don't you?
i.e. another function like ladspa_descriptor(). (There seems to be some
confusion!)
I think your idea is cleaner than Fons', and has the advantage of
allowing non-integer values for the settings.
Damon
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [RFC] LADSPA 1.2
On Thu, 2009-06-18 at 23:23 +0200, Stefano D'Angelo wrote: Sorry, didn't see that. Well, I guess there's no problem on the plugin side then... any other possible problems on the host side? In case there are none, we could add an array or another callback. You'd need a way to let the host know if the plugin is version 1.1 or 1.2. Otherwise the host might try to use the new fields which might be garbage. I can't see a way of getting a LADSPA version number from a plugin at present. Maybe a ladspa_version() function could be added (outside LADSPA_Descriptor!), defaulting to 1.1. But I'd probably just go for the ladspa_get_port_value_enums() function and leave LADSPA_Descriptor untouched, just to be safe. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] jackd/jackdbus : D-Bus or not D-Bus...
On Tue, 2009-05-19 at 11:37 +0100, Rui Nuno Capela wrote: the main question, at least in my mind, is all about *which* settings will be used to auto-start the server, isn't it? an explicit command line, as in classic, should *always* take precedence over the settings in any internal configuration database, which i think the d-bus honors instead and that latter behavior is being the root of all d-bus evil. scnrt ;) If jackdbus migrated the settings from .jackdrc the first time it is run that would probably save a lot of hassle. Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Re: [LAD] pipe/cond/semaphore/etc benchmarks
On Fri, 2007-06-08 at 14:18 -0400, Dave Robillard wrote: Hi all, I remember a while back someone posting results of a benchmark to compare performance of pipes vs cond vs semaphores, but I can't find the specific post or code in the archives for the life of me. Does anyone have the /code/ for that benchmark (or anything similar I can fiddle with to do some testing)? Do you mean this one: http://linuxaudio.org/pipermail/linux-audio-dev/2006-July/016403.html Damon ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
