WebRTC Has Turned Browsers Into Codecs

Radio World: What would you say is the most interesting recent trend in codecs?

Tom Hartnett: By far, the inclusion of WebRTC clients in computer browsers. Essentially, every internet browser, desktop or mobile, is capable of performing the function of an audio codec. We see it as having a huge impact for radio contribution. We’ve been working hard over the last five years finding ways to leverage this into broadcast for our customers, and make WebRTC technology blend with the huge installed base of hardware codecs. We’ve already delivered hardware (Opal) and cloud-based (Gagl) solutions that leverage the low delay, audio quality and easy availability of WebRTC clients.

RW: How will virtualization and software-integrated air chains change how engineers deploy codecs?

Hartnett: Some of our larger network customers are inquiring about virtualization on the studio side. We’ve embarked on some projects to meet this need, but we still give a substantial reliability edge to hardware, as there are complications and compromises that need to be made both on the audio and network sides to achieve virtualization.

RW: Given advances in audio coding and wireless IP, what improvements can still be made in the quality of audio from the field?

Hartnett: Both technologies have matured, stabilized and sort of “met in the middle.” This means it’s reasonable to deploy a codec with a 4G/5G adapter and have an expectation of a successful broadcast. I don’t think 5G is a huge leap forward for codecs — most of the enhanced operation is on the downstream side — but modern 4G/5G networks should be expected to easily carry an audio codec channel. Of course, those still concerned can “double up” their wireless bandwidth using two modems and our CrossLock technology.

RW: What long-term changes did the pandemic eventually bring?

Hartnett: Comrex saw banner sales when Covid hit, but we also saw increased use of “non-broadcast” remote solutions like Zoom and Teams for remote contribution. While they provide better audio than telephones, there’s still quite a lot of audio distortion in these products. We set about creating a cloud service that would blend the reliability factor of hardware codecs with the convenience of PC/Mobile phone contribution. We launched our Gagl cloud service this year to meet this need.

ACCESS NX Portable, using two Comrex Connect Modems via CrossLock bonding

RW: What codecs or apps are most commonly used for news work from the field?

Hartnett: For those looking for broadcast audio interface, pro-grade diagnostics and the ultimate in reliability, Comrex Access NX Portable is the dream field codec. Rather than apps, we’re promoting Gagl, our cloud-based codec bridge service, as an easy way to integrate phones and laptops on the field side with Comrex hardware codecs in the studio. Gagl requires no software install on the field side, and can host up to five contributors simultaneously.

RW: How widespread now are IP-based systems for STL applications?

Hartnett: I’d wager there’s more IP-based STLs out there than hard-wired or RF links today. Comrex BRIC-Link has established an industry reputation for reliability and is the go-to solution for most STLs.

BRIC-Link III, the latest model in the BRIC-Link IP audio codec line

RW: How do today’s codecs integrate with today’s AoIP networks and infrastructures?

Hartnett: We’ve chosen to remain agnostic in AoIP implementations by integrating the AES67 standard rather than any particular brand of AoIP. This makes us compatible with all the major players on that level.

RW: And how do today’s codecs avoid problems with dropped packets?

Harnett: Networks are a lot more stable than they used to be, and encoders in our codecs are efficient enough to work flawlessly on most networks without any error correction. But we’ve designed our own network reliability layer, CrossLock, to deal with packet drops using a combination of error correction methods for use on challenging networks. We have a growing list of customers for whom CrossLock has solved their reliability issues, even when using it on a single network.

RW: What considerations should be taken into account to allow radio talent to do shows using their phones?

Hartnett: While this is easily supported by our Gagl cloud service, I feel long-form programming like radio shows are best served by hardware codecs. These provide the proper pro-grade audio interfaces and a UI that allows you to get the job done easily. Phone services and apps are great, but should still be limited to short-form contribution in my opinion.

RW: What tools are available for sending audio to multiple locations at once?

Hartnett: Comrex codecs support IP multicast, but it’s primarily for private networks. Our codecs have also always supported multi-unicast, allowing delivery to as many simultaneous sites that can be delivered over your network. Finally, all our codecs can deliver an Icecast-compatible stream to a CDN for distribution, even simultaneously with a normal codec-codec connection.

RW: What would you consider to be reasonably low latency at this point?

Harnett: Latency is hugely application dependent. Many applications like STL are not interactive, and intentionally adding network delay buffer can enhance reliability. Interactive applications can usually tolerate around 100 mS delay — encoding, transmission, decoding — and this is easily achieved, even over relatively high-delay networks like 4G.

RW: We hear about Forward Error Correction a lot; why is this important?

Hartnett: In our products that emphasize low delay, we see little advantage to FEC in IP codecs, with the exception of dual-network redundancy, which can be considered FEC. To be effective, FEC requires so much interleaving and buffering that alternative error correction techniques like ARQ give better results. That being said, our CrossLock reliability layer implements both these functions when deemed to be effective by the system.

RW: Are ISDN and T1, for all intents, fully sunsetted?

Harnett: Dedicated circuits are long dead for new installs in North America, except that virtual T1s are still available. IP codecs have come so far in reliability; I really believe they replace ISDN very well, with the advantage of not having to custom install an expensive ISDN line for each remote.

ISDN is only now being phased out in Europe and eastern Asia. They are starting the transitions Americans began 15 years ago.

RW: Any recent examples of unusual problem-solving? 

Harnett: We’ve gotten a couple of success stories from users who need an STL where virtually no IP infrastructure exists. They installed a Starlink terminal at the transmitter site and have had good results. It does require a little tweaking of codec parameters, and it’s not perfect, but the reliability has come a long way since the early days of Starlink launches. Compared to other satellite options, it’s really cost-effective.

RW: Can engineers now create reliable remote setups on moving vehicles such as trains?

Hartnett: While it’s very enticing to do a remote from a train or airplane, I think anyone who has tried to use Wi-Fi on these vehicles, even for web browsing, understands their limitations. So it’s recommended for short-form contribution only. Cruise ships are an exception, we’ve had many successful cruising remotes using our hardware.

RW: What steps should an engineer consider to create redundancy and cybersecurity?

Hartnett: For redundancy, if an application is mission-critical, dual wired networks are the best practice and worth the cost using Comrex CrossLock. For less-critical links, wireless 4G backup using Comrex HotSwap is a cost-effective redundancy method.

With cyber, it’s all about putting security measures outside the codecs. For point-to-point links and STLs, it’s pretty straightforward to set up a VPN. Beyond that, constraining access to known IP addresses, using complex passwords, and turning off unused services in codecs are best practices.