[linux-audio-dev] LADSPA needs & wishes

Fraser fraser at arkhostings.com
Mon Jan 29 02:18:11 UTC 2007

Hi Steve,

>> ahh, so there is a V2 coming, not too much info about it yet out there
>> (unless you know where to look)
> Which is deliberate, as it's not quite finished yet. There was quite
> a lot of discussion here though.

I took me a while to find this list.

The http://www.ladspa.org site refers to the linux audio developers
mailing list as being here: http://www.linuxaudiodev.com/ which has had
nothing but a holding page since the middle of last year...

> Sure. This was an issue in LADSPA, though not a significant enough
> one that anyone wanted it changed. I would suspect you're
> overestimating the burden compared to the function call overhead and
> cache thrashing. I'd be interested to see figures indicating
> otherwise though. There will obviously be cases where it's faster to
> set values using callbacks, but I'll bet it's not universal.

Perhaps I am yes.
I am more thinking about the consequences of this when running 40+ plugins
as the same time (mixing in VST for example I'll use that many plugins
easily). With that many the conversions would add up to something but like
you say it could be neglible. I'll try to benchmark it and post some

I had a thought last night about this - if I am worried about the load
from converting parameters I can always do something like:

if(current_control_value1 != last_control_value1)
  recalculate internal_value1

in the run loop

BTW this all came about from one of the plugins I'm working one - 10
parameters from which 50 internals are calculated - lots of
sin,cos,tan,pow & sqrt's going on. By keeping track of the previous values
at least I can recalculate when I detect a change rather than every run()

>> 3) changes to parameters can be presented to the run() function
>> immediately
> I don't see how it makes any difference in this area?

in the example code this line:

        const float gain = *(plugin_data->gain);

is outside the for loop in the run() function
so changes to the gain are not picked up till the next run() call.

whereas in my example I had my (magically converted) parameter inside the
for loop - so any changes are picked up immediately:

        for (pos = 0; pos < sample_count; pos++) {
                output[pos] = input[pos] * plugin_data->MyTranslatedGain;

When you consider plugin parameters can be automated and music is all
about timing, having an unpredictable delay between when a parameter is
changed and when the new value is applied could be an issue (ie you can't
make the sound being produced by a plugin change 'on the beat').
With my setup, blocks of audio are 2048 fames in size, so my run()
function will pick up changes every 46ms - which is an audible delay

(yes I agree this is a small deal and if really matters to the plugin
there are ways around it)


More information about the Linux-audio-dev mailing list