Audio Engineering Society UK

Title: ‘Grand Designs – Networked DSP for Really Big Buildings’
Location: Royal Academy of Engineering, London
Description: Michael Page of Peavey Digital Research
Start Time: 18:30 for 19:00
Date: 14 July 2009

Download MP3 audio recording of this lecture (18MB)

Download PowerPoint slides of this lecture (6MB, MS PowerPoint 97-2003 compatible)

Abstract

Advances in audio distribution and control over digital networks have delivered tremendous benefits for operators of large venues and premises, such as theme parks, cruise ships, stadiums, live performance venues, airports and industrial complexes. Audio for entertainment attractions, background music, paging systems and evacuation purposes may all be transported and controlled on a single distributed system, via Ethernet and IP local area networks. Audio processing for acoustic correction, routing, mixing and other processes is all easily performed using programmable DSP, located both centrally and at distributed nodes. Michael Page of Peavey Digital Research will discuss and demonstrate the technology used to achieve this.

Meeting Report

Michael started his talk by listing the range of applications for the networked audio DSP systems he’d come to talk about: a diverse range including airports, stadiums, theme parks, ports, houses of worship, legislatures, and convention centres. Then, displaying an aerial view of the truly gigantic Hartsville-Jackson Atlanta Airport, he posed the question: what does it take to wire an airport for sound?

It sounded like a straightforward question, until Michael started discussing it. He started by talking about the audio system outputs: each boarding gate area (all 179 of them, at Atlanta) needs an individual output, each lounge, each concession, each arrivals hall zone, each check-in zone, each customs hall, each luggage reclaim zone… not to mention all the non-public areas. Each of these many hundreds of outputs needs, in addition to level control: EQ for loudspeaker correction, EQ for room correction, delay for time-alignment, possibly dynamic range processing, and possibly ambient level sensing. Ambient level sensing is a particularly complex DSP function: it uses a measurement microphone to detect the ambient level in a space, so that the level of the loudspeakers can be adjusted to ensure a consistent signal-to-ambient-noise ratio for the listeners. But if the audio system is active while this measurement is being made – as is often the case – sophisticated DSP is needed to “null-out” the contribution from the loudspeakers from the signal picked up by the microphone, in order to obtain an accurate measurement.

Next, Michael considered the inputs. Each boarding gate has a paging station, plus paging stations for every lounge, concourse and information desk, that may be routed to any system output. There may be background music inputs for lounges; automated message playback systems (“Please do not leave your bags unattended”, etc.); automatic announcements from the fire alarm system; and all these need to be prioritised, so that evacuation announcements aren’t blocked by the background music, for example. Each input typically needs EQ and dynamics processing, and needs to be routable or mixable to any combination of the several hundred outputs. So: we’ve got an audio system with several hundred inputs, several hundred outputs, all connected with a giant intelligent mixer, and a sizeable amount of DSP on every input and output. The inputs and outputs are distributed over six huge buildings, across a site a mile long and half a mile wide, and it has to integrate with the security, life safety, building management and enterprise management systems. Finally, it needs to be extremely robust and redundant, so that it keeps running even if the system sustains major component or infrastructure failures, perhaps caused by a large fire or a bomb explosion. Wiring this for sound isn’t as simple as first thought!

Michael next considered another application: stadiums need to get high-quality sound to every seat in the stadium, despite huge acoustic differences in the seat and loudspeaker placements. So each block of seats needs separate loudspeakers and processing – plus zones for all the internal areas: locker rooms, bars, restaurants, VIP areas, conference centres, car parks, atriums, etc. Stadiums don’t need as many inputs as an airport, but the ambient level processing is even more critical due to the difference in ambient level between sides of the stadium, at crucial points in events!

Finally, Michael discussed the requirements of theme parks. Audio-visual experience attractions such as “Terminator 2 3D” at Universal Studios are an obvious application: audio is a fundamental part of these attractions, and they require high-level, high-quality audio reproduction from a large number of independent channels to be precisely synchronised, sometimes interactively, with the motion control and video control systems that create the other dimensions of the visitor experience. Audio reproduction, even if it is only zone-specific background music, is usually present at pretty much every publically-accessible location in a theme park, and all public areas must have audio coverage for life safety announcements such as fire evacuation. As with airports, the wide range of different acoustic environments and geographic spread requires a large number of independently-addressable audio zones. The audio system inputs may be local, such as interactive audio playback within rides, or remote, such as background music, advertisements or paging announcements. Parade grounds and live shows complicate matters further, with many radio microphones and loudspeakers covering a very large area.

