Subject: Buffer allocation (was Re: [linux-audio-dev] MuCoS, Glame, API Issues)
From: Jarno Seppanen (jams_AT_cs.tut.fi)
Date: to maalis 09 2000 - 06:32:47 EST
Richard Guenther <richi_AT_fs1.dekanat.physik.uni-tuebingen.de> writes:
> On Wed, 8 Mar 2000, Paul Barton-Davis wrote:
>
> > so that the host can improve cache performance by reusing data
> > buffers. if you leave buffer allocation to the plugins, the chances
> > are that you will trash the cache every time you call a new one. given
>
> How does host controlled allocation work, if you have sample generating
> plugins? How does host controlled allocation work, f.i. on a resample
> plugin? I dont see the point - if allocation is dedicated to the plugins
The buffer allocation is done based on the filter graph topology. A
conservative and easy-to-implement solution is to allocate a separate buffer
for every existing output port in the network.
The effective solution is to globally minimize the number of allocated
buffers. A bit of dataflow analysis is of course needed to implement this.
(Some) means for the minimization are
1) Allocate a single buffer for cascaded chains of plug-ins. Requires
in-place processing in plugins.
2) Re-use allocated buffers from upstream connections after the buffers are
not needed anymore. This will constraint the execution order of the
plugins.
3) Implement process_replacing() and process_adding() methods in plugins in
order to remove the need for "adder"-type plug-ins (and their buffers).
It doesn't matter whether a plug-in "produces" samples or "transforms" them or
whatever. Allocating buffers is a matter of making connections possible.
Sample rate changing plugins are not supported, as the ladspa system is (at
least the last time I checked) single-rate. But the above scheme is usable
with multirate networks as well.
> one can forward the buffer and do modifications in-place in every plugin,
> this is more cache friendly than for each plugin having a seperate buffer
> to read from and to write to. Well, I need to look at the code of the
In general I would think that it is wiser to put the flowgraph analysis
explicitly to the host instead of "embedding" it to the plugin API. Makes
it easier to change the analysis later.
-- -Jarno
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:05 EST