[linux-audio-dev] LADSPA needs & wishes

[Steve Harris]

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