Re: [linux-audio-dev] LADSPA needs & wishes

On 29 Jan 2007, at 02:18, Fraser wrote:

> Hi Steve,

Hi Fraser,

>> 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.
>
> 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

Yes, exactly. It's slightly more expensive as you have a conditional,
but you save the function call overhead, which is something like
1000-1500 cycles IIRC.

>>> 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.

Ah, well the host is not supposed to change port values during run()
anyway, the idea in LADSPA (and LV2) is that the host should chop the
run() block where port values change. In practice not all hosts do
that, some just pick a suitably small block size, eg. 32 frames and
quantise the changes to that rate.

- Steve
Received on Mon Jan 29 12:15:02 2007