Shane Toven is senior broadcast engineer at Educational Media Foundation and its K-LOVE and Air1 Networks. This interview is excerpted from the free ebook “The Evolution of AoIP.”
Radio World: At this stage of its implementation across radio, what would you say is the most important thing that engineers should know about audio over IP?
Shane Toven: While it can be complex, there are easy ways to implement it now. For example, the proliferation of Dante into the broadcast field has lowered the barrier of entry. I have seen it a lot in television and other facilities, and I was kind of surprised to see it making inroads into broadcast.
Traditionally it has been used in live and installed sound, but it’s a straightforward system for broadcasters to work with, and the hardware is inexpensive. You can get dongles for analog, AES, USB and Bluetooth to move audio on and off of a Dante network for less than $200. And it can, in fact, talk to other AoIP standards using AES67, though it’s not as straightforward once you move out of a pure Dante world.
RW: There’s that issue of interoperability again.
Toven: With AES67 — how long has it been now since that standard was ratified? — we’re still not a whole lot better off than we were originally. Yes, it can make hardware with different AoIP standards talk to each other, but it’s anything but straightforward. You still have multiple discovery protocols, any one of which could potentially be implemented as part of AES67, or none at all. Further, you still have to deal with clocking and PTP, which is a topic in itself. A lot of these systems deal with clocking automatically in the background, but with AES67, you need to be more intentional about it and know what you’re doing.
RW: How does EMF deploy AoIP? Is it all within studios or is it broader than that?
Toven: Both at studios and at transmitter sites. In the studios, we have an extensive Axia AoIP infrastructure, and we’re even looking at deploying AoIP over a managed WAN. Again, being intentional is critical when designing such a system in terms of IP schemes, clocking and routing.
We work with several standards internally. Avid ProTools uses AVB; other systems use Dante; still others use NDI, which is another, more video-centric standard. Ultimately, you still have to get audio in and out of those systems, and if you want to do it over IP, you have to figure out how to translate between the various standards.
RW: What about STL type applications, point A to point B?
Toven: Our station sites each have at least one AoIP node — two for digital sites. Those are used mostly for routing audio within the rack; in most cases, they’re not used for any kind of STL application. I have used them that way, where you put one on either end of a microwave radio and link them up, and it can work quite well despite a sensitivity to timing and link conditions. Sometimes you’re just better off using a codec.
RW: What about security concerns?
Toven: That’s a great question. AoIP traffic itself in most cases (especially if it’s just multicast traffic) is pretty easy to sniff out because most AoIP streams use no real encryption. If security is a concern, the biggest thing is to follow best IT practices and limit access to those networks physically and electronically as best you can.
The other concern, of course, is from the standpoint of hardware management. Again, you want to limit access where you have management interfaces and follow best practices in terms of strong passwords, changing default usernames and passwords, and the like.
RW: How does this discussion overlap with conversations about virtualization and the cloud?
Toven: They tie together extremely closely. In a virtual environment, you don’t have any sort of physical audio I/O. So how do you get your audio in and out of those systems? AoIP, which again can take any number of forms. It can be native AoIP traffic like AES67, Livewire, or WheatNet. But AoIP is definitely relevant to virtualization.
RW: We’re getting more accustomed to hardware becoming software and to software becoming a service. Is that playing out in AoIP?
Toven: Absolutely. You see manufacturers offering as software what they had offered as hardware — mix engines, codecs. The hardware had essentially become a PC running software, so why not eliminate the PC? If you have an existing virtual environment, it’s just as easy to put that software inside of that virtual environment than it is to buy the box and have another dedicated box on your network.
The drawback is that manufacturers don’t necessarily have control over that environment, so it’s more difficult to support. But from a user perspective, if you’re savvy in terms of virtualization and know how to fine-tune these environments, it can work really, really well.
I’ll give you an example of how you can scale this technology. I recently was in American Samoa, where I replaced an entire air chain with a virtual environment. There was a stack of equipment — audio processor, RDS generator, the STLs. But I set up a virtual environment, loaded an instance of a virtual remote control and an instance of a virtual audio processor. The processor took AoIP in and spit out encoded MPX — uMPX in this case — and it worked amazingly well. I was really happy with the way it turned out. This setup allowed the elimination of an old 950 Megahertz STL hop. The station sounded so much cleaner by the time it was done, and it’s been very reliable.
I can do this halfway around the world, on a single station, yet it’ll absolutely scale to much larger levels, all the way up to massive enterprises.
RW: Are there any misconceptions we should dispel?
Toven: I think one of the most common things that intimidates people is thinking, “I need a whole bunch of knowledge about networks, switches and things like that.”
While true, the necessary knowledge is of things like QoS, multicast, IGMP. Once you have a handle on those, you’ve got the basics of what most AoIP networks require. Any fairly simple managed switch will handle those features.
The misconception is that AoIP is inherently complicated. While true at a certain level, there are simple ways to implement it. In fact, for a smaller facility, implementation is much easier because the smaller you get, the closer to plug-and-play you can get. In some cases, you can even get away with an unmanaged switch.
RW: Are there further developments that we ought to be watching for?
Toven: We need to keep watching what’s happening with AES67. There are still things that could be improved — particularly the control side, and discovery. Personally, I would like to have seen that discovery function implemented as mandatory, as it would make life a lot easier.
AES70 is one development to keep a close eye on, as it allows for this control functionality. I would also keep an eye on technologies like Dante and NDI as they continue to grow, and on manufacturers like Telos and Wheatstone as they continue to develop their own products and look more toward the virtual world.
Don’t forget the advantages of putting a lot of this stuff in the virtual realm. For one thing, it’s a good way to minimize the whole supply chain issue. If you can get a server, you’ve got your platform, you’ve got your hardware.
But don’t be intimidated. There are so many advantages to doing AoIP that far outweigh any drawbacks — like scaling all the way down to a single station out in the South Pacific. So don’t let it intimidate you. Dip your toes in the water and start playing around and I think you will like what you find.
