Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Tue May 15 2001 - 16:15:03 EEST
[ re: push/pull, run/run_adding/replace, etc. ]
Let us learn from history here. I think it is extremely, incredibly
desirable to remove these concepts from a design that is oriented
toward connecting entire applications. It has been bad enough
supporting the run/run_adding issue just in LADSPA, which supports
"mere" DSP algorithms. It will be much harder to support these kinds
of things when an application is itself hosting LADSPA or VST or XMMS
or other plugins, contains dozens of its own internal objects, etc.
Whether we retain busses or not, I propose the following: unlike the
context switch costs that we've been discussing, the cost of zeroing
memory goes down more or less linearly with processor speed (helped
along by RAM speed, which is increasing much more slowly). Because of
this, we should consider the cost to zero a buffer to be an
essentially vanishing item in the overall operation of an audio
system. Because of this, all output memory buffers should be used as
"busses" - they are, as tom put it, "summing nodes". All operations to
store data in them should use "+=", and not "=". The host will provide
buffers, and will ensure that they are zeroed when appropriate.
>And remember we have *three* plugin destination variants:
>- in place
>- add
>- replace
>
>IMO plugins need to publish their capability mask and an info about if
>they allow or not parallelization (i.e. if they have some kind of stored
>status).
I do not want to discuss parrallelization at this time. It is MUCH
more complex than anything else we have attempted to handle so far,
and I do not want it be part of an initial inter-application glue. It
puts a lot more responsibility and constraints on a "server/host"
application, and at the present time, its not useful. I am quite
willing to keep an eye on the issue for future extensions, but I
honestly and deeply feel that its inappropriate at this time.
--p
This archive was generated by hypermail 2b28 : Tue May 15 2001 - 16:42:44 EEST