Subject: Re: [linux-audio-dev] LADSPA and run_adding()
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Fri Nov 17 2000 - 23:11:43 EET
On Fri, 17 Nov 2000, Paul Barton-Davis wrote:
> i would really like to once again voice my opinion that run_adding()
> should be the default mode of operation for all LADSPA plugins.
--votes;
I'm still not convinced. I like to keep things simple. For me, LADSPA
plugins are loadable functions that process a given range of samples.
'run_adding()' goes further. It implies that plugins are signal
routers, etc ...
> extra cycles. providing an independent buffer for each plugin and then
> mixing them together at the end is the stuff of performance
> brickwalls.
Each plugin!? Uhm, now I am _really_ missing something essential. Ok, we
have a buffer, let's call it 'a'. If we want to to serial processing
(input -> plug1 -> plugN -> output), we do:
--cut--
- read_from_file(a)
- plug1.run_inplace(a)
- ...
- plugN.run_inplace(a)
- write_to_file(a)
==> 1 buffer, N plugins, 1 chain
--cut--
Ok, the other type of processing would be parallel processing - so we do:
--cut--
- read_from_file(a)
- b = clone(a)
- plugA1.run_inplace(a) ; plugB1.run_inplace(b)
- ...
- plugAN.run_inplace(a) ; plugBN.run_inplace(b)
- a = a / 2 + b / 2
- write_to_file(a)
==> 2 buffers, N + M plugins, 2 parallel chains
--cut--
And this design can be easily extended to more complicated setups.
> this is appearing of major significance is a large-scale multichannel
> system right now.
This sounds like marketing speak to me. ;) Linux is good for the small
firms, but for the really huge, large scale, bigger-than-life
organizations, you need big UNIX houses (or the even bigger: Microsoft
Datacenter!). Might be true, yes, but not much of an argument.
-- . http://www.eca.cx ... [ audio software for linux ] /\ . . http://www.eca.cx/sculpscape [ my armchair-tunes mp3/ra/wav ]
This archive was generated by hypermail 2b28 : Fri Nov 17 2000 - 23:40:59 EET