Handbook for Sound Engineers

Consoles 981

console is split, then a means of harvesting all the
metering data from the DSPs, squirting it all up to the
control surface, then disseminating it appropriately defi-
nitely has to be devised. This one sentence describes
something that has many, many times been hopelessly
underestimated, and at least in one case required a
whole separate Ethernet run back to the control surface
purely to handle metering.
In this design’s case, the host micro polls each of the
DSPs in turn, clocking back the metering information
from each through the return path of its SPI; a packet is
created of each complete console wide set, which is
then delivered back to the control surface.
The good news is that metering data is not needed at
anything like audio data sample rates. The feeds have
been prefiltered in the DSPs with appropriate time
constants and updating the relatively small data (8 bits
is plenty) relatively slowly (better than every 25 ms or
so) is adequate. Nevertheless, unless the polling by the
host is under rigorous and deterministic control and the
total bandwidth of even this fairly slow, small data set is
carefully considered, the metering can start to be a
major burden.

25.23.3.3 Host Microcontroller

This is usually a fairly fast and meaty micro, often of
the x86 persuasion or large 68000 family. In the case of
a self-contained console (control surface and signal
processing all being in the same box) this will in all
likelihood administer the control surface and displays in
addition to the relevant function here, which is riding
herd on the DSPs.
The host’s job is to turn control parameters (as
generated by the control surface) into coefficient sets
that the DSPs can understand to perform the effect of
those parameter changes. This would be by the coe-gen,
or coefficient generation, software (typically written in
C) and is equal in importance—a fact little appreci-
ated—to the actual DSP code the DSPs are running. It is
the coe-gen code that just as much determines how a
console runs, feels, and sounds—after all, the DSPs are
just doing what they’re told and running code sent to
them, by this host. By ways of example, the coe-gen
code looks up what mix DSP crosspoints need to be
modified to what coefficient values in response to a
given fader being moved to a certain level and to take
into account any mastering overlays, pseudo-VCA
subgroups, etc.: what coefficient values to create for a
parametric EQ section changed to differing parameters
of frequency, level, and Q. In addition to being a fraught
exercise in database management, there’s some pretty

good math in there too. (In DSP software design, one

strives to keep the actual DSP algorithms as straighfor-

ward [fast] as possible, leaving as much squirrely and

calculation-extensive stuff as possible to the coe-gen

code in the host.)

Since a major part of the thrust toward digital

consoles has been their promise of storage and recall,

statically (snapshot) or dynamically (as in real-time

automation), it is beholden to the host to manage the

data transfers involved. Everything that may need to be

stored is already in the host, but the software routines

and hardware to facilitate storage/recall need to be

present. A console can be quite self-contained in this

regard if the data set is relatively small; on-board flash

memory may suffice. Otherwise, whirling and whining

hard drives may well be necessary. In the event the

console is integrated reasonably closely with an audio

recorder, hard disk, or otherwise, the automation data

may get squirted onto that as a sideband.

In a split console (control surface is separate from

the guts), the host also has to manage intercommunica-

tion with the control surface; typically this is done with

an Ethernet variant, which demands the existence of a

TCP/IP stack for the communication protocol and hard-

ware to terminate the Ethernet.

25.24 Digital Audio Workstations (DAWs)

Fig. 25-151 shows the major (usually indivisible)

elements within a digital console system and their rela-

tion to each other.

User Surface. This has indication of control positions,

metering, and means of controlling the audio processing

and can range all the way from the sea-of-knobs

large-format console-style surface to graphics on a PC

screen with a mouse.

Surface Host. A micro to look at, make sense of the

controls, and drive the metering. This can vary from

being a small embedded micro to a large PC-like

processor, depending on the size of the surface and if it

is expected to do high-speed communication, should the

control surface be remote. It can also not exist, its none-

theless necessary functions being subsumed by a PC’s

CPU processor.

Processing Host. Takes care of looking at the data

being passed to it from the surface host, creating the

necessary coefficients for the audio processor, and also

looks at the various and many metering returns from the

audio processor, rendering them down into a form