Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Jim Peters (jim_AT_uazu.net)
Date: Tue May 15 2001 - 13:25:08 EEST
Tom Pincince wrote:
> The name "mixer" means to combine multiple streams into one. Every
> place in a mixer that can combine 2 or more streams into 1 is a bus.
Thanks - going back to basics in this way is very helpful right at
this moment.
> The number of sub busses in an 8 buss mixer and the number of tracks in
> an 8 track recorder are equal precisely because they were designed to
> utilize the one-to-one capabilities of a bus.
Yes, I'd forgotten that. I was thinking in terms of Master-L-R, Aux
sends and so on, and forgetting the individual route-to-tape busses.
> I see why you resist busses. I also see that you view signal flow as a
> push process. I view audio as being pulled through the signal path (no
> ego). The difference may prove to be profound. In a pull model the
> plugin doesn't write to any busses, the plugin just presents its outputs
> and the busses read from the plugins. This is what you want.
Yes, I can go for that. I'm beginning to understand that my real
problem isn't with busses, but rather with the idea of the plugin
having to write directly to them. If the connections between the
plugins and the busses are independent of the plugins, then I can be
much more happy with the situation.
> Also since an audio bus is nothing more than a summing node, a
> many-to-one connection, a software implementation of an audio bus
> could be a list of the plugin outputs that it is to sum and the
> buffer that it is to write this sum to.
> ...
> I can imagine a server managing a bunch of summing nodes.
> ...
> So the server sees everything as a summing node reading from 0
> to N plugin or bus outputs
Yes, I think this is a very clear way to think about it. This means
that every bus or plugin input port has associated with it a list of
busses and plugin outputs which should be summed into it (with a
gain-level associated with each). In the server, each bus buffer or
plugin input port buffer is the actual place where all these signals
are added together.
As was noted earlier, the underlying optimisations can still be
applied whatever model we use to understand the connections, so there
is no loss of efficiency in using this model.
> and orders the execution list with busses last.
Busses won't necessarily be last, because other plugins may read from
them. But the run-list ordering issue has already been dealt with, so
no problem there.
> The issue of optimizing for both one-to-one and many-to-one vs. the
> simplicity of having only one kind of bus is something to be considered
> by those much wiser than myself. I just know that in the analog audio
> world busses that can read from many sources are also regularly used to
> create one-to-one connections.
Thanks, my perception of the issues has been changed. If plugins can
write their outputs to just one place, and then something else
(server, whatever) takes care of mixing all the various plugin outputs
into busses or plugin inputs, then I can see no more problems with a
bus-based approach.
> ...or maybe I should just go live in a yurt in the woods and play
> acoustic guitar :)
Well, strange you should mention it, because I'm off tomorrow on a
course for five days in the wilds of Cornwall, well out of the reach
of E-mail, but probably well within reach of acoustic guitar players
and yurt-dwellers ! A lot can happen in five days, both on a course,
and on this list - I'll be curious to see how things look in a few
days time.
Jim
--
Jim Peters (_)/=\~/_(_) Uazú
(_) /=\ ~/_ (_)
jim@ (_) /=\ ~/_ (_) www.
uazu.net (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
This archive was generated by hypermail 2b28 : Tue May 15 2001 - 13:39:37 EEST