Subject: Re: [linux-audio-dev] LAAGA - how are we doing ?
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Sun May 06 2001 - 22:58:28 EEST
Kai Vehmanen wrote:
> 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 ...
Oh no ... giving up so soon ! This project hardly exists for me if
we're not creating a server - *the* LAAGA server. If other people
want to copy it, well, fine. But why would they want to do *that* if
we get it right ?
The server is where it is happening for me, not the API. The same API
implemented badly could be a complete waste of time, tried once and
instantly forgotten by the majority of the Linux community. It's only
if the server is absolutely rock solid and up to the job that anyone
is going to take any notice at all. If it simply works without
problem, and makes things easy that didn't happen before, it will
surely catch on.
So long as Paul is also interested in creating an actual server, I'll
carry on. I guess you can protect the interests of other people who
might want to write their own servers, for whatever reason.
> 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...
Yeah, we're trying to give the user some way to run all these on the
same machine at the same time. That's what I thought we were doing.
> Well, I was one of the people who fought hard for the S in LADSPA
> ... I'm mainly interested in making it something that the community
> will accept.
Me too. And I don't want any surplus complexity either. I like jobs
that are nice and self-contained, and don't stretch out far into
distant future. This means getting as much right as possible first
time, with a good design.
> 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.
I don't want to dilute the power of what we're attempting here too
much by trying to cater for too many varied hosts. For example Paul
wants SMPTE time-code in there, which has very interesting
possibilities. Would you have us take this out because it may be too
hard for some frameworks ? This kind of thing is what might help us
bring things together. Dilute it too much, we lose everything. In
fact, dilute it too much, and things like `ardour' won't even be able
to run on it, and we're back where we started.
It seems to me that LADSPA was designed to be easy to implement from
both sides - the server and the client. My feeling is to make LAAGA a
bit more unbalanced - to put more effort into the server in order to
make it easier for clients, on the basis that many more clients will
be written than servers.
> > 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
>
> Ok, here's something I see differently. I'd like the LAAGA server be
> responsible for the above functions. ... 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.
My idea is a small C-coded server, which comes with a simple
command-line or text-mode tool for adjusting the connections between
plugins. A server interface would be there to allow a big fancy
connection-manager to control the server, but this fancy GUI thingy
wouldn't be part of the core server distribution in my view. There
should be no dependencies on any GUI stuff at all.
> > 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.
They're either connected or they're not.
> 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 one's reading and the other is writing, then they're passing data
from one to the other, which is what I meant by a `connection'.
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 - 23:20:41 EEST