NEW YORK — Last week’s article on IP codecs generated numerous emails. (In case you missed it, read that piece here.) The general gist of the emails is that these devices are not understood very well. Granted, they are still a fairly new technology, but they are a mystery. So, I’ll touch on several of the emails I received in hopes of clearing up some of the mystery.

The first note was from a station that is presently using an IP codec as an STL (Studio to Transmitter Link). When they moved their facility several years ago, they found they would not be able to make a microwave shot to the transmitter site, and the local phone company fouled up the program line installation they requested (big surprise). The station opted for the IP Codec route.

Unfortunately, the first line of the second paragraph in this email identified the entire issue. This is a small rural area. The internet provider is less than reliable, and the service was described as “unstable.” As a matter of fact, the station was off the air as the writer was putting together his note to me, as there had been a transformer explosion near the head end of the network provider and they were down due to the power outage. An internet provider with no generator/power backup? In this day and age? Apparently, they do exist.

The key to making IP codecs work well is to have a stable internet provider. The stream that comes from an IP codec is intended as real time audio. The data is sent out in packets. With streaming audio that you would listen to on your computer, you have a buffering delay of usually 20 seconds to possibly over a minute. The player is constantly chit-chatting with the server, and is aware of what packets it should have and in what order they need to be assembled to produce audio. If a packet turns up missing, the player says “I’m missing packet umpteesquat.” The server then resends that packet, and you hear uninterrupted audio. This is the reason for the buffering delay – to maintain constant audio output if data is missing.

With IP codecs, you need not only uninterrupted audio flow, but also low round trip latency, particularly for live remotes that take phone calls or where a DJ is talking up intros. Obviously, you cannot run up a large buffering delay, and there is no time to resend missed packets. To make up for this, IP codecs employ error correction. The coding sent tells the receive end that packet A, plus packet B, plus packet C equals D. When the codec sees packets A, B and C, it adds them up and knows they are valid. If, say, packet B goes among the missing, the codec knows that A plus B plus C should equal D. It’s basic math. It can then intelligently recreate the missing packet and you hear uninterrupted audio.

If too many packets are missing, as would be the case with an unstable connection, you get glitches. There are numerous schemes manufacturers of these devices use to try to counter an unstable connection – one of which is to group several packets together and send them out as one “burst”. This sometimes works and gets the packets through. But there is no real substitute for a good, stable connection. If your Internet provider is suspect, and there are alternatives, it may be worth giving another company a try. The bottom line is that, if you do not have a good, stable connection on both ends, you will end up having problems.

Another reader wrote to say that I didn’t address the fact that codecs from different manufacturers won’t “talk” to each other. Actually, I did say that interoperability is a problem, as codec s from different manufacturers usually do not play well together, if at all.

We presently have a similar problem with ISDN. Just about all manufacturers of ISDN gear offer a G.722 basic codec. And for the most part, your brand A box can call a brand B box in G.722 mode and it will work. But if there are minor issues on the ISDN connection, these boxes may not talk to each other. Why? Because, apparently, there are several “flavors” of G.722, and unless the connection is close to perfect, they won’t “frame” and produce audio.

It’s a similar situation with IP codecs – except that each manufacturer has a different way of handling internet connection problems. There is no “standard” in place for manufacturers to follow – they design their system to work in a specific way, while another manufacturer designs their box to handle the internet connection differently – and the boxes won’t talk to each other. Further complicating the issue is what I mentioned previously about the G.722 codecs. There are numerous “flavors” of each codec type, and the different types very often won’t frame up and work together.

Yes, this can be a pain when you are looking to pick a codec. And for the manufacturers, they use their design as their marketing tool. Each brand handles things in a different way, and each brand has pros and cons. The best thing I can offer is to talk to the persons you will be connecting to and find out what brand IP codec they are using. You may need to purchase more than one codec. But you need to do your homework. I believe there are a few different manufacturers of IP codecs that will play nicely together, similar to the G.722 codecs.

Yet another reader wrote lamenting the fact that trying to get comparison information between brands was like trying to pull teeth. I agree, and he gave me an idea for my website that I may implement – coming up with a quick comparison between several different brands of equipment. All I can tell this gentleman for now is that he needs to go to each manufacturer’s website and download their product brochures. Read them. You should find the information you are looking for. You can always call the manufacturers as well. They will be happy to answer your questions.

Finally, if you are looking to go with IP codecs, arrange a demo with several different brands. Call your favorite broadcast supply company and request a demo with the brands you wish to compare. You can also call the manufacturers themselves. Most have demo programs in place and will be happy to set you up with a demo, will walk you through setup and operation, and will look forward to what you have to say about their product. Frankly, this is the best way to gather information – get experience with the product and see what it can do.

I love doing demos, because I always try to break the product. No, I don’t take the device and throw it against the wall or run it over with a car. I put it through its paces, then try modifying settings until the thing no longer works. I see what I can get away with before the device says “uncle.” I have helped numerous manufacturers by finding things out about their products that needed to be corrected before they produced too many of them and had them in the market causing trouble. This is why manufacturers like doing demos in the real world – they get feedback from the potential customer and find out about issues before they can be a huge problem.

IP codecs are still a young technology. And this technology changes many times over the life of a product. The only way you will know if an IP codec is for you is to try one. And make sure your internet connection is solid.

Thomas R. Ray, III CPBE, AMD, DRB is president of Tom Ray Consulting and Technical Editor of TALKERS. He can be phoned at 845-418-5065 or emailed at tomray@tomrayconsulting.com. His website is www.tomrayconsulting.com. Meet Tom Ray at TALKERS New York 2013 on Thursday June 6.