Subject: Re: [linux-audio-dev] LADSPA and spectral data
From: David Olofson (david_AT_gardena.net)
Date: to maalis 09 2000 - 21:33:46 EST
On Thu, 09 Mar 2000, maarten de boer wrote:
> What is the way to deal with plugins that need more
> input than they might get from the host per run call?
> For example the FFT, that needs binsize audio. The only
> way I see now, it that it will have to remember the data
> on it's input. This might not be very efficient. (The FFT
> is a bad example though, it will probably need to copy
> the data anyway, but you get the picture). A solution
> might be that the host *knows* how much data the plugin
> needs, and does the necessary buffering.
Yes, this is the only solution that works in a real time system, as
plugins requesting data could cause requests rippling through the
net, eating your CPU alive. (I once tried to design a system that was
based on that kind of behaviour, but realized it could become nothing
but a recursive callback nightmare... Or possibly a system stress
test. :-)
> A related problem: all connected plugins are run, but what
> if some plugin (like the FFT) does not modify it's output
> at the every run? The next plugin will run anyway, but
> uselessly or repeating with the same data. Maybe the
> plugin should set a flag ?
No active data flow control on this level, please... What you're
looking for is the kind of stuff that MuCoS is meant to handle. LADSPA
is meant to be simple and highly efficient. Possibly, MuCoS will
evolve into an optional extension of LADSPA, for more complex
plugins.
> Another situation:
> In setup like this:
>
> +------ binsize -------+
> | | |
> v v v
> +-----+ r +----+ r +-----+
> | |---->| |---->| | +---+
> --+->| FFT | | ?? | |IFFT |---->| |
> | | |---->| |---->| | | - |--->
> | +-----+ i +----+ i +-----+ +->| |
> | | +---+
> +----------------------------------+
>
> You want to substract the audio calculated by
> the IFFT from the original signal. Two problems:
> - the IFFT will generate it's output in binsize
> blocks, and not in the framesize. Unless, for example,
> the all plugins are indeed called everytime, but
> a flag is passed from [FFT] to [??] to [IFFT] to tell
> whether new data is available.
Another way is to tell the host that the FFT/IFFT plugins need to
work with a specific buffer size, so that there will be an implicit,
fixed relation between engine cycles and FFT/IFFT plugin calls. That
way, no other support from the API is really needed, but it does mean
that hosts have to be aware of the fact that there are plugins with
specific requirements/limitations to buffer size.
> - the data that goes through [FFT] [??] [IFFT] will have
> a delay in relation to the original signal. Who will take
> care of that? The host, but placing an delayline in the
> original signal? In that case, it will need to know the
> latency of each plugin.
It has to know that anyway in order to handle feedback, mixing signals
from parallel plugins, mixing processed + dry signals, and some other
stuff correctly.
> Or the plugin? In that case, all
> data should be timestamped.
This is the case with MuCoS events - but that's switching from
streamed data/signal to events, which is a quite different thing. I'm
not sure that's a correct way of doing it, as it forces your plugins
to hardsync event timestamps with the sample rate and FFT buffer
size. It would work, though...
> Maybe this goes beyond the scope of LADSPA, and is more
> of a OO DSP environment, but I'd say that it would be
> great if LADSPA would be able to deal with these things.
> And besides, this is just an example, I am sure the same
> or similiar situations will arise. Better to have them
> covered right away :-)
Not easy, and results in a more complex API and more overhead, so it
most probably won't be in the basic LADSPA spec. Adding an event
based API on top of it does mean things like this can be done in
quite a few ways, while hosts can still run pure LADSPA plugins.
//David
.- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
.- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> david_AT_linuxdj.com -'
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST