Subject: Re: [linux-audio-dev] changing control port values with LADSPA: a serious issue?
From: David Olofson (david_AT_gardena.net)
Date: Sun Mar 17 2002 - 04:00:32 EET
On Sunday 17 March 2002 00.11, Jake Donham wrote:
> "David" == David Olofson <david_AT_gardena.net> jots:
>
> David> 1) Simple operations are memory bound on modern
> machines.
>
> David> 2) Using more buffers increases cache footprint, and
> thus David> increases the number of cache misses.
>
> David> 3) If there is heavy work going on in the background,
> David> there's a big chance the audio and control buffers
> David> will be thrown out - which results in increased use
> David> of memory having a *much* harder impact on
> David> performance.
>
> Interesting.
>
> Does this not apply to the instruction cache as well--
Yes. In fact, most modern CPUs don't even have a separate instruction
cache. (The 68k CPUs up to 030 did, though - not sure about the rest.)
>that is, if
> you touch less memory at the cost of increasing the code size of
> all plugins (which must now include interpolation code) have you
> really won? Depends on how much extra code, and how big your
> buffers.
Correct.
However, for a really low latency buffer size, like 32 frames, that
would be 128 bytes per control port. That's a *lot* of code to
implement interpolation for one port... ;-)
Besides, if code size should really matter, you could implement
interpolation using a loop for all control ports, making the
difference even bigger.
> >> It doesn't seem like a good idea to hard-code particular
> >> kinds of parameter interpolation, linear or otherwise.
>
> David> You have to consider the cost of any conditional code in
> David> plugins and hosts - and not only the complexity, but
> also David> the cost of pipeline flushes when branches are
> David> mispredicted...
>
> Right, that's why I was suggesting a separate control buffer, so
> plugins wouldn't have to do any extra computation.
Yes - but apart from the memory issue, there's another, much more
serious problem. Consider this simple 12 dB state variable filter:
---8<---------------------------------------
Set cut-off:
f = 2.0 * sin(M_PI * cutoff * dt);
Set resonance:
q = 1.0 / resonance;
Filter one sample:
l += f*b;
h = in - l - q*b;
b += f*h;
--------------------------------------->8---
Of course, with a decent FPU, you could just run all of that in your
inner loop and get away with it - but you can forget about real time
on a Pentium! (A Pentium *would* handle the actual filter without
complaining too much, though.)
If you want to speed things up, you'll have to calculate an
approximate "ramp" of sufficient degree (linear, cubic, ...) for
*'f'* instead of 'cutoff'. How would you go about doing that if you
get a full audio rate buffer of control data?
For more complex filters FIR and other effects, this effect will be
even more important. This is why it's probably better to just leave
the interpolation to the plugins - or at least, provide
"interpolation parameters" in a form that plugins could transform as
needed.
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
`----------------------> http://www.linuxaudiodev.com/maia -'
.- David Olofson -------------------------------------------.
| Audio Hacker - Open Source Advocate - Singer - Songwriter |
`-------------------------------------> http://olofson.net -'
This archive was generated by hypermail 2b28 : Sun Mar 17 2002 - 03:50:37 EET