Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Jim Peters (jim_AT_aguazul.demon.co.uk)
Date: Thu May 10 2001 - 01:49:45 EEST
Paul Davis wrote:
> Well, apps don't cooperate by themselves. A user has specific desires
> about cooperation, and so they set up application X to share data with
> application Y by choosing to have X and Y use the same set of
> (internal bus) channels.
Although I agree with you, Paul, on the basic approach to all of this,
I have problems with your approach to connecting plugins together,
i.e. getting them to read/write the same channel numbers in the AES
model.
I'm guessing that you won't be happy with applications `reserving'
hard-coded channel numbers. I mean I could write my application to
always output to channels 110-113. That would be handy for me the
coder and me the user because I can easily remember these numbers.
This is a bit like TCP/IP port numbers being hard-coded for particalar
servers. Do we want this situation ? I'm guessing that you as a
server-writer wouldn't be so happy with this approach.
Instead, I'm guessing that you'd want applications to allocate the
next few free channel numbers. This means that these numbers could
potentially be different on each invocation. This means that every
time I start up my home `studio' I'd have to manually copy channel
numbers from one application to another in order to get them talking
to one another. This is a pain in the neck.
Not only that, but each application is going to have to provide their
own GUI for selecting input/output channel numbers, so this operation
is going to be different in each application. If plugins don't have
names, then all the application can do is give a list of `in-use'
channel numbers to choose from.
This seems to me like a huge duplication of effort in the coding of
applications for each of them to provide connection management, and
also a real pain in the neck for the user copying all these details
around. Maybe with some scripting it may be possible to coordinate
the startup of a group of applications and somehow transfer channel
numbers on from one to the next, but this is not a clean or elegant
solution - rather it is a hackish work-around.
My solution is for the plugin to have a name, and for it to give each
channel it allocates a name, and to use those names in some kind of a
central `patchbay' application which can be used to do the
connections. I know you are opposed to this, but it has these plus
points:
- Connection code doesn't have to be written into every single app -
they just launch themselves and leave it up to the connection
manager app to do the connecting (automatically or manually).
- It would be possible to load and save connection settings, so that
you don't have to connect up things manually each time. Also you
could set up default settings, so for instance your MP3 player is by
default connected up to a certain two output ports when it appears.
- Making the connection manager application independent from the
server (via a connection manager plugin API) allows other developers
to write their own, perhaps resulting in several to suit different
people's preferences.
Well, anyway, this is my solution. As I say, I see the following
problems with the current purely channel-number oriented approach:
- Need to manually copy channel numbers from app to app when several
are started up. No useful default behaviour possible.
- Duplication of GUI code for assigning channel numbers (code required
for each separate plugin).
- Temptation to hard-code channel numbers.
- Fragility if number of physical inputs and outputs changes, because
this means that all the internal busses will start at a different
number. This means that an `ardour' based setup will have all its
internal busses at different numbers, and any apps which are being
started with command-line arguments to target particular ardour
ports are going to suddenly stop working properly.
- This is a step back from almost everything else out there. Even in
a studio on a mixing desk, things are numbered, but the numbering is
stable and won't change from run to run. If it's unstable, then it
should be hidden away behind something that *is* stable, like names
or tags or something like that.
If my solution is no good, do you have any other ideas ? Or can you
answer my criticisms of your method ?
> the engine controls the ALSA PCM device. it loads the
> plugins for the HDR and the FX rack "applications". both plugins
> present a (G)UI for the user to set up their input and outputs.
I was seeing this the other way around - that the user would launch
the app (the GUI process), and then that would ask the server to load
its plugin. I'm uncertain about the opposite direction - would this
mean that the GUI would be a thread in the server ?
Jim
--
Jim Peters / __ | \ Aguazul
/ /| /| )| /| / )|| \
jim_AT_aguazul. \ (_|(_|(_|(_| )(_|I / www.aguazul.
demon.co.uk \ ._) _/ / demon.co.uk
This archive was generated by hypermail 2b28 : Thu May 24 2001 - 01:55:46 EEST