978 Chapter 25
DSP is concerned chemically indistinguishable. For
each mix group in turn the DSP addressing runs through
all the input data in turn, multiplying each by its appro-
priate gain coefficient. Automated addressing in the
DSP keeps track of which coefficient goes with what
sample. It is about as efficient a processing operation as
it can possibly be.
There are of course limits as to how many channels
and how many groups a single DSP can mix:
Crosspoints. Each channel-to-group calculation is a
crosspoint (from the concept of the mixer being a big
soft matrix). A 150 MHz DSP has a little over 3000
processing cycles at 48 kHz, but necessary program-
ming overhead precludes the use of all of these for
mixing. Around 2000 crosspoints is perhaps more real-
istic. So for 64 inputs, 32 output mixes per DSP is theo-
retically possible; 32 sources, 64 outputs; 128 sources,
16 outputs, and so forth. This elasticity has limits,
however, as follows:
Input Bounding. This is the limit on how many sets of
input data one can realistically capture and shovel down
into the DSP and still leave it with processing time to do
any mixing. Even DMAs have some time impact—in
general, DMA notwithstanding, the more time taken
dragging data around, the less time available for
processing. External memory fetches take time (access
to such memory is much slower than to internal
memory—hence the need to bring the data down from
the FPGA rather than access it directly for the mix).
Even though it is theoretically possible to spend an entire
sample period wheeling in new data in the background
for calculation in the next, data management can get
pretty hairy. In comparison the actual mixing is a doddle.
Output Bounding. This is less of a problem, since by
and large there are fewer of them. But expecting a large
number can lead to an issue of how to get all those
mixes back out into the world.
Since simplicity was a major aim of this particular
design, the outputs of the mixer stage are taken as six
pairs (twelve groups) from the DSPs in-built serial
interface; these group outputs are applied in the same
mix’n’match fashion as the inputs, directly to whatever
class of output device is necessary—D/As for analog
outputs, AES transmitters for digital, etc. Deriving more
outputs from the DSP involves getting those mixes back
up into the FPGA—again by DMA—and doing a
parallel-to-serial conversion of each there, in reverse
fashion to that done on the inputs to the mixer stage. By
such means, the modest processing power in this mixer
core can easily handle a 64-by-32 console. Here, the
twelve buses not coming directly serially out of the DSP
are done in this manner.
Increasing the number of mix buses yet further
would be achieved by using another FPGA/DSP core,
allowing a further thirty two mix buses. The second mix
stage’s FPGA is simply parallel-fed from exactly the
same thirty two data lines from the input channel
processing DSPs as the first mix stage.
The fact that the mix outputs are in serial native
format dramatically facilitates the dropping in of a
further DSP for post mix processing if required for
some applications–graphic EQs and group dynamics
sections, for example.
As can be seen from the diagramS and the descrip-
tion, the signal flow of this console is in such striking
accord with an analog implementation, one can rightly
wonder what all the fuss is about.
FPGA’s are becoming increasingly faster, more capa-
cious, and capable with the addition of on-chip RAM
and dedicated multipliers and such. A mixer of modest
proportions, such as this design, is implementable
directly into an FPGA alone with no need for the DSP.
Currently, it is a cost-benefit design exercise, deciding
whether a capable enough (and more expensive) FPGA
is worth it over the low-cost DSP and cheaper FPGA.
But the trend is clear.25.23.2.5 Universal Mix BusesThe described design provides a large number of raw
mixes, with no mix-specific hardware or code. It may
be noticed that apparently an otherwise vital subsystem
to the mixer appears to be missing—monitoring. Well,
actually it isn’t, and the fact that it is implicit in the
design as it stands points out an approach and attitude to
mix buses that would be hard to maintain in analog
where every bus is a significant expense: in digital,
buses come cheap.
Monitoring in this case commandeers a pair of mix
buses (assuming stereo); think PFL bus for now. Any
input to the mixer can be monitored on this bus by
applying an on coefficient to the appropriate crosspoints
to bring the source(s) onto the bus. So far so good. But
for monitoring output buses (stereo group, auxes, any of
them actually) rather than apply the analog solution of a
selector to switch between those existing groups, what
one can do is exactly recreate the mix to which one
wishes to listen; if one were to apply the same coeffi-
cient set that is making, say, auxiliary bus 5 to the moni-
toring bus, too, then one will exactly recreate what is
happening on aux bus 5 in the monitoring.