In the previous articles, we investigated IP from a broadcast engineers point of view as it helps us understand IP. In this article, we start to look at audio integration, and how we make IP work with audio signals, and the challenges we need to overcome.
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.
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.
Intelligent systems use efficient SDN's to route IP packets so we don't have to rely on switcher protocols.
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.
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.
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.
You might also like...
In this series of articles, we will explain broadcasting for IT engineers. Television is an illusion, there are no moving pictures and todays broadcast formats are heavily dependent on the decisions engineers made in the 1930’s and 1940’s. Understanding broadcast vid…
See that hill up ahead? It’s not a hill, it’s Mt Everest and your job is to conquer that mountain. Rendered into familiar industry vernacular, you, video engineer, are charged with building an IT-centric facility. A SMPTE standard was…
At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground. In less than four years the facility was on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…
Two years ago proponents of ATSC 3.0 began looking for a facility to host the testing of the country’s next-generation TV broadcasting standard. Similar to the early days of digital broadcasting—when the 8-VSB modulation scheme was being considered for use…
The industry’s realization of the importance and value of metadata has been growing: The recent Pay-TV Innovation Forum 2017 survey from NAGRA and MTM found that the majority of pay-TV executives believed data and analytics would be crucial to the d…