Subject: RE: Buffer allocation (was Re: [linux-audio-dev] MuCoS, Glame, API Issues)
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: to maalis 09 2000 - 08:46:55 EST
The idea is very much that the host can do this any damn way it likes. Some
systems may wish to use graphs, some may wish to have a single plugin
'insert point' or signal chain. Some may wish to use plugins in-place for
cache-hit simplicity, some may not because of forked routing issues or just
to keep things simple.
The idea is that the plugin API itself does NOT specify any of these
things, it just provides an interface so the host can tell the plugin to
read some floats from somewhere and write some more somewhere else.
There is no LADSPA host source code and never will be. Long live the LADSPA
host!
-- Richard
-----Original Message-----
From: Jarno Seppanen [SMTP:jams_AT_cs.tut.fi]
Sent: Thursday, March 09, 2000 11:33 AM
To: Richard Guenther
Cc: Paul Barton-Davis; linux-audio-dev_AT_ginette.musique.umontreal.ca
Subject: Buffer allocation (was Re: [linux-audio-dev] MuCoS, Glame, API
Issues)
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.
[...]
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:05 EST