When considering what Digital Signal Processing, (DSP), to use in a particular system, there is a wide range of options available to select from. How to choose one and on what basis to make that selection comes from understanding the capabilities and performance of the offerings available. Of course price comes into play, now doesn’t it. In this article we will explore the basic types of DSP processing units that are available and what their strengths and weaknesses may be.

First off, just what is a DSP? Actually, a DSP is a specialized electronic chip, much like the processor in your computer, whose architecture is optimized to handle the rapid crunching of digitized signals such as video and audio. Actually they can process many other signal types but we’ll limit our discussion here to audio. An early DSP chip example out of a TEF20, a Motorola 56001 is shown on my jacket in Figure-1 (no, the jacket isn’t DSP powered). So basically we have this chip that excels in crunching the math (processing) that we’d like to impose on our digitized signal; I’ll discuss the conversion of the analog audio to digital a bit later.

The next thing we need is a means of programming that chip to do what we want. Enter the programmers. The DSP programmer is an individual that has training in creating the specialized programming, writing code as it is sometimes called, that controls what the DSP will do with the signals that are sent to it. There are two types of Code in the DSP world; the Machine Code (sometimes referred to as Low Level code) which runs the DSP and associated support hardware, and the High Level Code which has the user interface, either front panel controlled or on a host computer and is what the operator actually controls.

The Machine code runs the machine, such as the input, output hardware, I/O converters, DSP, memory and control interfaces. This code runs mostly in the background, as far as most of us are concerned. The machine code will manage the hardware and how it works within the actual equipment hardware, and is often referred to as Firmware. The firmware is specific to a particular make and model of DSP processor, and manufacturers will offer updates to this firmware from time to time. Updating of firmware needs to be done carefully and only by an experienced individual that is up to date on exactly how to do it. It is possible to completely lobotomize a piece of hardware by improperly loading firmware.

As previously mentioned, the DSP will impose specific mathematical operations on the digital signal and requires machine code to determine what this is to be. There is a module of programming, which may be incorporated as part of the high level code or as a utility used by the DSP engineers, that is called the compiler. This program takes the desired operations requested of it, (routing, processing and the like) from the high level code and creates the DSP specific machine code that will be loaded into the DSP. The amount of processing and routing that is possible to fit into a DSP is dependant on the size and speed of the DSP processor and is put into terms of MIPS, Megabit Instructions Per Second. Thus there is a finite amount of processing that the device is capable of.

One primary goal of DSP programmers is to squeeze as much code into the DSP as possible to maximize the capability of their product within the ability of the particular DSP they are using. Not all compilers are created equal. Compiler efficiency and design approach have very much to do with just how much you can stuff into a particular DSP unit. The nuts and bolts of how a particular compiler goes about what it is doing is way too much to go into for this article; suffice to say there are some very clever people working on these and how well they go about their task is important. Engineering decisions have to be balanced against DSP resource use, resultant signal latency and a host of other considerations.

The Input and Output or I/O interface is also to be considered. The DSP works on digital signals so first the analog signals must be converted into digital. The conversion of analog to digital is another very wide-reaching subject, so we’ll stick to the basics for this discussion. Basically the analog to digital A/D converters sample the incoming analog signal and assign a numeric value, a bit, to each of the samples that reflects the amplitude value of the analog signal. That numeric value or bit will typically be in 16 or 24 increments, for audio, and thus the amplitude resolution is determined by this number. In short, the number of bits relates to the dynamic range and signal to noise capability of the converter. If the sample rate is high enough, the string of digital values will follow what the analog signal was doing. For instance audio on CDs is sampled at 16bit/44.1KHz.

Ease up, I didn’t make the standard. It can be argued that 44.4KHz isn’t really high enough for live sound, so it is not uncommon to see processing units that use 48KHz and 96KHz. There are higher sample rates available but with bit rate and sample frequency there is a cost. Remember, a DSP has only so many bits it can handle at any given second, so if the flow of data is increased, the number and complexity of operations that can be imposed upon that data flow will be diminished. Simply put, a 96KHz signal is roughly twice the size of a 48KHz sampled signal and therefore would take twice the resources within the DSP. I’ll leave the argument of just how high the sample rate should be for another time. I will, however, comment that most of the DSP processing units offered today are 48KHz sample rate, and they sound pretty good. With higher throughput DSP units becoming available, it is reasonable to expect the higher sampling rate devices to become more prevalent as we progress.

Some DSP units also offer Digital inputs and outputs. These units take advantage of signals that are already converted to digital and allow the signal chain to remain digital throughout the process. Currently the most common digital I/O offerings are AES/EBU and CobraNet™. Of course all of the previous conditions as to sample and bit rate apply to the impact on the resources of the DSP processors; that is if the specific processor actually supports the given digital format.

Another aspect of DSP based processing systems vs. analog is the stability. Generally speaking, once programmed, a DSP unit will do exactly what it is supposed to do as long as it is functioning and it’s configuration is intact. They either work or they don’t. Not to say that DSP malfunctions don’t occur or that they are not capable of very alarming and stunningly spectacular failure modes (the industry has many stories of such) but when working, they tend to stay put and not drift with environmental changes.

TYPES OF DSP UNITS
There are two basic types of DSP processing units available on the market today. Those which are typically front panel controlled and offer a number of fixed or pre determined processing configurations, and those which have a completely, user defined, totally flexible processor configurations. The latter is often referred to as “drag-n-drop”. There are a great number of different manufacturers and models to choose from; we will be showing only a small number of the many units available in the market as an example of units typical of a given type.

