When a broadcast facility moves to ST 2110, the network stops being background infrastructure and becomes a core part of the signal path. The choice of network topology has direct consequences for latency, redundancy, scalability, and how well PTP and multicast behave. Spine-leaf has become the dominant architecture for serious ST 2110 deployments, and understanding why - and what it asks of you in return - is worth the time. ...
Broadcast infrastructure has always been built around redundancy. Dual power supplies, redundant signal paths, failover routing - the principle is the same everywhere: no single point of failure should take a show off air. When broadcast moved to IP, the question became how to achieve the same resilience on a packet network, where the failure modes are fundamentally different from SDI. SMPTE ST 2022-7 is the answer the industry settled on. It defines a scheme called Seamless Protection Switching, and understanding it is worthwhile for any engineer working with AES67, ST 2110, or IP contribution systems at a level above basic connectivity. ...
There’s a tendency in broadcast to talk about technology in terms of what’s replacing it. Dolby E is overdue for that conversation in some quarters. And yet, if you’re working in contribution, live event production, or linear broadcast distribution, Dolby E is still very much present. Understanding what it is, why it exists, and what it’s carrying in its metadata is not optional knowledge for anyone doing serious audio engineering in broadcast. ...
Optical MADI is everywhere in broadcast - OB trucks, broadcast centres, temporary installations. It covers distances that coax can’t, it’s immune to ground loops, and a single fibre carries the same 64 channels as a coax cable. Most MADI-capable equipment implements the optical interface via an SFP cage, which gives you flexibility in connector type and fibre distance - provided you use the right module. This sounds straightforward. In practice, it causes more problems than it should, because the SFP cage is a standard physical form factor but the signal going through it is not standard Ethernet. Getting this wrong means no audio and no obvious error message to explain why. ...
For most of my career, getting a high-quality audio circuit to or from a remote location meant either booking an ISDN line or arranging a satellite or fibre contribution. ISDN was reliable, well-understood, and nearly universal in broadcast. It was also expensive, inflexible, and is now being switched off across much of the world. The replacement, in most cases, is SIP over IP. And while IP contribution codecs have been around for a long time, SIP as a standardised signalling layer has made a real difference to interoperability - particularly as broadcast facilities want to bring commentary and coordination circuits in from the public internet without needing to manage dedicated infrastructure at the remote end. ...
Of all the things that can go wrong in an AoIP system, PTP problems are among the most frustrating to diagnose. The audio often still plays - just with intermittent glitches, drift, or lip sync issues that are hard to reproduce and harder to pin down. Understanding what PTP is doing, and why, makes a significant difference when you’re standing in a broadcast centre an hour before air wondering why your streams are misbehaving. ...
If you’ve spent any time working with ST 2110 or AES67 systems, you’ve almost certainly encountered SDP files. They show up everywhere - in NMOS sender manifests, in device configuration interfaces, in Wireshark captures, and in the logs of things that aren’t working the way you expected. They look deceptively simple. They’re plain text. But getting them wrong causes problems that can be frustrating to diagnose, especially when the issue is something subtle like a mismatched packet time or an incorrect clock reference. ...
One of the things I find interesting about the broadcast industry’s move to IP is how the conversation tends to focus on transport. Ravenna, AES67, ST 2110 - these are protocols for moving media across a network, and they’ve matured significantly over the last decade. But transport is only part of the picture. Once you have dozens or hundreds of IP devices on a network, you need answers to some fairly fundamental questions. How do applications know what devices are available? How do you make a connection between a sender and a receiver? How do you change that connection, and when does the change take effect? ...
When we talk about audio over IP in broadcast, the conversation almost always centres on network transport. How do we get audio from A to B over an IP network? That’s where Ravenna, AES67, Dante, and MADI-over-IP live. It’s an important problem, and the industry has largely solved it. But there’s a different problem that gets less attention: once audio arrives inside a software-defined or cloud-based facility, how does it move efficiently between applications? How does one process hand audio to the next without creating a bottleneck? ...
The audio world has its own version of the IP debate, and if you’ve spent any time around broadcast engineers in the last few years, you’ll have heard it. MADI is old technology. AoIP is the future. Dante, Ravenna, AES67 - that’s where everything is heading, and anyone still specifying MADI is stuck in the past. I’ve heard this argument a lot. I’ve also spent years working with both technologies at major live events, and my view is considerably more nuanced. ...