Now the problem is understood – how is it solved? Traditionally, it was analogue: large quantities of analogue multicore, thousands of crosspoints of punch-on patchbay, and many racks of analogue signal processing. It was difficult and expensive to engineer robust system redundancy, and very difficult to get computer-interfaced control of the audio signal processing. Each audio channel required a balanced line connection, requiring a huge quantity – and weight – of cable.

All this was revolutionised in the early 1990s by the arrival of DSP technology. DSP brought huge cost and functional benefits to the audio installation industry, for two principal reasons: it allows very simple interfacing of audio functionality to computer systems; and it permits arbitrary, heterogeneous arrangements of audio DSP functionality to be realised cost-effectively in generic hardware. The other crucial development from digital audio technology was digital audio networking, carrying many channels of uncompressed audio at low latencies on standard computer networking infrastructure. Analogue audio multicore cables were hugely expensive to buy, and even more expensive to install, whereas computer networking cables are flood-wired into all commercial and public buildings. So despite the relatively high transceiver costs, audio networking was a vastly cheaper way of getting audio around a commercial building. It also implicitly provided computer-controlled audio signal routing, saving the cost of expensive dedicated audio routers. The de-facto standard audio networking technology for the commercial installation industry has been CobraNet since the late 1990s, which is Ethernet-based (layer 2), has a latency of about 5 milliseconds, and convey up to 64 channels of audio in both directions.

To indicate the state of the art in audio networking, Michael spoke about a relatively new technology called Audinate Dante. It’s Internet Protocol based, typically runs over Gigabit Ethernet, and it’s scalable for both bandwidth and latency, making it very flexible for a wide range of applications. It may be configured for performance comparable to CobraNet, but in principle it can also function (with higher latency and lower bandwidth) over poorer-quality networks such as the public internet, or alternatively it can function as an ultra-low-latency, ultra-high-bandwidth point-to-point link between audio processors.

Michael then explained how these technologies are brought together. A system typically comprises some number of analogue audio i/o units, DSP units and control interfaces, connected by an Ethernet network for audio and control data, but these units may all be physically remote from each other. Control interfaces are used to communicate with user interface devices, uninterruptable power supplies, fire and life safety systems, building services management (HVAC) systems, show control systems, and many other possibilities.

This is a very successful technology area, with a number of companies actively competing. Peak Audio developed the first product of this kind in the early 1990s, the MediaMatrix system, which comprises a PC-AT motherboard with custom ISA backplane, DSP ISA cards with Motorola 56K DSPs, and analogue i/o boards. This was first used to provide an adaptive, distributed sound reinforcement system in the US Senate Chamber, which posed some unique challenges that could only be solved by computer-controlled DSP. The MediaMatrix product was licensed to Peavey, who manufactured and distributed it, and it was extremely successful.

The second generation MediaMatrix product was the Nion, launched in 2004. It has a PowerPC CPU running embedded Linux, for distributed control and communications with the other Nions on the network, and monitoring the DSPs and audio interfaces. It has a number of Analog Devices SHARC floating-point DSPs, a proprietary high-bandwidth low-latency audio link bus that uses Cat-5 cable to connect Nion units together, and a CobraNet interface module. CobraNet has such high bandwidths and low latencies that it needs dedicated data processing hardware: a generic CPU doesn’t have sufficient network performance. It also features a selection of “general purpose I/O” connections for control interfacing: logic i/o, relays, high-current outputs (for driving lamps, solenoids, etc.), control voltage inputs and outputs, and rotary encoder connections, for creating simple custom control panels.

Michael demonstrated of the NWare software, a Windows application used for defining the DSP and control functionality. It has a graphical user interface resembling a CAD drawing tool, allowing the user to drag-and-drop blocks representing DSP functions, audio i/o, control functions, control scripts, and many other functions. It also allows creation of custom control panels for PC-based or touch-screen user interfaces. When the design is complete, the “deploy” button is pressed to generate the DSP and control code, and download it to Nions connected on the network, which immediately take on the designed functionality.

The lecture was wrapped up with a look at the NWare system design for the MediaMatrix system at Emirates Stadium. As well as huge quantities of signal processing blocks, it featured touch-screen graphical user interfaces based on architectural plans of the stadium for ergonomic control and monitoring of audio across many different zones in the stadium at once. Custom support for communicating with UPS devices is implemented in the Python scripting language, which executes on the Nion. This vast system design gave a flavour of the tremendous complexity of the audio system implemented with MediaMatrix.

The NWare software can be downloaded for free from the downloads section on the MediaMatrix website.

Meeting report by Michael Page