SVG Sit-Down: Calrec’s Dave Letson on the Arrival of IP Audio-Signal Transport
Standards and protocols, better control, more training are the main challenges
The transition to IP signal transport for broadcast audio is taking place surprisingly quickly, although not everyone on this field of play is necessarily ready for it. The alignment between industry technical standards and proprietary protocols, the increasing need for better network control, and the paucity of training are just a few of the challenges facing broadcasters as they go about implementing IP. SVG sat down with Calrec VP, Sales, Dave Letson to discuss these and other issues facing broadcasters transitioning to IP.
The shift to AoIP seems to have occurred rather quickly, although we know that AES67 and the SMPTE ST-2110 suite of standards were years in development. Looking back on recent history, what would you say have been the salient points of this transition?
From an audio perspective, AoIP has been happening slowly over a long number of years. Fifteen years ago, Calrec, like many companies, had proprietary-based audio-over-IP solutions. The drivers then are still very much the same: customers want to move away from expensive, point-to-point cable runs. The attractiveness is to have a network of different devices coexisting on a cheaper infrastructure that is flood-wired in the building and connected on commercial off-the-shelf switches. The advance of switch technology now allows for much more bandwidth, and it’s only in recent years that the broadcast industry has been able to move large numbers of HD video channels across an enterprise-level network.
What were the challenges in transitioning broadcast audio’s main product platforms — consoles and routing, in Calrec’s case — to AoIP, and what are the challenges still to be met?
The primary challenge has really been in aligning to standards. All those proprietary network systems had to move over to competing standards, and those had their uses and benefits. However, the relatively recent shift to SMPTE-2110 has started to move more towards interoperability.
The challenge now is to provide a level of control over all of these elemental audio, video, and data streams on a broadcast network. The NMOS-04 and NMOS-05 standards start to bring that much closer to reality. However, it is not yet fully adopted, and there is a lack of available stream-management tools. This was the primary reason Calrec created Calrec Connect, our own stream manager leveraging NMOS-IS04 and NMOS-IS05. This, however, is just the beginning. Broadcasters will demand truly interoperable systems that can provide deeper integration of device-level controls. I believe that is our next big challenge as an industry.
What’s the status of implementation for AoIP into remote-production vans? The leading providers of those environments have developed pilot examples for integrating AoIP into remote broadcast, but that’s a market sector historically slow to change (and for good reasons). What is the narrative for this?
I think it’s mostly the old adage that, if it’s not broken, why fix it. With the adoption of IP in an OB van, you gain the same benefits of a large broadcast facility. Everything is self-contained, on short cable runs within the truck. Then, there is the literally dirty side of life on an OB truck, like fault finding in the pouring rain at 10 p.m. on a Saturday evening. The maintenance and support tools just aren’t there yet. IP fault-finding is new to pretty much all of us. EICs on trucks need to get on with doing the job. The show must go on!
However, this is changing. Companies like NEP and Game Creek are migrating to products like Evertz EXE-VSR routers, not necessarily just because it’s IP but because they can no longer build systems large enough on baseband equipment and the prospect of deeper integration of control is also attractive.
How will AoIP impact deployment of at-home–production practices?
In the short term, not very much. AES67 isn’t really suited to WAN networks; companies will still want to use J2K codecs or products like Net Insight’s Nimbra, [which] allow all of the audio and video to be packaged together and sent back in sync. In the longer term, as the whole industry starts to understand how to work with SMPTE 2110 and AES67 networks, there will be a natural extension to move to WAN networks over longer distances.
Has development of training around AoIP in general and various specific AoIP-enabled products been keeping up with their implementation? For instance, in a related development, Dolby contracted with a for-profit technical academy to develop an online syllabus to provide instruction for its Atmos format. How is the broadcast-audio industry responding to the challenge of training?
Unfortunately, we don’t think there is enough IP training to keep up with implementation. There is a distinct lack of knowledge in the market today. However, this is a good thing, because the broadcast engineer’s skill set is expanding. There are many opportunities for experienced broadcast engineers to embark on training opportunities: for example, the Cisco CCNA training. This tests a candidate’s knowledge and skills required to install, operate, and troubleshoot a small to medium-size branch network and covers topics like routing and switching fundamentals, WAN technologies, determining IP routes, managing IP traffic with access lists, and establishing point-to-point connections.
Where does Networked Media Open Specifications (NMOS) fit into the AoIP narrative? Specifically, NMOS for Discovery and Registration (IS-04), Connection Management (IS-05), and Network Control (IS-06)? If discovery, registration, and network control are not part of the SMPTE standard, how will implementing NMOS later, after we’re well down the AoIP path via AES67 and ST-2110, affect its integration into products and platforms?
We view it as a complementary, parallel development. AES67/SMPTE 2110 deals solely with the transport of audio [data] over a network, and NMOS deals with control. IS-04 and IS05 allow for a standard to be adopted to make/break streams between AES67/SMPTE 2110 devices. This is an absolute must.