Subject: Re: [linux-audio-dev] RE: Non-Sequential LADSPA Extension: experimental SDK
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Dec 20 2000 - 03:21:48 EET
>All the API extensions do is allow a plugin to select which bits of input
>audio it wants to work with as each output block is requested (i.e. allow
>the plugin to call seek() during a run call).
OK, so essentially, you're providing callbacks for the plugin to use
to retrieve specific audio data ?
> I Fade-in: first call, size 1000: how long is the input area?
>{length=23456} Don't both requesting special input audio behaviour, just
>use an ordinary audio input. Produce the output block from the input block
>while scaling 0 to 999/23456. Second call, size 1234: scale from 1000/23456
>to 2233/23456.
I don't want to belabor this, since you noted later that you basically
agreed plugins weren't the way to do this in a DAW like Ardour. But
just consider this: take a typical gain control curve. Every place
where the shape of the curve varies, you'd have to have a different
plugin or you'd have to reset the control parameters of the one
plugin. This implies that the execution of plugins now has to be
sensitive to position in the audio stream, which is not true for any
of other plugin that i can think of at this time. its true that once
there is a real automation system (one that includes plugin
parameters), something vaguely like this has to exist anyway, but i
still don't see using a plugin for the fades themselves.
> II Reverse: first call, size 1000: how long is the input area?
>{length=23456} Okay, to produce output values 0...999 we cannot use the
>corresponding sequential input audio which would start from 0. Instead the
>plugin requests (seek()s) input from 22456 in the input data, reverses the
>data and outputs. Second call, size 1234: same idea with some extra
>counters, request audio from 21222 to 22455. Incidentally, this plugin is
>an example in the experimental SDK.
i don't this that this will scale well in a multichannel system. there
is no caching of audio data beyond a short distance ahead of (and
behind) the current play position. you're essentially going to end up
reading the data twice. do this on several tracks at once, and you run
the risk of missing deadlines. there's another fundamental problem
that applies to this whole callback-for-audio-data method. to reduce
apparent latency, plugins are run from the audio thread. i originally
put them in the disk butler thread, but it was too horrible for words
- the disk butler is reading 1-2secs ahead of playback, and thus
modifying plugin parameters is distinctly "laggy". you *cannot* do
disk i/o within the audio thread, and ardour has no concept of
buffering data in a way that could guarantee that disk i/o was
unnecessary when this callback was made. this is particularly true for
reverse, but is applies to some extent even for varispeed.
the EDL approach i've designed for reverse will mark an entire
sub-sequence (list of pieces) as reversed, and will read them in the
correct way when retrieving data from the disk. that way, we only do
the i/o once, and in the disk thread.
> III Varispeed: some call, block size 1000, pitch 1.5 (relative freq
>uency,
>i.e. a just-intoned fifth up): ask for the chunk of input audio from where
>we were last time of size 1500 (poss. 1501 if petty). Interpolate or sample
>happily to produce an output block of 1000 samples. Yes, this does mean it
>becomes trivial to build real-time synths with multi-sample capabilities
>with LADSPA. If anyone has the GTK experience and time to help me with PNet
>please shout...
like reverse, there are both scaling problems and fundamental design
problems here. you are now talking about not only reading the data
twice from disk, but reading more in some tracks than in others. then
throw in the "this might cause disk i/o from the audio thread", and
all of a sudden, it seems dead in the water.
the EDL approach will attempt to deal with varispeed playback by using
an approach benno suggested: the audio thread will consume more data
from the ringbuffer that connects the audio and disk threads, and the
disk thread will do extra work to try to catch up as it refills the
buffer. of course, if the speed up is too great, or too many tracks
are doing it, its not going to work. there's a limit to the disk
throughput. this is not theoretically any different than the plugin
approach you describe, except that the plugin doesn't have anyway to
know that its exceeding the bounds of reasonableness :)
> IV Granular stuff: here the plugin can simply request access to an
>y input
>audio it likes and spatter it into the output buffer to hand. As the long
>as the input audio is in RAM this should run fine in real time.
and there we have the key problem: there is no reason to suppose that
its in RAM at all. the recordings i'm using as test cases for ardour
each weight in at between 1 and 8GB. needless to say, there is no way
in hell these are going to fit in RAM ...
--p
This archive was generated by hypermail 2b28 : Wed Dec 20 2000 - 03:50:04 EET