Subject: Re: [linux-audio-dev] LADSPA and run_adding()
From: Paul Sladen (paul_AT_sladen.org)
Date: Tue Nov 21 2000 - 01:39:36 EET
On Sat, 18 Nov 2000, Paul Barton-Davis wrote:
[various run_replacing() vs. run_adding() thing.]
> Given that one or the other is the best in some *common* situations
> (though I may agree with you that run_replacing() is more common that
> run_adding()), and given that there isn't very much work to be done in
> the plug to supply both, why not require it ? the argument is that the
> host can do it, but that is suboptimal because of the L1/L2 cache
> situation. the plugins get slightly larger, but the difference between
> run_replacing() and run_adding() is so small that almost anyone can
> code it.
Perhaps it would be to let the plugin decide.. "ah yes, BUT what happends
when you want to keep the original?". My current wondering, while
possible not compatable with LADSPA as it stands are along the lines of
the plugin "relocate" to another buffer if it thinks (or needs to work
with retaining the old buffer. Surely what it should returning is the
pointer to the data that it has finished processing. An equivent solution
is de-referencing the location in memory that get connected().
OK, so I admit that this is probably easier to visualise inside the
context of ideas I'm working on... the gist being that each plugin
(starting from the one connected to the audio _output_ connect on the
sound card) calls back-"down" the chain, eventually reaching the source of
the audio data (the sound card in, or a hdr). One by one, each plugin
processes the data, and simply returns to next one "up", till the
root-caller is hit.
Another item that is simply solved this way is deciding which
plugin/thread should be run as the SCHED_FIFO start point.. it's quite
simple, it's the one connect to the _output_ of the sound card... that one
just requests all the way up the chain, eventually reaching the sound card
input, or an hdr output etc...
Paul
-- e: paul_AT_sladen.org t: 0115 922 7162
This archive was generated by hypermail 2b28 : Tue Nov 21 2000 - 02:19:15 EET