Subject: Re: [linux-audio-dev] exploring LADSPA
From: Steve Harris (S.W.Harris_AT_ecs.soton.ac.uk)
Date: Thu Aug 14 2003 - 11:55:01 EEST
On Wed, Aug 13, 2003 at 08:09:19 -0400, Paul Davis wrote:
> >- Somewhat related to the item above, a plugin's run() method computes exactly
> >one sample at each call, not a block of samples. This is again a matter of
>
> perry cook's SDK does this too. everybody knows its cool, just as
> everybody knows its incredibly inefficient. you have 100% of the
> overhead of a chain of function calls for every sample. for anything
> except trivial processing, its too expensive to be useful for a
> general purpose API (for now).
So does sfront, SyncModular and and lots of hardware systems. You can do
it efficiently in software if you downcompile the modules to a processing
loop at runtime, c.f. the linuxsampler project.
The is an area where we can really beet the closed source guys as we have
no issues with giving away out DSP code.
> per-sample processing isn't a feasible option as a general API model
> for, oh, i'd guess at least another 3-4 years. and many operations
> that want to work in the frequency domain require blocks anyway, and
> so are not helped by this design.
NB nor by the current design of blocked systems, the FFT, WSOLA, etc.
requirements are a bit odd.
> >transparently, according to the port's configuration. I believe this
> >simplifies use of the system and eliminates the need for a special
> >runAdding() plugin method.
My suspicion is that runAdding et al is just unneccesary (c.f. cache
effects), but I haven't benchmarked it.
- Steve
This archive was generated by hypermail 2b28 : Thu Aug 14 2003 - 12:01:09 EEST