Islands in the stream: The art of constructing an audio over IP network on the go
In last month’s SVG Europe Audio Summit there was a lot of talk about IP which went way beyond what it promises to deliver and how it can enable broadcasters to be more maneuverable and efficient.
We have all moved on; IP is already delivering, and multiple broadcasters took to the stage to illustrate how IP is delivering the goods for them. But the road is not an easy one, and NEP’s deputy head of sound, Neville Hooper, was very clear when he said that SMPTE 2110 networks cannot be deployed overnight.
“They require time to plan, build and produce before those infrastructures work at all,” he said. ”Network designers need to ensure they are using the right tools for each application. Planning is paramount.”
“There is no one-size-fits-all approach and every system has to be built around what the client is trying to achieve. Although more vendors are designing equipment that is IP compliant, it still takes time for manufacturers to actually implement them; R&D roadmaps do slip and they all work at a different pace”
That comes as no surprise to broadcast systems engineer, Chris Goddard. Goddard has been designing broadcast IP networks since before there was a SMPTE standard to adhere to, including the UK’s first ever IP outside broadcast trucks (for Arena) back in 2016. Specialising in audio, he started his career at SSL in the 1990’s and has helped build over 40 OB trucks, designed Timeline TV’s remote production flypack pods for Formula E, and played a key part in BT Sport’s IP transition project in Stratford.
He knows better than most that SMPTE 2110 (ST2110) networks do indeed require time to plan. Lots of time, in fact; the BT project alone, which saw the broadcaster replace 25% of its network with IP, took over two years to complete.
It also means he is very well placed to identify where some of those planning challenges exist for anyone thinking of making the switch.
Islands in the stream
“Clients usually know what they want, but there is a huge amount of detail involved to get there, and understanding the system from a technology point of view, documenting everything, and implementing processes are all things that my brain likes to do!” says Goddard.
“I have been exposed to IP networks from quite early on; I started working on the first IP outside broadcast trucks before ST2110 was even a ratified standard. Arena’s OB X, OB Y, and OB Z were designed from the ground up to be IP, but when we started building them, manufacturers weren’t necessarily able to supply compliant equipment, and not all equipment was even IP capable.”
And herein lies the rub. It is not just that not all equipment is not yet IP compliant, or that different manufacturers are at various stages in their own IP journeys, or even that there are different interpretations of those same IP standards. It is all of the above.
“Designing an IP network can be like building islands,” says Goddard. “For example, an element of the audio might be best served by using Dante, because of available products, but the main transport is via ST2110. At some point these two domains have to come together, usually by bridging them using a non-IP method such as through an audio console.
“There is no one-size-fits-all approach and every system has to be built around what the client is trying to achieve. Although more vendors are designing equipment that is IP compliant, it still takes time for manufacturers to actually implement them; R&D roadmaps do slip and they all work at a different pace.”
It is no wonder manufacturers have a tough time keeping up, as IP standards and recommendations are also developing at pace to provide solutions to new use cases and they too develop at a different rate to how fast manufacturers can implement them.
“IP isn’t purely about audio; moving media around a broadcast system includes audio, video, metadata, control, etc. Managing this when your system consists of equipment from different manufacturers can be challenging”
AMWA’s suite of NMOS recommendations are a good example of this. While NMOS-04 and NMOS-05 are well established for discovery and management, recommendations like NMOS-08 provides solutions to enable IP networks to match tried and tested SDI workflows like audio channel mapping. Without it, we are back to using bridges to external devices like Grass Valley’s Audio Live to link those islands.
Because recommendations like NMOS-08 have not hit a point where many manufacturers are designing it in, Goddard says the knock on can be significant.
“Over the two years it took to plan, design and implement the BT Sport transition project, equipment specifications were constantly changing because different manufacturers were at different stages of development, and all that has a big effect on interoperability.
“Not only that, but manufacturers also interpret standards differently, again impacting interoperability. Some audio equipment might only be capable of 16 channel packet encapsulation, others 64. They’re both correct and conformant, but one can’t interpret the packets from the other. Some interesting discussions were had to convince implementation details to be changed. All this takes time.”
Moving targets and difficult transitions
Collectively, these reasons make everything within the transition to IP a moving target. If certain equipment is not interoperable, it complicates IP transitions by demanding more bridging between IP and legacy environments, and grafting these workflows into an existing 24/7 environment is even more troublesome, especially when it comes to infrastructure.
The SMPTE 2022-7 standard (a precursor to ST2110 but adopted by ST2110) is a case in point, providing broadcast networks with ‘hitless redundancy’, a system which uses dual paths (red and blue) to connect all edge devices on the network. It means every device generates data on both the red and the blue path at the same time, enabling the receiving device to take packets from either.
It provides fabulous physical IP redundancy. But it’s not an easy installation, and it’s another thing to consider when designing IP networks.
Goddard comments: “BT Sport had an existing Central Apparatus Room (CAR) and we were building a second, additional, CAR which allowed us to fulfill two requirements; firstly, to add new system functionality without having to splice it into the existing CAR, making switch over a more straightforward process. Second, to provide another location for the other half of the redundant -7 network.
“We were creating two networks to take advantage of this redundant topology, and there is no point physically locating them together. You ideally want them on different power supplies and in different physical locations, so you build your network accordingly and run connectivity via separate routes around your facility.
“Understanding where to locate the core switches and what those core switches are going to be based on, from a port-speed point of view, is a lot of work to begin with, especially in a facility which is already on air. Every piece of equipment needs a connection to both the red and the blue networks, across two CARs. It requires a lot of infrastructure planning which needs to be considered before you even get on site.”
On the right road
The road to IP is not straightforward; it is littered with potholes and slow moving traffic, and not all the traffic moves at the same speed or takes the same route to get there. So how will we know when we do get there?
“It depends on where “there” is and what the end goal is,” says Goddard. “A protocol like Dante does an excellent job of working with audio over IP. You don’t get to see what goes on under the hood but it provides a solution which discovers, routes audio, manages signals and understands the capabilities of different equipment. You don’t have to think about it because it does all the hard work in the background.
“But IP isn’t purely about audio; moving media around a broadcast system includes audio, video, metadata, control, etc. Managing this when your system consists of equipment from different manufacturers can be challenging. The management system itself can be chosen from a variety of suppliers, all with their own selection of capabilities.”
Goddard notes that ST2110 is like working with engineering building blocks; it exposes you to everything and you have to manage it all yourself. “And of course it plays well with distributed and remote working; you’re not necessarily using ST2110 to do your distribution across a wide area network so it’s still going through some kind of gateway, but it lends itself more readily to that kind of workflow.”
The destination is definitely somewhere more interesting. Some people are already there, but others are still on the way. Just so long as they are planning the journey.