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.