Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Sun May 06 2001 - 16:37:27 EEST
Kai Vehmanen wrote:
> It doesn't make sense to demand that all LAAGA servers must use
> ardour's/gstreamer's/arts'/ecasond's internal signalflow structure.
> It's true that all servers must provide a solution to this, but
> doesn't affect the LAAGA API.
You say `servers' (plural) as if there might be more than one of them.
However, my impression was that there was going to be just one of
them, and that we (one way or another) were going to write it. I
thought the ambition was a bit bigger than creating another LADSPA.
Since there seems to be some difference of emphasis here, let me
describe the `plan' as I understand it (so far):
We are aiming to design and build a low-latency audio server using
everything that Paul has learned from writing AES and `ardour'.
This is going to be rock-solid through being tested to death and
will provide a foundation on which all kinds of other interesting
low-latency apps may be built without concerning themselves about
all the framework details. (It can also act as a common audio
communications exchange for other apps even if they do not wish to
provide plugins.)
This server will have some kind of port to which external
applications can connect to request that a plugin of theirs (fitting
our LAAGA plugin spec) be loaded up into this extreme low-latency
environment. The plugin will then set up its channels, shared
memory and other resources, and then be ready to run.
Connections between plugin ports might be setup either by the
plugins themselves, or through commands sent to the main server
port. Maybe we could allow an external patching app to ask to load
up a plugin which it can use to monitor and update the connections -
this keeps the patching UI independent from the server, allowing
anything from a command-line tool up to a fully visual patchbay or
flow graph to be developed independently.
The way you are talking, it is as if ecasound might host these
plugins, or that ardour might host them, or anything else that fancied
doing it. But this is going to get us in a mess. What if we want to
use two of these hosts together ? What if I want to record my
ecasound output to ardour ? The host itself needs to be independent
of any of the applications that use it in order to be the general
solution that I believe we are aiming at. It needs to be the neutral
centre-ground.
> Now the point is that the above design is very different from for
> instance Ardour's bus-concept. But the LAAGA API should handle both
> cases.
Oh dear. I've been checking back through the discussion, and I think
you have been thinking in terms of a LADSPA-like system with the host
controlling the connections, and Paul has been thinking in terms of
AES busses. For instance, you wrote in your spec:
int (*request_channel)(int direction);
void (*release_channel)(int direction, int channel);
and Paul wrote in his revised spec:
int request_channel (int direction, channel_id_t channel);
void release_channel (int direction, channel_id_t channel);
My impression is that in Paul's spec, the plugin requests a specific
channel number, and if that channel number is also used by another
plugin, then those two plugins are now connected !
If there really is this difference in approach, we do need to get this
sorted out. As I say, it affects everything all the way up to the
top-level user interface.
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Sun May 06 2001 - 17:02:52 EEST