Automation

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. ...

Anyone who manages a fleet of Comrex contribution codecs will know the problem. You have ACCESS MultiRack units in a broadcast centre, BRIC-Link devices at remote sites, ACCESS Portable NX units in the field - and keeping track of which ones are online, which are connected, and which have silently gone offline is a constant background task. Checking them individually through Switchboard is fine for one or two units. At scale it becomes friction. ...

Broadcast audio engineering has always involved a degree of systems thinking. Routing matrices, gain structures, signal flow - these are disciplines built around understanding how components interact and what happens when something changes. Software-defined workflows extend that thinking into a new domain, and with it comes a new category of things that can go wrong: a script that worked last week stops working, a configuration change breaks something, a colleague overwrites your work. ...