Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now


Codec Trends Special Report: Harnack

We asked manufacturers to share thoughts about the state of their art

Kirk Harnack, CBRE, Vice President, Telos Products for Telos Systems. ‘Broadcast engineers often have more choices now than they realize for connecting transmitter sites, remote talent, studios in distant cities, sports venues and mobile news reporters.’

Radio World asked several codec suppliers about trends in their area of expertise and we got back some great information. Kirk Harnack is VP of Telos Products for Telos Systems. This is one in a series.

How are codecs different now?

Harnack: The biggest shift is away from circuit switched connections, such as ISDN, to packet-switched connections using Internet Protocol.

This doesn’t mean that IP codecs work only over the public Internet, however. Indeed, we might say that the biggest shift in codec technology is really the shift in connection choices. With ISDN and other dedicated services, there is usually just one “incumbent” telephone company from which to obtain service, plus perhaps a “competitive” carrier. With IP connection technology, there are often a half-dozen options for connectivity including low-cost RF links.

With the move to IP for data transport, we also see a shift in codec options designed to work with varying levels of latency, packet drop and other variables introduced by packet-switched data carriage.

In what direction is codec design heading?

Harnack: In the direction of options. There are sensible options from the various broadcast audio codec designers in terms of form factor, data redundancy, automatic backup, algorithm and bitrate flexibility, ancillary data and software updates.

Engineers were leery for a long time of relying on the Internet for audio transport.

Harnack: Broadcast engineers prefer to be in control of their own operations. Using their own equipment with tariffed, regulated services, such as T1 or ISDN, has been adequate in most cases. When we think of IP, we usually think of the public Internet, though that doesn’t have to be the case at all; it’s just usually the least expensive case. When a T1 connection carrying a station’s STL feed to the transmitter is cut, waterlogged or otherwise unusable, there isn’t any other good option for data transmission in that same format.

However, IP is different. IP technology and carriage is so commonplace nowadays that redundancy is inexpensive, and five nines of reliability or better is often available. Some radio networks are building out a content distribution/contribution systems using parallel satellite, private WAN and public Internet connections. Many radio stations are handling full-time STL using a local Internet provider — cable or DSL — backed up by a high-speed wireless carrier. Automatic path switching is available in sophisticated, yet inexpensive data routers.

An important component in IP data transmission is choice. Broadcast engineers often have more choices now than they realize for connecting transmitter sites, remote talent, studios in distant cities, sports venues and mobile news reporters. As engineers, it’s important that we seek out every available service and option, and bring these options up as possible solutions.

Where are we with bitrates and algorithms?

Harnack: As with many questions, the answer is “that depends.”

When bandwidth is available, broadcast engineers can choose a linear audio mode for perfect 24-bit digital audio at 48 kHz sampling. This will consume a little over 2 Mbps over an IP link. Excellent audio quality — “unimpeachable,” to quote the late Steve Church — can be had using AAC at 320 kbps or other modern algorithms at similar or higher bitrates. When low bitrate connections are the only option, we like AAC-ELD (Enhanced Low Delay), or other similarly sophisticated codecs like HE-AAC and HE-AAC v2. Other new codecs such as Opus are showing promise as well.

It’s always the case, even when using a modern codec, that a higher bitrate will deliver better audio. And linear carriage is better than any perceptually coded audio.

What role are HD Voice and other developments playing for broadcasters?

Harnack: HD Voice is an interesting subject for broadcast engineers. If we lived 100 percent in the world of telephony, we would think that “HD Voice” was the greatest thing since sliced bread. At the moment, “HD Voice” usually implies telephony using the G.722 codec. For telephones it’s a wonderful improvement! For broadcast remotes it’s certainly an improvement over G.711 (the regular telephony voice codec), but it’s not nearly as good-sounding as AAC at similar bitrates.

The benefit of HD Voice becoming more widespread in telephone systems is that phone callers sound far better than ever before. And, call-ins from reporters, ball games, parades, etc. sound quite good, and far better than they would have over a regular phone connection. But please don’t think of using “HD Voice” as a substitute for a full-spectrum, modern codec for long-form programming; and don’t even think of using it for live music.

What we’re starting to see now is a blurring of the lines between IP codecs and VoIP telephony. This is a good thing, as long as we use this enhanced capability on phone calls to bring their quality up. Let’s not fall back on HD Voice for applications where a full-spectrum, stereo codec would have been the right choice.

The Telos VX phone system can easily accept calls from HD Voice (G.722) users. The Z/IP One IP codec can also communicate with other G.722 devices (G.711, too) and can even register with a SIP Server such that standard 10-digit dialing is available.

What is the next big challenge facing codec designers?

Harnack: The abundance of low-cost bandwidth is just so enticing to anyone trying to work with real-time audio. If ISDN at 128 kbps was reliable, we wonder, why won’t 5 Mbps be that much better? Of course we know the answer to this. Most broadband connections are inconsistent. Sometimes, many times, maybe even most times, we may have high capacity and low latency. But sometimes we won’t.

That inconsistency is our challenge and our opportunity. A real-time broadcast codec needs suitably low latency and a reliable connection for the duration of the broadcast. While we cannot guarantee service without interruptions, we certainly can develop algorithms that are capable of adapting to deteriorating network conditions, correct errors (lost packets) and even provide some sort of path redundancy in some cases.

Building a codec to work over an IP transport rather than a telco transport is not so difficult. With dedicated bandwidth (nailed up, QoS), IP can be just as reliable as a circuit switched connection. Once we try to get that performance over the public Internet though, things get less predictable. This is the challenge. And this is where our most brilliant developers are dreaming and innovating every day.

What else should a codec shopper know?

Harnack: Several IP codecs designed for broadcasters are compliant with the N/ACIP standard. This standard assures a basic level of connection compatibility across different brands of IP codecs. However, N/ACIP compatibility does not address the clever and creative approaches that different IP codec manufacturers are taking to data error mitigation and concealment.

One approach is to simply send two streams from each encoder, increasing the chances that all packets will arrive at the decoder. Another approach, one that Telos has embraced quite successfully, is to use codecs that offer built-in error concealment, and then add resilient buffer size management and encoding bitrate management.

Telos calls this Agile Connection Technology. ACT measures the end-to-end network performance twice each second, plus factors packet losses and drop, as well as packet concealments, to instantly adjust buffer size and far-end send bitrate as needed.

Engineers looking at IP codecs should consider several aspects of the proposed utilization, data path(s) and the expertise level of those using the equipment. For broadcast remotes it’s best to choose a product that works well through others’ firewall/routers, and offers a friendly directory (buddy list) for one-button connecting. For full-time connections, make sure the IP codec will reconnect automatically after power loss or network outages. Ancillary data — RS-232 serial and GPIO — might be important to you, and especially important that these functions are synced to any end-to-end delay in the audio.

What is your most notable recent product?

Harnack: The Telos Z/IP One is becoming the “Swiss army knife” of IP codecs. Engineers bring us success stories every week about using Z/IP One for difficult remotes, STL links, even letting a bedridden morning host broadcast from home. It works with our free Z/IP Server for easy NAT traversal, and offers 11 coding algorithm options, each at the designers’ allowable bit rates. SIP connectivity is standard. The ACT function delivers the best remotes possible over IP, even 3G and 4G mobile links. It can connect over Wi-Fi, and to Livewire networks for easy setup. All this allows Z/IP One to work seamlessly with other Z/IP Ones; and also with other N/ACIP-compliant codecs.