Current industry buzz words are automation, centralization and standardization. They are supposed to drive efficiencies and simplify broadcast infrastructures to make the business more profitable.

The IT world is full of automation and centralization, and business owners of broadcast facilities look at the efficiencies gained with deep envy. However, broadcast systems are generally more advanced in standardization compared to IT.

Broadcasting is Standardization

In part, the need for standardization was driven by the manufacturers of radio and television sets. To build affordable domestic appliances the manufacturers needed a common standard.  For RCA to have the confidence to build a hundred thousand radio’s they needed to know all the broadcasters were singing from the same hymn sheet.  And as Gary Olson’s article “We are family” shows, the extent of broadcast-IP standardization is increasing in momentum.

Early IT designs were closed systems and you couldn’t move a tape from an IBM3090 to a Univac 9400. Even the networks were different as manufacturers wanted to lock buyers into their systems, and they were so busy trying to make the technology work they didn’t have time for standardization. Only with ARPANET and the development of TCP/IP did we start to see standardization in IT.

The big issue for broadcasting is that we are distributing synchronous data streams on asynchronous IP networks, and we are not used to following strict ITIL (Information Technology Infrastructure Library) processes.

Audio Pops and Splats

Broadcasting can deal with delay quite easily assuming it’s deterministic and reliable. Sample rate synchronizers and converters have been in use for many years in the digital audio world. They rely on a single master clock generator that provides synchronization of all DAC’s, ADC’s and audio processing in a station. Loss of synchronization in one part results in audio splats, pops and short repetitive sequences.

Documentation of point to point connections was relatively straightforward. System diagrams with cable numbers matched the physical cables so engineers could easily fault-find broken systems. But documentation had to be kept up to date, and was often forgotten about after the fire-of-the-day had been extinguished. Knowing where the latest version of the documents resided was another challenge.

Systems Quickly Become Complex

Even with the most efficient administration system, we had trouble knowing where the sole source of truth was to be found. And when we add patch bays to the mix, the system became confusing and outdated very quickly. It isn’t uncommon for interconnected patch-bays of audio double-enders to be left for years without being touched - the person who made the connection didn’t pull the connection down at the end of their shift, or even worse, put a note on it saying, “do not touch”, and so it wasn’t.

IT systems have their challenges and are far from perfect, but compared to broadcast systems they are positively idyllic. IT has its roots in banking, and has developed highly effective management systems to provide audit trails to track adjustment. Change management is one of the disciplines in ITIL which guarantees documentation stays up to date and relevant.

Reliability 

For a countries economy to thrive their banking industry must be trust-worthy and reliable, otherwise investors become nervous because they may lose money, and borrowers become nervous because the interest rates become unstable, resulting in fluctuating repayments and loss of money. The banking industry relies on human confidence, and so they have spent hundreds of years perfecting audit trails. As IT moved into this arena they have had to adopt the same practices.

IT engineers tend to be product specialists, they have a deep understanding of specific vendors’ designs, such as Cisco switchers or Barracuda firewalls. Their training is based on the risk-averse system of banking and ITIL management.

Change Control

If you ask an IT engineer to make a change to a system, you are usually asked to fill in a “change control form”, this isn’t the IT engineer being difficult, but reverting to the training they’ve had driven into them from day one. As broadcast engineers, we can either ignore them and do the work ourselves, or fill in the form.

The essence of the form is to find out who will be affected by the change. In traditional broadcast systems using point to point connections this was generally an easy question to answer. If I removed a DA I knew was feeding a sound desk, and three monitoring positions, then the impact was limited. In the IT world, making a simple change to a firewall or switcher could have a devastating effect on the accounts system, or even worse, payroll!

To understand this further look at the article “Do We Need Network Security?”

Look to IT

Do you want to be the engineer who is responsible for making a seemingly innocuous change to a firewall, and then the finance system not being able to communicate with the out-sourced payroll database, resulting in nobody getting paid that month?

To fully understand automation and centralization we must look to the IT industry to understand its implications and reasons. But broadcast engineers have the moral high-ground for standardization and are teaching IT professionals SMPTE, DANTE and AES standards.

Intelligent Routing

Audio innovation seems to lead video, and the integration of audio into IP systems is no exception. HARMAN’s Studer have been working to integrate IT thinking into their designs with DIOS. As well as providing the automation and centralization systems already discussed, they have integrated traditional audio networking into IP to provide resilience across any audio connection. DIOS will automatically detect a loss in a MADI link, and then route the audio through an associated IP link, using its deep knowledge of the system to provide the best efficiency.

Before we can start building our IP network we must understand how the IT department think and work, and only then can we start streaming bandwidth hungry audio signals through IP networks.