Telos Archives – The Broadcast Knowledge

Intercom systems form the backbone of any broadcast production environment. There have been great strides made in the advancement of these systems, and matrix intercoms are very mature solution now, with partylines, IFBs and groups, wide range of connectivity options and easy signal monitoring. However, they have flaws as well. Initial cost is high and there’s lack of flexibility as system size is limited by the matrix port count. It is possible to trunk multiple frames, but it is difficult, expensive and takes rack space. Moreover, everything cables back to a central matrix which might be a single point of failure.

In this presentation, Martin Dyster from The Telos Alliance looks at the parallels between the emergence of Audio over IP (AoIP) standards and the development of products in the intercom market. First a short history of Audio over IP protocols is shown, including Telos Livewire (2003), Audinate Dante (2006), Wheatstone WheatNet (2008) and ALC Networks Ravenna (2010). With all these protocols available a question of interoperability has arisen – if you try to connect equipment using two different AoIP protocols it simply won’t work.

In 2010 The Audio Engineering Society formed the x192 Working Group which was the driving force behind the AES67. This standard was ratified in 2013 and allowed interconnecting audio equipment from different vendors. In 2017 SMPTE adapted AES67 as the audio format for ST 2110 standard.

Audio over IP replaces the idea of connecting all devices “point-to-point” with multicast IP flows – all devices are connected via a common fabric and all audio routes are simply messages that go from one device to another. Martin explains how Telos were inspired by this approach to move away from the matrix based intercoms and create a distributed system, in which there is no central core and DSP processing is built in intercom panels. Each panel contains audio mix engines and a set of AES67 receivers and transmitters which use multicast IP flows. Any ST 2110-30 / AES67 compatible devices present on the network can connect with intercom panels without an external interface. Analog and other baseband audio needs to be converted to ST 2110-30 / AES67.

Martin finishes his presentation by highlighting advantages of AoIP intercom systems, including lower entry and maintenance cost, easy expansion (multi studio or even multi site) and resilient operation (no single point of failure). Moreover, adaptation of multicast IP audio flows removes the need for DAs, patch bays and centralised routers, which reduces cabling and saves rack space.

Watch now!

Download the slides.

If you want to refresh your knowledge about AES67 and ST2110-30, we recomend the Video: Deep Dive into SMPTE ST 2110-30, 31 & AES 67 Audio presentation by Leigh Whitcomb.

Speaker

Martin Dyster
VP Business Development
The Telos Alliance

As video infrastructures have converged with enterprise IT, they started incorporating technologies and methods typical for data centres. First came virtualisation allowing for COTS (Common Off The Shelf) components to be used. Then came the move towards cloud computing, taking advantage of scale economies.

However, these innovations did little to address the dependence on monolithic projects that impeded change and innovation. Early strategies for Video over IP were based on virtualised hardware and IP gateway cards. As the digital revolution took place with emergence of OTT players, the microservices based on containers have been developed. The aim was to shorten the cycle of software updates and enhancements.

Containers allow to insulate application software from underlying operating systems to remove the dependence on hardware and can be enhanced without changing the underlying operational fabrics. This provides the foundation for more loosely coupled and distributed microservices, where applications are broken into smaller, independent pieces that can be deployed and managed dynamically.

Modern containerized server software methods such as Docker are very popular in OTT and cloud solution, but not in SMPTE ST 2110 systems. In the video above, Greg Shay explains why.

Docker can package an application and its dependencies in a virtual container that can run on any Linux server. It uses the resource isolation features of the Linux kernel and a union-capable file system to allow containers to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines. Docker can get more applications running on the same hardware than comparing with VMs, makes it easy for developers to quickly create ready-to-run containered applications and makes managing and deploying applications much easier.

However, currently there is a huge issue with using Docker for ST 2110 systems, because Docker containers do not work with Multicast traffic. The root of the multicast problem is the specific design of the way that the Linux kernel handles multicast routing. It is possible to wrap a VM around each Docker container just to achieve the independence of multicast network routing by emulating the full network interface, but this defeats capturing and delivering the behaviour of the containerized product in a self-contained software deliverable.

There is a quick and dirty partial shortcut which enable container to connect to all the networking resources of the Docker host machine, but it does not isolate containers into their own IP addresses and does not isolate containers to be able to use their own ports. You don’t really get a nice structure of ‘multiple products in multiple containers’, which defeats the purpose of containerized software.

You can see the slides here.

Watch now!

Speaker