Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Paul Davis (pbd_AT_Op.Net)
Date: Thu May 10 2001 - 03:59:09 EEST
>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.
You seem to think that plugins "reserve" channels in some kind of
exclusive sense. Thats not true.
We don't care how many plugins are using any channels (well, we need
to know, but we don't care ;) We don't care which plugins use which
channels. A single channel is an essentially infinite resource: as
many plugins can use it as you can imagine.
>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.
No, they save state. Ardour saves all state when you ask it to (and at
a few other times too); next time you start it up, it comes up with
the same connections as before. Simple, eh?
>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.
Damn right! I don't want *your* model of how to connect these things
interfering with *my* GUI design. Nothing personal there, Jim :)
> If plugins don't have
>names, then all the application can do is give a list of `in-use'
>channel numbers to choose from.
>- 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).
connection code is: request_channel (channel_id, dir);
now, that wasn't so hard, was it? :)
anything more than that, and you're firmly into internal application
design, and I don't want to go there.
>- It would be possible to load and save connection settings, so that
> you don't have to connect up things manually each time.
This is an internal application task, IMHO.
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.
Thats just part of the state of the application.
>- 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.
no single method will work for all applications. the system ardour
uses is tailor-made for its GUI metaphors (primarily the mixer
strip). the system quasimodo uses is built around its GUI metaphors
(primarily patch cords).
>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.
This is entirely what I intend. When I add a new device into my rack,
it has no useful default connections. Software lets me do one better:
the device can remember how it was connected so that when I "turn it
back on", it will be connected in the same way. But it connections are
to channels, not other applications, just like the connections in my
rack are to the sockets on my patch bay, not to other components.
You do have a patch bay, right ?
>- Duplication of GUI code for assigning channel numbers (code required
> for each separate plugin).
no duplication is likely, for reasons given above.
>- Temptation to hard-code channel numbers.
no way around this. if you run the application on an engine with 26
physical channels and 32 internal bus channels, then an application
using what it thinks is the 24th physical channel is out of luck when
run on engine with only 2 channels.
>- Fragility if number of physical inputs and outputs changes, because
> this means that all the internal busses will start at a different
> number.
No, they do not. To get internal bus #1, you use bus_id (1), and it
returns an encoded channel_id_t. Sorry, I've skipped over that
detail. You can determine channel type with channel_type(), but you
also need to use {hardware,bus,network,...}_id() to get the correct
channel_id when connecting. (if you have my code, see
a recent copy of quasimodo/libs/audioengine/audioengine/types.h)
>- 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.
the difference is that in this situation the mixing desk comes with
the possibility that it could have 26 channels in one "existence", and
2 in the next. if i start an engine using my trident card, i've got 2
channels in and out. applications using that engine will have to make
do with what they've got (and be written to expect this). if i run the
engine with my hammerfall, they'll have to make do with 26. there's no
way to predict how many physical connections the "mixing desk" will
have from run to run, since the audio h/w involved could be different
from run to run. am i missing something?
>> 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 ?
this is a detail. the server still loads a plugin, regardless of where
or how the request was delivered. it could be via a socket, via a UI
for the server ... at some point, dlopen() is going to get called, and
its the server who will do it.
as for the GUI thread issues, this is LADSPA GUI territory, and I want
to leave that alone for now. its a hugely problematic area. i've
alluded to some of the difficulties in a reply to Kai earlier today (EST).
--p
This archive was generated by hypermail 2b28 : Thu May 10 2001 - 04:29:51 EEST