The author is APT product manager for WorldCast Systems.
A paradigm shift has been taking place for several years, as we move gradually toward fully networked IP broadcasting facilities in which there will be almost no discrete audio signals.
The focus of networking has shifted to the broadcasting facility where in-house structures increasingly feature IP protocols such as AES67, Ravenna, Livewire, Wheatstone and Dante. This change may be driven by the manufacturers of production equipment, but it will undoubtedly also have an impact on audio codecs, as they will be required to fit seamlessly within this new infrastructure.
The move toward an “all-IP” facility necessitates a redefinition of both the role played by the audio codec, specifically when deployed in STL/SSL applications and also the key features that a prospective purchaser should seek out.
THE CLASSIC AUDIO CODEC
In the past, the definition of a good audio codec generally was one that was equipped with a plethora of audio formats, able to connect with many third-party brands, and conformed to many standards.
This “classic” audio codec was designed to cover as many application areas as possible and hence support a multitude of algorithms and modes. However, for STL/SSL applications, audio formats should be limited to those that offer high signal fidelity with moderate or zero compression. Highly efficient low-bit-rate formats are not required or desirable in today’s high-bandwidth distribution networks.
Another aim of the classic codec was to be interoperable with many brands. The EBU has spent 10 years working to harmonize compatibilities to achieve this, and many codecs highlight N/ACIP compliance amongst the current feature set. However, the ability to connect with many other manufacturers increasingly is irrelevant within many of the new emerging STL applications.
Interoperability still plays a crucial role within codecs designed for mobile use in remotes and OB applications, so the efforts made in this regard are still useful. As a result, we are likely to see a greater diversification in codec design depending on the application. Whereas the classic codec was designed to cover all scenarios, we will see a very different feature set emerging for the modern remote codec than for the modern STL codec.
THE MODERN GATEWAY CODEC
With formats and interoperability no longer a priority, the desirable feature set of the modern STL codec begins to look very different.
Networking capabilities
The role of the modern gateway codec is to connect the LAN domain of a studio and the WAN domain. In many ways it acts similarly to a network router; the codec should appear in the infrastructure as a network unit with addressable inputs and outputs and can be integrated into the management systems of the studio.
An important asset of a modern gateway codec is its ability to integrate into the existing in-house network. While this varies from facility to facility, it should support AES67 as a minimum.
Hardware considerations
Converting an in-house audio stream into a WAN-compatible format with the lowest possible latency requires computation power so separate DSP based hardware is advisable for a gateway codec.
The codec should be adapted to the size of the broadcasting organization and support a sufficient number of audio channels to meet both current and future requirements.
As separate hardware, care must be taken to ensure that the device is designed to be redundant and that the redundant components are hot swappable.
Timing
Support for the distribution of complete FM Multiplexes (MPXoIP) will be important for some broadcasters.
For those working in the distribution of MPXoIP where the same program is transported to multiple transmitter sites, engineers should be aware of the issues that can be caused by latencies along the transmission link. It is advisable to seek out a codec that provides time alignment in the network and minimizes artifacts and RDS jumps at the transition point from one transmitter to another. To accomplish this, the encoder and decoders must be connected to a common network time base.
Stream Protection
In professional broadcast audio, packet loss invariably leads to audio dropouts and is to be avoided at all costs. The much-discussed FEC (Forward Error Correction) is not a perfect solution for relative low-rate audio streams and should be viewed critically. On the other hand, redundant streaming has emerged as a very successful solution that is easy to implement.
Redundant streaming is not implemented identically in all codecs and care should be taken to ensure that the technology chosen provides flexibility of stream routing, flexible use of physical and logical network ports and no limitations on the number of streams. It is also highly recommended to ensure that you can access monitoring statistics to review the effectiveness of the redundancy.
While undesirable in many broadcast scenarios, packet loss in MPXoIP or EDI broadcasts (EDI is for the DAB Digital Radio standard) simply cannot be tolerated. A packet loss in the EDI stream always leads to an audible dropout. Errors in the FM MPX signal caused by packet loss lead to overmodulation of the FM carrier.
[Read: Regardless of Locale, Remotes are the Star Thanks to New IP Codec Technology]
For this reason, two-layer protection is recommended for such signals. In the case of MPXoIP, this would mean redundant streaming plus additional protection such as over-modulation cancellation.
THE CODEC FOR AN “ALL-IP” WORLD
As broadcasting infrastructure increasingly is governed by RJ-45 network cables, switches and routers and much less by discrete audio connections, it is inevitable that the audio codec for STL applications must adapt to fit seamlessly in this new environment.
The modern gateway codec that is emerging must provide a redundant, scalable, DSP-based gateway to the WAN that offers a high level of protection to its mission-critical broadcast streams.
