Subject: Re: [linux-audio-dev] extending LADSPA, it's not that easy ......
From: David Olofson (david_AT_gardena.net)
Date: Sat Nov 04 2000 - 07:09:55 EET
On Wed, 25 Oct 2000, Steve Harris wrote:
> On Wed, Oct 25, 2000 at 11:27:56AM +0200, Benno Senoner wrote:
>
> [discussion of 'zipper' artifacts v's block size etc.]
>
> > What we need is to linearly interpolate the control values inside the plugin.
> > (Anything more than linear interpolation gets too complex for realtime work.)
>
> The other obvious thing is for another type of input that works like the
> audio ones, but possibly at a reduced data rate. This is quite common I
> think, and it's certainly how the nord modular works internaly.
>
> What is the overhead on just providing something identical to audio
> streams (in data terms) but hinted differently? Would a plugin that
> required, say, 3 streams in addition to the 1-2 audio ones bring the
> system to it knees? Sorry, I don't know much about the hardware issues
> involved. Obviously it wouldn't be a problem for offline processing.
Performance is hardly a problem (although plugins would have to use
rather well optimized code for the internal resampling), but host
complexity is.
How do you deal with the different buffer sizes and the different
rates? Which rates are allowed? How do we connect control ports using
different sample rates?
Well, I have "simple" answers for all of those questions, and it's no
big deal to implement it. However, if it's a part of the API all
hosts and/or plugins *have* to deal with it one way or another, or
we'll soon end up with lots of "classes" of LADSPA plugins, which
won't run on host of all other classes, and/or won't work together
with plugins of certain classes. Not very nice, especially not for
the end-user.
Now, if we *really* want to implement this (rather than just hinting
some audio ports as actually being audio rate control ports), the
simplest way would be to decide on a single control sample rate,
based on a fixed relation to the audio sample rate. This fixed rate
should be somewhere between the two existing rates; the audio sample
rate (about 32..96 kHz) and the control rate (300-3000 Hz, depending
on how much overhead you can tolerate.)
Approaching the audio rate with the current control rate (buffer size
based) causes massive overhead, so one could estimate/guess some kind
of "highest feasible control rate" figure for the average plugin/host
combo. (How about 3000 Hz?) The new control sample rate would have to
be higher than this value for the feature to make sense.
As to the highest feasible sample rate for the new control ports,
this must be significantly lower than the audio sample rate, or there
will be no significant performance gain to motivate this performance
hack. (That's all it is! The perfect solution from the DSP POV would
be to use audio rate ports for everything.) How about a maximum of
25% of the audio rate; ie 12 kHz with an audio sample rate of 48 kHz?
(I'd guess that when processing control data only, the total CPU time
required would be reduced to somewhere around 30%. The run() call +
function init/exit overhead is still the same as for all other
plugins, which is why it won't go all the way down to 25%.)
Finally, there's a third frequency involved; the highest control
*signal* frequency we want to be able to deal with. This will be the
control rate frequency / 2, so assuming the limits above, we can set
it to somewhere between 1500 Hz and 6 kHz in a 48 kHz system. In
addition, it's a *very* good idea to give this frequency an even
power-of-two relation to the audio rate, narrowing the choices down
to audio fs / 4, 8 or 16.
That is, pick one row from this table:
fs: 32000 44100 48000 96000
-------------------------------------
fs/16 2000 2756.25 3000 6000
fs/8 4000 5513.5 6000 12000
fs/4 8000 11025 12000 24000
> The LADSPA interface is currently very clean and easy to code for, if
> something is added to allow for more accurate control changes I would
> like to see if maintain the clarity and shallow learning curve.
*That's* the problem...
I'm trying to do this with MuCoS, but I'm taking a different route.
Instead of fixed rate control signals, I'm using queues of
timestamped events. These events can change parameters between any
two samples in a buffer, without the CPU leaving the plugin. For
performance and complexity reasons, a plugin has only one input event
queue, and thus only has to keep track of one thing in the inner
loop: "How many samples left to the next event in the queue?"
(Obviously, someone has to make sure the events are sorted in
increasing timestamp order. I prefer to have hosts do this, rather
than to force every single plugin to sort it out, by giving them
multiple input queues. You always have to pay *somewhere*.)
The advantage with this over fixed rate control data is that you have
sample accurate control timing without constantly paying for in by
pumping huge amounts of DC level control signals to all control
ports. A plugin can have countless control "ports" without forcing
anyone to feed them with data, or even to connect anything to them,
and still the plugin will be ready to accept control data at any
sample rate, at any time, without any handshaking, reinitialization
or reconfiguration.
(Besides, events are actually *commands*, and they can be used to
build RPC-like protocols like varispeed/bidirectional streaming and
off-line processing extensions, or whatever - all without adding
overhead or complexity to the main path. It's even possible for a host
to route protocols it doesn't understand through "protocol manager
plugins", as a result of MuCoS' view of a "host" being more similar
to "low level communication protocol manager" than to "provider of all
kinds of resources and functionality". Oh well, you'll see it in
action any century now! ;-)
As for the fixed rate control ports; I think it has to be a
single, fixed, audio based sample rate, and fs/8 sounds reasonable to
me.
Do you really run LFOs higher than 2 kHz, or what...? If you really
want to, use audio ports for the control data instead.
Hey, this shouldn't be a problem, as all plugins with support for
both control streams and audio streams (ie fs and fs/8) *must* come in
a version with only a single sample rate for all ports.
Why? Well, think about what happens if you want to use audio
processing plugins to process control data, and those plugins have
fs/8 ports... ;-) (Ok, you could separate plugins in two or more
classes, but I think that's a very bad idea. Besides, control
rate-only plugins have to behave exactly like audio-only plugins
anyway, as they would otherwise be be messing with a timebase that's 8
times higher than the internal sample rate.)
//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:23:07 EET