Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [alsa-devel] Re: [linux-audio-dev] laaga, round 2
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Tue May 15 2001 - 03:02:04 EEST


OK, either this is getting fun...

Abramo, Paul, and Steve are doing computer science experiments and the
rest of us are building audio abstraction models (or logos). Pass the
glue please.

Since busses have captured the attention of many, I will combine the
various questions and observations into a single message. There are two
ideas that I feel are important:
1) An audio bus is a summing node, nothing more, nothing less.
2) Audio apps don't have egos. This suggests that it helps to visualize
audio as being pulled instead of being pushed.

> > I guess I am a bit confused about the discussion of bus models.
> > Someone please fill me in :) I own a Mackie CFX12 which has only 4
> > buses. Now, if I am not mistaken, the buses are what I can assign
> > channels of the mixer to, and then the buses can be assigned to the
> > master output. Now what I do not understand is how this would not be
> > complimented with a 'patchbay' type approach. For instance, each
> > channel has inserts pre or post, and all items can be sent to the two
> > effects channels. However, if I wanted to string a bunch of effects
> > units together, I would have to do it seperately from the mixer.
>
> At the moment, I don't think we're actually discussing interfaces yet. The
> buss vs. patchbay discussion involves the actually implementation of
> routing in the server. Interfaces would be left up to the individual
> applications that use the server. At least, that's my understanding.
> (Correct?)

That's my understanding too.

> I'm not familiar with the CFX12, but as per my understanding,
> when people talk about a "four buss mixer", they are talking about the mix
> busses. That it, you have four busses at mixdown that you can route audio
> to. However, most boards have more actual busses than that. Your aux
> sends are busses too, so if you have 4 aux sends and four mix busses, then
> that's 8 busses. The you have the stereo buss, which has two channels, so
> that brings your total to ten. At least, that's my understanding.

Right. Every place in a mixer that can combine 2 or more streams into 1
is a bus. So the main left output gets its signal from the main left
bus, each aux send gets its signal from its aux bus, solo is a bus,
solo-in-place is two busses, etc… The name "mixer" means to combine
multiple streams into one. All *mixing* occurs in the summing
amplifiers on the individual busses.

So what about patchbays? In the analog world they have two main
functions.
1) Ideally a mixer would have enough aux sends, returns, channel strips
and sub busses to accommodate every possible one-to-one, one-to-many,
and many-to-one connections between all pieces of gear without ever
needing to change physical connections. Patchbays provide additional
routing options for large setups where the mixer has an insufficient
number of aux sends and sub busses.
2) They provide a routing option that does not force the signal to pass
through a summing op-amp, avoiding its distortion and noise
contributions.

In a digital environment, a unity gain summing node adds no artifacts to
a one-to-one or one-to-many connection, and a maximum of 0.5 lsb
rounding error to a many-to-one connection. If the digital environment
is inside a computer, then any number of aux sends and sub busses can be
created to accommodate all desired routing, limited only by computing
power. So an "all bus" model can do everything that a "buss + patchbay"
model can do while eliminating the need for the server to define and
manage more than one kind of connection.

> 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.

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.

The output of each sub bus is patched into one input channel of the
recorder. Each channel strip can send to each bus independently. If
one wants to record four vocal takes of a song back to back, assign the
vocal mic's channel strip to sub 1/2, record enable track 1 for take 1,
track 2 for take 2, then assign the channel strip to bus 3/4, record
enable track 3 for take 3, and track 4 for take 4. No rewiring
necessary. So using a bus for a one-to-one connection between a mixer
and a recorder is a common practice.

OK, so now let's move away from discussing just audio busses, which I
understand well, and look at how they would be used by a server, which I
don't understand nearly as well!

> 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.

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.

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. You describe a bus as something that is
written to by multiple plugins and read from, and I agree that this
would not be appealing. I was reviewing your proposal (which I was
easily able to find thanks to Kai's LAAGA site. Thanks Kai) and I
noticed your analysis of run() vs. run_adding(). I was impressed by the
similarity between your description of run_adding() and my description
of a bus as a list of plugin outputs to be summed to a buffer. What
does this mean? Don't ask me, I am not a programmer. However, I can
imagine a server managing a bunch of summing nodes. I can imagine each
plugin being a summing node (list+buffer) plus other processes, and the
busses being summing nodes (list+buffer) without any other processes.
So the server sees everything as a summing node reading from 0 to N
plugin or bus outputs, and orders the execution list with busses last.
The primary activity is reading followed by processing, not writing to
plugins or busses.

> I've been thinking some more on this since my posting last night. It
> seems to me that in Paul's model, the plugin itself has to do the job
> of the mixer

Paul's plugin is a mixer :)

>- i.e. the plugin must supply one or several feeds,
>ideally all at independent gain-levels,

The independent gain levels have been conspicuously missing from paul's
description, and I planned to bring it up, but he seems to have plenty
of things to do right now.

>to one or more busses.

I don't know pauls bus details, but in my model each send is written
once and it is the job of each associated buss to read from it.

>It's
>like the plugin is taking the place of not only the device generating
>the sound, but also the whole mixer strip that that device is plugged
>into (on a mixing desk).

The sound generator and the channel strip are two separate plugins. The
channel strip reads from the bus that reads from the generator's output
buffer.

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.

...or maybe I should just go live in a yurt in the woods and play
acoustic guitar :)

Tom


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue May 15 2001 - 03:22:32 EEST