Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Jim Peters (jim_AT_uazu.net)
Date: Sun May 13 2001 - 23:21:01 EEST
Tom Pincince wrote:
> While the buss model may or may not be the best for an all encompassing
> server, it is the most accurate model for representing the functionality
> of a physical mixer.
> :::
> The fact that paul realized that the buss
> architecture of the mixer can be opened up to be accessible to other
> apps should not be seen as a problem.
Sorry, yes. My problem with Paul's bus model, though, is that it
makes certain configurations hard to set up.
If you look at the typical model of a bus, there are three types of
items - the sources being fed to the bus, the bus itself, and the
destinations of the bus feed. In the AES model, the sources are
plugins that write to the bus, the bus itself is a buffer in memory,
and the destinations are other plugins reading from that buffer.
This is all fine. If you want to route a source to more than one bus,
this is easy on a mixer - just turn another knob or press another
button. However, in the AES model, this involves the source plugin
making another write call to another buffer.
So, in general, for a plugin to be usable in this bus-based system, it
needs to have the facility to write to one or more busses as
configured by the user.
This is a pain in the neck for a typical plugin, because it has no
interest in supporting multiple outputs - it's focus is on doing some
sound processing, not on managing routing. Really it would be best
for the plugin to just present its outputs, and let something else
take care of the routing for it.
As I mentioned in a later posting, and as you note yourself, this *is*
possible in a bus-based system, but only if we reserve a whole bus for
each plugin output that we might want to re-route.
At this point it's starting to look like we're bending the model to do
something it wasn't designed for.
Also, it seems to me that using a purely number-based system is not
good enough for LAAGA - it would be better if plugins and ports had
names so that they could be recognised and connected without always
having to check numbers back and forth. At the very least this would
allow something like `ardour' to give you a meaningful list when you
select inputs and outputs.
I know I have been suggesting the patchbay model, and I accept that
the physical version is limited to one-to-one connections. However,
the connection model I used in my little Perl script, and in my
`alternative' API spec allows any number of connections.
I recognise that even though this is flexible, there is still
something missing compared to the bus model. It's something like, if
you imagine the sources on the left, and the destinations on the
right, the connection model allows you to connect anything on the left
to anything on the right.
Connection model:
SOURCE-1> <1-DEST
SOURCE-2> (many straight line <2-DEST
SOURCE-3> connections between <3-DEST
SOURCE-4> ports) <4-DEST
SOURCE-5> <5-DEST
The bus model is different in that every transfer from left to right
*has* to go through a bus:
SOURCE-1> || <1-DEST
SOURCE-2> <BUS-1> <2-DEST
SOURCE-3> <BUS-2> <3-DEST
SOURCE-4> <BUS-3> <4-DEST
SOURCE-5> || <5-DEST
Now, we could emulate a bus in the connection model by having a `bus'
plugin that simply relays its inputs to its outputs. However, perhaps
it would be useful to have some kind of combined approach where busses
are supported by the server, but that you don't have to use them if
you don't want to:
SOURCE-1> <1-DEST
SOURCE-2> <BUS-1> <2-DEST
SOURCE-3> <BUS-2> <3-DEST
SOURCE-4> <BUS-3> <4-DEST
SOURCE-5> <5-DEST
This would allow direct connections from a source to a destination if
required, but would also allow connections via a bus if preferred.
Regarding implementation, taking my `alternative' proposal as a base,
we could have a built-in virtual plugin (i.e. that doesn't really
exist) called "BUS" which the server manages. So anything connected
to any named port on the "BUS" plugin creates a bus.
This would mean that to emulate the AES method of working using this
combined model would involve first creating your port:
add_port(handle, &floatpvar, 1, "1"); # Create output port "1"
And then connecting it to the target bus (assuming this plugin is
called "AAA"):
connect_port("AAA-1", "BUS-23");
Similarly for an input port:
add_port(handle, &floatpvar, 0, "3"); # Create input port "3"
connect_port("BUS-22", "AAA-3");
If nothing else is connected to/from these plugin ports, then the
server can optimise this down to exactly the same underlying buffers
as would be required for the bus model, so nothing is lost.
However, the difference is that some external connection manager (if
implemented and running) could choose to connect our AAA-1 output to
something else as well if it wished, which would not have been
possible in the bus model.
I hope this makes it clearer. Any thoughts on this ?
Thanks for getting the ball rolling again, by the way. I really
didn't know how to get the process unstuck. Cheers !
Jim
--
Jim Peters (_)/=\~/_(_) Uazú
(_) /=\ ~/_ (_)
jim@ (_) /=\ ~/_ (_) www.
uazu.net (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2b28 : Sun May 13 2001 - 23:36:34 EEST