Subject: Re: [linux-audio-dev] extending LADSPA, it's not that easy ......
From: David Olofson (david_AT_gardena.net)
Date: Sat Nov 04 2000 - 09:11:12 EET
On Fri, 27 Oct 2000, Benno Senoner wrote:
> On Fri, 27 Oct 2000, Tom Pincince wrote:
> >
> >
> > I woke up this morning thinking the same thing. This 128 step
> > resolution reveals itself sonically in many places. The solution that I
> > imagined was also for linear interpolation within each block. Thinking
> > as generically as possible I imagined two entry fields for each plugin
> > control parameter, one for the beginning of a block and one for the
> > end. If only one field was used there would be no interpolation. If
> > interpolation did not apply to a particular parameter then the second
> > entry field would be ignored.
>
> this works, but for the host app it would be easier to simply provide one
> control value which is then sloped using the one supplied previously,
> (which the plug remembers internally). But this has disadvantages too:
> to start with a value different from zero, when processing the first block,
> you have first to disable interpolation, set the blocksize to 1 and set the
> control value to the desired amount,
> So it's probably better to use your model ? thoughts ?
I don't think <start, end> control data seems very nice and handy to
use; implicitly using the new value written to the port as the end
value, and the current value (the resulting end value from the
previous buffer) seems more straightforward.
As for skipping to a new level without interpolation;
1) Is it legal to call run() with SampleCount == 0? (This
would obviously mean "Slide control levels to the values
written to the ports over 0 samples, processing 0 samples
of data.")
2) To avoid the special case checking required for the above
to work (you'd get div-by-zero without that!), how about a
new plugin call to force some or all control ports
directly to the new levels?
> > required me to do 50 or more of these microscopic fades per day. In
> > these situations the end points of the fade regions need to be defined
> > with single sample accuracy. Working with blocks of even 32 samples is
> > much to crude for this.
>
> Not sure if I misunderstood you, but I'd like to see the person which can
> distinguish between a fast pure exponential volume envelope, and the
> same made of linear segments with 32sample len.
> The ear can distinguish only very few volume levels , so as Olli would
> say the exponential aproximation would be "perceptually perfect".
However, when modulating amplitude this fast, you're working well
inside the audio frequency range, which means that the timbre of the
faded audio will be affected by the fade envelope. Not that it's a
huge difference between exponential and linear fade-outs (provided
the durations are adjusted to give the impression of the two variants
being equally long), but I wouldn't bet that no one could hear the
difference. Compare this to dynamics processing, or programming
percussion sounds on analog or virtual analog synths - envelopes
blend with the waveforms when they're this fast!
> But if you are paranoid, you can always use a gain plugin which takes
> (as Richard said) two audio streams as input: one for the audio data and
> the other for the volume control data.
> This way you can supply arbitrary volume curves.
> (the plug would be a bit slower due to a multiplication involved for each sample
> but that's not a problem for today's CPUs).
On the contrary, it would probably be *faster* to use audio data in
this simple example! :-) The plugin doesn't have to generate the
amplitude data; only apply it.
However, in the big picture, there will be more overhead and less
chances to optimize, as the control data has to be generated
somewhere else, and then passed through the network, possibly
processed by some other plugins, with all the memory and processing
overhead that involves.
> > Prior to following lad my mental image of digital audio was entirely
> > based on single sample frames, not blocks. Now that I am thinking in
> > blocks it is challenging to create a mental image that allows single
> > sample accuracy for anything, even though I use Digidesign software
> > every day that does so.
>
> The blocks can vary arbitrarily in its size (to suit your needs), the important
> thing is to avoid to use a blocksize of <20-30 all the time.
> eg. if you need to do precise cuts, fades etc, you can easily go down to 1sample
> blocks every now and then (let's say at the beginning and end of each
> segment of an EDL) since it will non add significant overhead to the whole
> thing.
Another way to see it:
Time Audio Control
------------------------
0 * +
1 *
2 *
3 *
4 * +
5 *
6 * +
7 *
8 *
9 *
10 *
11 * +
12 * +
13 *
14 *
That is, one audio sample for every sample frame, but control
"samples" only for sample frame 0, 4, 6, 11 and 12 in this example.
Note that the control timing *resolution* is one one audio sample,
whereas the average control *rate* is just a third of the audio
sample rate.
Now, instead of pasing the ranges 0..3, 4...5, 6..10 etc to the
plugin through separate calls with all the overhead and added host
complexity that brings;
Control
--------
<0, +>
<4, +>
<6, +>
<11, +>
<12, +>
Put this in a LISP style list, a simple linked list, a table (like VST
2.0), a FIFO/circular buffer or whatever. Then add an outer loop
around the DSP loop of the plugin. Set this loop up to check the
timestamp of the next event and process audio until the sample count
reaches that time, or until the entire buffer has been processed; then
process and remove the event, remove/skip it from/in the
list/table/FIFO, and loop.
If there are no events for the current frame, the plugin will behave
exactly like a LADSPA plugin. However, if there *are* events, these
will be processed exactly when intended, without returning to the
host for control port updates.
This scheme means slightly more overhead than raw, fixed rate control
streams in the special "full rate used on all control ports" case,
but significantly less in most other cases.
(Yeah, here we go again. I'm supposed to *code* this; not explain it.
Ok, I still get interesting ideas when trying to see and explain this
design in various perspectives, but that's not productive enough.)
//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:19:02 EET