Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 10 2001 - 06:40:03 EEST
>Perhaps I am missing something, but it is not clear in what order the
>plugins will read and write to the channels. For example, to record a
the LAAGA server will ensure this. its a simple sorting problem
(unless there are feedback loops, in which case the problem is not
solvable in a general sense).
>It seems much easier to remove the whole concept of physical channels and
>let the plugins simply request the number of channels that they want. The
I don't understand this. The whole point of something like LAAGA is to
present an abstraction actual physical channels and have that be
unified with the way that data sharing is done. Channels correspond to
resources: either physical i/o channels on an audio interface or some
memory where data can be read/written.
>want - it could even use the entirely passive model. Of course, what is
>left is basically LADSPA without the control ports. In fact, it strikes
>me that LAAGA could be scraped and a LADSPA host could be written that
>would handle everything that has been proposed here!
LADSPA doesn't work unless you require that the plugins write to some
intermediate buffer (they only have audio "ports" that they access as
regular memory). This might be OK for a LADSPA plugin - for
multichannel apps, you're forcing data copying on a large scale, which
is rather pointless and very inefficient.
I would note that this thought has crossed my mind too, but I think
that LADSPA is clearly built around the idea of a plugin that "does
one thing and does it well". LAAGA is designed entire applications,
and I think that the simplifications made for LADSPA are not so
appropriate here.
However, my feelings on this are evolving. There might some good
reasons to force the AES engine to use intermediate buffers, in which
case {read_to,write_from}_channel would be redundant, and we could use
the LADSPA audio port concept, and have the plugin just scribble on
memory. OTOH, this brings up the run/run_adding dichotomy that I
worked so hard to get away from ...
--p
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 07:03:38 EEST