Posts

GLITS and BLITS are two broadcast-standard test tone sequences that most audio engineers have encountered but few have had a convenient way to generate from scratch. GLITS - Group Line-up and Identification Tone Sequence - is the BBC/EBU stereo alignment standard. It runs as a 4-second cycle of 1 kHz tone at -18 dBFS on both channels, with timed interruptions on each channel in turn to identify left and right. It is the tone you hear at the top of a contribution feed or at the start of a tape, and it tells you the line is up, the levels are correct, and the channels are the right way round. ...

The broadcast world is divided. Europe, Africa, the Middle East, and most of Asia produce and transmit television at 50Hz - 25 frames per second progressive, or 50 fields per second interlaced. The Americas, Japan, and South Korea use 59.94Hz - approximately 30 frames per second, or approximately 60 fields per second interlaced. These two families have coexisted since the early days of television and show no sign of converging. ...

Broadcast engineering has always had an operations dimension. Keeping a transmission chain on air, maintaining a routing system, managing the configuration of hundreds of devices across a live facility - these are operational problems that require discipline, process, and good documentation. What has changed is the nature of the infrastructure being operated. SDI routers had firmware. IP routing systems have software, APIs, configuration files, container images, and dependencies. An NMOS registry is a running process. A stream monitor is a web application. A routing automation system is a codebase. The tools that the software industry developed for managing this kind of complexity are called DevOps, and they are becoming relevant to broadcast engineering whether the industry is ready for them or not. ...

The broadcast industry spent the better part of a decade converging on ST 2110 and NMOS as the open standards for professional media over IP. The Pro AV industry - corporate, higher education, live events, hospitality, digital signage - has been having a parallel conversation, mostly in private, and mostly arriving at proprietary conclusions. SDVoE, Dante AV, NDI, AVoIP chipset ecosystems from various manufacturers: each solves the AV distribution problem, none of them solve it in the same way, and none of them interoperate with each other or with broadcast infrastructure. If you have ever tried to connect a corporate AV system to a broadcast facility, or route signal between a proprietary HDMI-over-IP encoder and an ST 2110 infrastructure, you will understand the problem immediately. ...

ST 2110 and AES67 both depend on IP multicast. A single uncompressed HD video stream can consume 3 Gbps. A facility running dozens of simultaneous video and audio flows, all as multicast, needs a mechanism for ensuring those streams only reach the switches and devices that actually need them. Without that mechanism, every multicast packet floods to every port on the network - which in a media facility would be catastrophic. ...

Broadcast IP infrastructure increasingly relies on software-defined components - NMOS registries, stream monitors, timing tools, test utilities. Getting these running on a server traditionally means installing dependencies, resolving version conflicts, and documenting the exact steps so someone can reproduce the environment six months later. Docker changes that. It packages an application and everything it needs into a single portable unit that runs the same way regardless of what is already installed on the host. ...

IS-05 handles making the connection between a sender and a receiver. Once that connection exists, a multi-channel audio flow is arriving at the receiver - but which channels end up on which outputs is a separate question, and IS-05 has nothing to say about it. That is the gap IS-08 fills. It is the NMOS specification for audio channel mapping: a standardised API for controlling how the audio channels within a received flow are routed to the physical or logical output pins of a device. ...

Building a spine-leaf ST 2110 network solves the transport problem. Signals can flow anywhere in the facility at the speed of light with predictable latency. What it does not solve is the control problem: how do operators actually route those signals, how does the system know what resources are available, and how does automation talk to the infrastructure in a consistent way regardless of which vendor made each device? That is what a media orchestration platform does. It is the software layer that sits above the network and provides a unified means of controlling everything connected to it. ...

If you spend any time working with Linux-based audio systems - streaming servers, audio consoles with embedded Linux systems, remote monitoring tools, or Raspberry Pi-based devices - you will eventually need to connect to them over SSH. Getting comfortable with key-based authentication makes that process faster, more secure, and less friction than typing a password every time. This is not a deep dive into cryptography. It is a practical reference for the commands you will actually use. ...

Spine-leaf has become the dominant topology for IP media networks in broadcast facilities, outside broadcast trucks, and stadium infrastructure. It is predictable, scalable, and well-suited to the low-latency, high-bandwidth demands of uncompressed media. But a spine-leaf fabric is, by design, a closed system. The border router is what connects it to everything else. Spine-Leaf in Brief In a spine-leaf topology, every leaf switch connects to every spine switch. There are no direct connections between leaf switches, and no direct connections between spine switches. Traffic between any two endpoints always takes the same number of hops - leaf to spine to leaf - which gives you consistent, predictable latency across the fabric. ...