Re: [linux-audio-dev] LADSPA::runAdding()

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LADSPA::runAdding()
From: David Olofson (david_AT_gardena.net)
Date: Sun Apr 02 2000 - 00:54:26 EEST


On Sat, 01 Apr 2000, Juhana Sadeharju wrote:
> >From: Paul Barton-Davis <pbd_AT_Op.Net>
> >
> >Of course. Why on earth should it not be able to do this ? If its
> >called with runAdding(), it just does nothing; if called with run(),
> >it just writes zeroes. How else would a delay work ?
>
> In both cases there is a signal flow, right? What I asked can the plug-in
> output nothing at all, no signal flow. Imagine the next plug-in is
> a disk writer which writes anything it gets to disk.
>
> If we don't want the signal to disk, (i) the disk writer plug-in could
> forbit it, (ii) host could cut off the signal before it gets to disk writer,
> (iii) the first plug-in don't generate any output.
>
> Case (iii) is attractive because there would not be unnecessary signal
> streaming when nothing is written to disk. And the case (iii) cannot be
> done (but see my question above) with runAdding() or with run() as
> described above.
>
> Argh, lets forget this discussion if this is not going anywhere...

Well, there are a few not-so-obvious problems with ports that may
stop sending data. Even for MuCoS, I'm planning to leave this out.
(There are other ways to get the benefits without the nasty
sideeffects.)

First, you need an interface that allows a host to transmit
"nothing". Then you need to make sure that this special case is
handled by whatever is connected to such a port. This gets kind of
messy with optimized inner loops for multichannel plugins, but it can
be done, of course. What you *can't* get rid of is the complexity and
overhead of always checking if you're getting data or nothing on
every input port. The problem is that supporting this on every input
port is not optional.

My suggestion is to have a separate interface that allows plugins to
say when output ports are silent or active. Plugins are required to
always transmit valid buffers from normal stream ports (*) and they
can expect to always receive valid buffers on their inputs. Plugins
*may* send events indicating if there is data on output ports or not,
but this is only a recommendation. Plugins *may* understand these
events when they arrive on their input ports, in order to switch out
some heavy processing whenever possible. Hosts *may* intercept these
events in order to find and suspend plugins that effectively do
nothing. No special actions required, though.

(*) The style used by LADSPA for audio - variable rate streaming is
another matter, as it inherently supports silent ports.

This is possible to implement without an event system, of course.
However, if LADSPA is supposed to be anything like the Model 1 API I
described in an earlier post, I don't know if it belongs there. Will
people care to implement it in plugins and hosts, or will it just be
extra overhead instead of the intended CPU saver?

NOTE: It's not enough for heavy plugins to implement it on their
inputs - *all* other plugins have to provide this info on their
outputs as well. For the simplest plugins, the required checking may
mean considerable overhead in relation to the actual processing.

And remember; many of us are still using dedicated hardware for these
things, with no way to utilize unused DSP power for other things...
Having native plugins *at all* is a major improvement in this area
already.

Although the above is mainly about performance and saving some CPU
cycles, it also explains why it's not a very good idea to either
force all plugins to output port on/offf info, or if not requiring
it, to rely on that info for things like your disk writer plugin. The
disk writer has to check the signal by itself, or utilize a control
input that the user can hook to some suitable gate/trig output from
another plugin.

//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 -'


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun Apr 02 2000 - 02:17:20 EEST