Subject: Re: [linux-audio-dev] extending LADSPA, it's not that easy ......
From: David Olofson (david_AT_gardena.net)
Date: Sat Nov 04 2000 - 05:14:41 EET
On Wed, 25 Oct 2000, Benno Senoner wrote:
[...]
> What we need is to linearly interpolate the control values inside the plugin.
> (Anything more than linear interpolation gets too complex for realtime work.)
There *are* ways to calculate or approximate polynomial coefficients
quickly, but it's probably just a waste of time (development and
still some CPU) anyway, in most cases.
There is another problem, as well: If this interpolation is supposed
to take normal control points as input (as opposed to
<target_y, Dy[, DDy]> points calculated outside the plugin), the
control signals will be delayed, and this delay will increase as the
interpolation deepth increases.
> That means that the plugin needs to support parameter fading.
> If you want simple linear fades you can use arbitrary high blocksizes,
> otherwise,in the case that you need complex stuff like exponential fades or
> arbitrary ones,
> you can use buffersizes of 32-64 samples and let the host
> modulate the parameters with a control rate of 350-700Hz which in turn are
> sloped linearly, leading to a perceptually perfect , zipper-free result.
No news, but in case anyone complains about the timing granularity
introduced by the one-change-per-buffer model: Timestamped events in
queues. This decouples the timing from the buffer size, and actually
*saves* CPU time in the average case (assuming that means "most
control inputs don't change") as the plugins don't even have to check
the input control ports for changes.
> Ideally plugins should have a flag to tell the host if a parameter supports
> linear sloping or not, and a method (a switch) to turn it off and on.
> (sometimes interpolation between two subsequent control values is not desired)
Not fun. Implementations would require plugins to have special cases
somewhere, unless the flag was for *all* control inputs; ie "all
inputs interpolated" or "no inputs interpolated" - that could be
dealt with by switching between two run() implementations.
OTOH, if it's only about occasional special cases, one could just
add a function call of the style set_control_fast(), that the host
could use to force a control port to change without interpolation.
Anyway, in most cases I think it's best if the *plugin* decides when
to interpolate and not, as the requirements on the interpolation
resolution, max speed etc depends on what the plugin actually does
with the resulting control data. (Some plugins may for example
require that the control frequency is always kept below the audio
frequency band.)
> Plus if you keep the buffersizes small , some plugins can greaty optimize the
> parameter fading:
> take a resonant low-pass filter:
> using the method I described above, the plugin would need to interpolate both
> resonance and cutoff which would mean a recalculation of filter coefficients
> for EACH sample, which can become quite heavy.
> Instead of recalculating the filter coefficients for each sample, we can
> determine them for the start and end value and then slope the coefficients
> linearly.
> As said this utilizes the fact that you can aproximate everything with a
> straight line within a short interval. (and since the rate of control data is
> so low, it will be perceptually indistinguishable form the "perfect" method.
>
> A host should act as Conrad proposed but with the addition that it should query
> if the plugin has interpolation capabilities or not and/or if it requires small
> blocksizes (like the lowpass filter).
Although that would be a simple way to avoid the problem, I don't
think it belongs there at all. The reason why some plugins behave in
undesired ways if you pass them to large buffers along with control
input slides is that the *plugins* are cheating with the maths! I
don't think the API and/or hosts should pay for that; especially
since it can be avoided by just forcing sensitive plugins to do
something more sensible.
That is, rather than forcing hosts to help cheating plugins, why not
just specify that plugins should do (or rather emulate) what they
claim to be capable of when they say "I support linear interpolation
of control data"...?
Implementation: Have a conditional buffer break-up kick in if the
buffer size exceeds a certain value.
total_samples = SampleCount;
do
{
if(total_samples > MAX_SECTION_SAMPLES)
SampleCount = MAX_SECTION_SAMPLES;
else
SampleCount total_samples;
total_samples -= SampleCount;
recalculate control interpolation coefficients;
while(SampleCount--)
{
interpolate control data;
process one frame;
}
} while(total_samples);
> That way, if an editor supports only linear sloping and the plug has this
> capability and does not require small buffersizes, it can simply pass a large
> buffer to the plugin for processing.
Using the method above, the host doesn't have to bother asking the
plugin - it can *always* just pass a large buffer for processing, as
long as a linear scale is what it wants. :-)
[...]
> The LADSPA docs should point out that plugs should support the parameter
> interpolation in order to facilitate (in the case of linear fade segments)
> parameter automation and/or to improve audio quality (for fast parameter
> shifts).
Frankly, nearly *all* plugins intended to be used for serious audio
processing will have to do this interpolation anyway. I think it's a
good idea to specify the semantics of this "trick" more strictly, as
that makes it more useful (ie loooooong linear fades w/o parameter
modulation overhead over the interface), and more reliable. (That is,
it won't break or behave mysteriously with some hosts - it
definitely will if there's no aggreed upon definition of what hosts
and plugins should mean by "control data interpolation".)
> And this is not only good for offline processing: realtime processing
> will take advantage of the interpolation capabilities too:
>
> take a gain plugin that is driven by a MIDI CC (with its limited 128step
> resolution).
> Without interpolation you can easily experience zipper noise.
Or rather, *both* zipper noise *and* quantization noise. Not very
nice at all...
> Add interpolation to the gain plug and the output will be smooth, since
> the plug happily interpolates between consecutive volume parameter values.
It will also be delayed by one event, as it's a bit hard to "slide
towards the next point, which we have not yet received"...
"No big deal", you may think (probably being right for most
scenarios), but the problem is that MIDI says
"Change to level X NOW!",
wheras this interpolated control port extension would expect to hear
"Slide from the current value to level X in Y sample frames."
(where Y is actually the SampleFrames argument of LADSPA.) Not quite
the same action! LADSPA would use the buffer size as a kind of time
base for the interpolation, while MIDI doesn't have a notion of time
at all! (Ommitting MTC, as it's not relevant here.) There is nothing
in the MIDI data that indicates when we can expect to see the next
update of our controller.
> I'd like to hear what you like and do not like of this model.
Well, that's about it! :-) I like the idea of officially defining in
the API how parameter interpolation should be done, to avoid
plugin/host (developer) communication problems. I also like the idea
of allowing applications to make useful assumptions about how plugins
will deal with certain situations, rather than just "guessing" that
some plugins will try to "smooth" control data in some way.
//David
.- M u C o S -------------------------. .- David Olofson --------.
| A Free/Open Source | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
| for | | Open Source Advocate |
| Professional and Consumer | | Singer |
| Multimedia | | Songwriter |
`-----> http://www.linuxdj.com/mucos -' `---> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : Mon Nov 06 2000 - 00:15:19 EET