The Devil In The DSP

Digital signal processing (DSP) devices impact system design, installation, and operation in a variety of ways, and it's time to fight the demons that followed them into pro AV. 6/29/2006 5:59 AM Eastern

The Devil In The DSP

Digital signal processing (DSP) devices impact system design, installation, and operation in a variety of ways, and it's time to fight the demons that followed them into pro AV.

THE AGE of digital audio and video started with an impact on media, and then moved on to change how we transport signals from place to place. As DSP and networking crept into pro AV, the AV design and integration process itself was affected.

In the analog days, entire systems would be laid out in CAD and on paper, down to every equalizer, compressor, distribution amplifier, matrix mixer, and switcher. We were designing systems as we should. And once the systems were installed, all of the components and their interconnection were documented in the as-built documents.

This worked well until the digital demons started to prey upon us.

Signs of deferred design

First, digital signal paths snuck into our AV systems design. Initially, it wasn't hard to deal with. We used some different cable here, a few interfaces there, and thought the digital age was no problem at all. It didn't affect our design and integration process — just some of the details of the system. We still had to design the entire system to create a complete design package, and complete as-builts at the end of the job that documented everything in detail.

It was control systems that were the first digital systems to give us a glimpse of the problems to come. User interfaces weren't being developed during the design phase, and programmers — who weren't interface designers — were putting together user interfaces at the end of the project without sufficient information to do so, and without user contact.

Problems resulted, and the mischievous sprite of deferred design was born. This demon visits when any crucial AV component or subsystem isn't designed when it should have been by those qualified to design it.

Once digital signal processing (DSP) came into our world, the demon grew. The nature of DSP (and one of its benefits) is that most of the time, fewer hardware components are needed to create a fully functional AV system for a given set of user needs. Drawing up the hardware configuration for the system became easier because there were fewer components to draw. Or were there?

Many designers — both consultants and integrators — have been tempted by the DSP demon, and have fallen. Many designs are produced that stop at the hardware box and don't follow through to the virtual devices inside the DSP. When this happens, how should the system be bid when what happens inside the DSP box isn't defined? Who programs the DSP? The integrator's project manager? The field guy? The consultant?

Additional challenges

Once the DSP portion of a system is designed and installed (uploaded, that is), hopefully it's to the client's satisfaction. But then what? How is the DSP part of the system documented? It isn't as clear as it was in the all-analog days. Today, DSP interfaces fall along a spectrum of approaches. Some interfaces are more documentation-friendly than others, but none really measures up to a good-old-fashioned detailed block diagram for “easy-to-use” system documentation.

At one end of the spectrum are the fully configurable DSP systems that allow us to draw a block diagram in software that looks like it would on paper. At least with these devices screen captures are a minimum solution for offline documentation, and print commands can print an entire block diagram that doesn't fit on the screen. However, large and complex DSP designs may not be suitable for typical print options. To be readable, some complex systems may require multiple pages with interconnection references, just like a traditional CAD design would. Another problem is that what's inside the boxes on the DSP block diagram can contain important system information such as matrix routing and crosspoint gain values, not to mention entire subsystems that may be encased in a simple box on the DSP screen.

1 2 Next

The Devil In The DSP

Digital signal processing (DSP) devices impact system design, installation, and operation in a variety of ways, and it's time to fight the demons that followed them into pro AV.

On the other end of the spectrum are the matrix and tab interfaces that require multiple screens that aren't simultaneously viewable to understand how the system is configured. While these devices may be just as capable as those based on the block diagram approach, they're more difficult to learn and document offline. With the block diagram approach, at least there's a chance that someone who isn't trained in the particular DSP software can figure out what the system is doing or could do.

Demons, design, and documentation

But the demon is here to stay, at least for now. Deferred design and deficient documentation are its primary manifestations. The first issue is purely a design phase problem, although the impact appears mostly during installation. The second concept affects design and installation, including people on both sides of AV contracts — AV providers and system owners. And these are just part of the overall impact of digital AV signals, DSP, and data networking on pro AV in recent years. So what are the solutions?

To address deferred design, designers need to understand that system design encompasses the whole system. Virtual devices inside a DSP box need to be designed just as much as the hardware boxes outside it. The simple solution? Develop a complete system design — both inside and outside DSP devices — during the design phase. But it isn't necessarily that simple. We have three options, each with its own issues in today's industry: 1) Create the DSP design in the preferred (or sole source) DSP software for a given device; 2) Draw an analog block diagram representing the signal flow inside the DSP box; or 3) Provide a detailed functional description of what the insides of the DSP box should do. In any case, it's important to address virtual devices during the design phase, rather than at system checkout.

When the project is finished, we need documents — electronic or paper — that provide a technical view of the DSP part of the system that allows for navigation, troubleshooting, and understanding of the installed system — at least as easily as the analog as-builts do. And I don't think I'm just being an old fogey here. I've tried to troubleshoot and operate systems that include very challenging DSP user interfaces. Sure, with sufficient training and experience on the particular DSP device, I can design, navigate, and set up a system offline. But even with experience and training, most DSP devices aren't conducive to complex event planning that may require system reconfiguration or real-time event troubleshooting and system adjustments.

Maybe it's a pipedream, but what if DSP devices — regardless of their built-in user interface —included an option to output documentation in a common, perhaps graphical, format? Maybe it could be a representation of the “analog equivalent.” Maybe it would even allow programming to be translated from one manufacturer's device to another. That would be a start. This kind of documentation would be invaluable in navigating and troubleshooting a complex system, especially during an event when time is short and pressure is high. Screen shots and text file output don't do the trick. Manufacturers: Are you listening?

Ultimately we have to learn to live with and embrace digital technology in all of its forms and its impact on pro AV design and installation. I'm sure it will mean that we have to learn and adapt. But we need to keep good design and integration in mind during the transition, and fight off the demons that are giving us the devil.


To comment on this article, email the Pro AV editorial staff at

Tim Cape is a contributing editor for Pro AV, the principal consultant for Atlanta-based technology consulting firm Technitect LLC, and co-author of “AV Best Practices,” published by InfoComm International. He's the current chairman of InfoComm's ICAT consultant's council, and an instructor and presenter in AV technology design and management. Contact him at

Want to read more stories like this?
Get our Free Newsletter Here!
Past Issues
September 2015

August 2015

July 2015

June 2015

May 2015

April 2015

March 2015

February 2015