Re: [linux-audio-dev] LAAGA - how are we doing ?

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Kai Vehmanen (kaiv_AT_wakkanet.fi)
Date: Sun May 06 2001 - 18:38:04 EEST


On Sun, 6 May 2001, Jim Peters wrote:

> 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

Yes, definititely multiple servers! I know having one server would resolve
many issues, but seriously, trying to get everyone to use one audio server
is just like trying to unite the Linux window manager scene (let's make
KDE, GNOME, flwm, fvwm, window maker, etc just widget plugins in our
universal window manager). The fact is that there are multiple audio
server-like solutions available, each with technical strengths and also
weaknesses, but more importantly, each with a dedicated userbase. I'm now
referring to aRts, esd, OSS, ALSA, gstreamer, and the various server-like
apps like Ardour, gdam, ecasound and others...

My opinion is that the only politically viable way to join our forces is
to allow the different frameworks to co-exist.

> 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):

Well, I was one of the people who fought hard for the S in LADSPA. And for
a reason. IMHO, without the few compromises we made, there wouldn't be as
many LASDPA hosts as we have today. I think the same thing applies to
LAAGA. We can achieve various things - the optimal performance,
flexibility, ease-of-use, etc, etc - but I'm mainly interested in making
it something that the community will accept.

> 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

It might be that AES will be the most robust LAAGA server. And that's not
a problem. But it should still be possible to add LAAGA hosting to other
frameworks. Let the results speak.

> 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.

Yep, fits my view.

> 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.

Ok, here's something I see differently. I'd like the LAAGA server be
responsible for the above functions. If should be possible to not allow
any kind of patching. This allows the implementation of really small LAAGA
hosts. For instance, installing many of the more complex audio packages is
not easy. I've had my share of troubles installing ardour, quasimodo,
arts, etc, etc ... others can probably say the same for ecasound. Now it
would be good if we had a very simple, C-only, no extra dependencies,
LAAGA server, so trying some simple LAAGA client wouldn't involve getting
these big packages installed and working.

> 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

No problem. Ecasound can implement both the server and the client API. It
should be even possible to run a ecasound plugin in a ecasound server.
Same applies to all possible LAAGA hosts. I don't see anything that
prevents this. After all, plugin is just a set of functions compiled
into a shared library.

> 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:

Yes, well if you look at ardour/aes sources, this becomes pretty
evident. But even though I want to go into slightly different direction, I
still don't want to drift too far from the current aes/ardour
implementation.

> 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 !

Well, the term 'connected' is dangerous here. In AES, the server is
relatively passive element. But the server still handles the processing
logic. AES main loop is basicly:

--cut from 'quasimodo/libs/audioengine/engine.cc' --
        for (node = plugins; node; ) {
                tmp = g_list_next (node);

                plugin = (AudioEnginePlugin *) node->data;

[ .. omitting plugin removal code .. ]
                
                plugin->process (nframes);

                node = tmp;
        }
--cut--

... this is called from the audio hardware driven
'MultiChannelDevice::io_loop ()' in
'quasimodo/libs/audioengine/alsa_device.cc'.

So the server just issues the process() callbacks. If two plugins are
assigned to the same bus channel, and they are added in the right order,
you could say they are in a sense connected (they process the same data).

> 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.

Well, I don't see this as such a big problem. It's just a question of
moving some of the functionality from plugins (ardour) to the server side
(aes). But of course, if Paul is against this change, well yes, then we
have a small-ish problem. ;)

-- 
 http://www.eca.cx
 Audio software for Linux!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sun May 06 2001 - 18:08:29 EEST