In the front panel controlled genre (Figure-2 & 3) the user will have an offering of any number of inputs and outputs, usually not more than 4 inputs by 8 outputs, and typically will be given a menu of I/O processing configurations to select from. The parameters of the processing blocks will be adjustable from front panel controls and menu driven LCD screens and alternatively from a host computer running the application for that type of processor. Figure-4 shows a typical menu from which to select the available configuration that most meets the desired function. The arrangement of the processing is selected by the manufacturer and the DSP code compiled to fit specifically into their machine. Compiling for a specific DSP and with a set array of processing blocks can often yield greater efficiency in the DSP resources and allow the programmers to stuff more features into the hardware. The trade-off is flexibility, but if the users need is satisfied by the configurations and control offered; then this may be a good choice. The front panel controlled units are, typically, also capable of being controlled from a host computer. Figure-5 shows a typical way that multiple units may be controlled from a single remote host computer. Most front panel controls can also be password protected to limit access to the processors by unauthorized meddling or curious fingers. Additional system security is offered by saving the configuration and settings in a host computer. In the event some glassy eyed, slack jawed ear digger manages to completely scramble the unit, or in the event of a hardware failure, one needs only to connect the host computer and reload the configuration; a vary nice capability.

The drag-n-drop (or flexible architecture) units offer a whole range of increased abilities and flexibility. In these units the hardware has, basically, A/D and or D/A converters with a DSP, or often several DSPs, attached to it. The most common are units that have 4 to 8 inputs and 4 to 12 outputs. Some of these units have modular I/O and the user can select just how many of what type of inputs and outputs they need. See Figure-6 & 7.

There are also several offerings that are input and output only devices that allow for expansion of a system. Some of these have additional on board DSP and some do not. Most of the drag-n-drop units have digital links that allow for the interconnection of a number of units together. There are a number of intercommunications formats, some proprietary and specific to the particular manufacturer and some using a third party communications protocol; such as CobraNet™ (Figure-8). These links provide as few as 8 digital links to/from adjacent units, or as many as 36 links to/from. This allows for a system that acts as a single larger processing unit that is scalable in size and I/O capacity. These links vary in terms of box to box latency and channel count. In addition, most of these types of DSP units also offer control and triggering ports on them (Figure-9). These allow the user to have the DSP sense some external trigger or volume control and also to send a control signal out upon certain conditions within the unit. On the surface they are fairly unimpressive to look at, but don’t let that fool you; there is a lot going on under the hood.

The flexible architecture, drag-n-drop, units are completely dependant on a host computer to configure them; they have very few, if any, controls on them. The Host computer runs an application produced by the manufacturer that provides the user a means of instructing the DSP unit as what to be. This high level code or programming has the Graphical User Interface, GUI, and this is what the user will interact with to configure the DSP to their needs. Oh yeah, and this is where the offerings in this type of unit REALLY start to stand out.

Think of the unit as a blank sheet of drawing paper upon which you can select various hardware units and processing blocks from a menu to be placed on the sheet. (see Figure-10). Then you connect the blocks together, in a manner similar to a CAD program, which virtually wires them together as seen in Figure-11. Once completed, you instruct the user interface, high level code compiler, to compile what you have designed. This is where the differences in compilers really kicks in and the compiler sets off to create the DSP code that will allow the hardware to implement the processing you have designed in the GUI. POOF! You have a DSP unit that does what you want. SUPER!

OK, it isn’t exactly that easy but pretty close. The file that the user creates is generically called a View File. Each manufacturer has some catchy marketing name they call them, but view file is a common name for them. When creating your view file, most manufacturers provide some sort of meter or number that indicates the amount of the processing you have consumed out of the available resources. These are typically rated in percentile, and give you some idea of just where you stand during your development. It is not necessary to have the actual DSP unit connected and you can work offline. Some allow for the creation of super blocks that contain any number of processing blocks within. These allow for a more tidy appearance within the view file and to consolidate logical processing into a graphical grouping.

It doesn’t take long to realize that there are a mind-boggling number of combinations and routings that can be created in one of these flexible architecture units. When considered with the scaleable nature of the drag-n-drop systems very large and highly complex systems can be realized. The down side to the drag-n-drop systems is the learning curve required to place the processing objects, and interconnecting them in the view files. While most of the GUIs look similar there are major differences in the rules and operation of the programs. Just as an example, the process of drawing lines between processing blocks is complicated by the fact that some of the programs won’t let you draw lines with bends in them. This causes the operator to have to create ways to keep the view file from becoming a rat’s nest of lines over the processing blocks. On the up side they are scaleable, very flexible, reasonably cost effective and fairly tamper resistant; because a computer is required in order to talk to the units.

One thing, to be sure, is that the emergence of DSP processing has allowed the sound professional to implement considerably more sophisticated processing configurations than previously possible or practical, in a purely analog implementation. Even the fairly straight forward front panel controlled units replace better than a dozen individual pieces of equipment that would have been necessary to match the processing capability they possess.

Economics alone would have usually prevented designers from including all of the features common in a DSP unit in an analog implementation. Therefore we now routinely employ more complete processing in our projects and are able to achieve improved results than in the past. When you consider what the drag-n-drop systems are capable of, it is commonplace to employ processing configurations that you wouldn’t have even dared to think of 10 or so years ago.

Hey folks, DSP is our friend and it behooves us to learn how to determine what the appropriate application of the available technology is, to best meet the design challenges we encounter. DSP processing units give us a powerful tool in our arsenal to accomplish just that.