Radio Consoles

IP Audio Networking

Why Wheatstone For Radio? Click to find out...


Wheatstone for radio: You know what they say about radio and silence. Right. So don’t even go there. At Wheatstone, we know you have one thing and one thing only that’s going to raise you above the din of today’s multimedia world. Your sound. If it’s just pictures you want, that’s not us. Wheatstone is all about audio. We process it, route it, and cue it up for you. We get it to do stuff that only radio can fully appreciate, starting with audio IP routing (AoIP) that thinks like you do and radio consoles that are the everyday workhorses of thousands of radio studios today. Cool consoles and mixers. Intelligent audio IP studio networking or TDM routing. AM and FM on-air processors that rock. It’s all right here.

Click to download our NEW RADIO PRODUCTS FOR 2015 Brochure

AES67. Hear, There and Everywhere.

5 things you need to know about this audio standard.

AES67 INSIDE_BADGE_2560AES67 is everywhere. It’s in every major audio network, including our WheatNet-IP, which means that you’ll be able to transport audio between all these systems and other devices and peripheral gear that are connected to them. This IP audio transport standard was ratified in 2013 by the AES X-192 task force, of which Wheatstone was a member.

But, AES67 is by no means a complete interoperability standard. It doesn’t provide for discovery and control, both of which are needed for any kind of inter-functionality to take place. These standards are in the works, but in the meantime, turning devices on and off, controlling peripheral gear from the console, signaling when a source is ready for air play, and controlling the playout system with a fader – these are all functions of WheatNet-IP and similar audio networks. In the case of WheatNet-IP, for example, a single Ethernet cable carries the real-time audio stream as well as network and device control messages and other metadata. AES67 covers the audio streams only.


With all this in mind, here are straightforward answers to the more common questions our engineers receive on AES67.

Why do we need AES67?

IP networking is easily one of the most ubiquitous technologies found in the world today. IP audio network manufacturers are able to take advantage of, and share in, many, many proven standards as a result.

So, why do we need one more standard?

Because the rules of IP packet distribution are not friendly to real-time audio. Synchronizing large amounts of data is the biggest problem. In the IP network, packets aren’t necessarily routed based on which packets were created first. That works fine for a typical office network, but without some sort of deterministic routing for the heavy traffic loads of the audio network, packets can become jumbled and delayed. This can cause jitter and packet loss or dropout. Audio network makers have had to work around this problem with tools like buffering and QoS to assure continuous audio transport. No two manufacturers solve this problem the same way, which has made it difficult for them to exchange audio between them.

What does AES67 do?

Almost all audio networks use a standard IP protocol called RTP (Real-Time Protocol) to create the proper packet order. RTP provides identification in the packets about their creation time and order but, for all the reasons stated above, it has been up to the IP audio network manufacturer to extract this information and to recreate the audio data and timing. Each differs in the specific packet loading, timing and synchronization mechanisms within the protocol.

AES67 has come along to provide the common synchronization, clock identification, session description and other interoperability recommendations we can all share. AES67 adapted the PTPv2 (Precision Time Protocol - IEEE 1588-2008) standard as the master clock reference, so we can more easily transport audio between our various systems without jitter, delay and data dropout. Check out this AES link for a full description. 

Does AES67 provide for discovery?

No. AES67 does not provide for a standard way to find and add devices to a network. Discovery is left up to each individual manufacturer, although most of the major players take a similar approach to finding and labeling components in the network. Most designate extra packets on the network to communicate discovery data and display it seamlessly to all users with signal names and other information easily created and recognizable to broadcasters.

Does AES67 provide for control?

No. AES67 is an audio transport standard only. Another standard or other standards are needed for full interoperability of the control features of various audio networks. The AES-X210 task group, of which Wheatstone is a part, was formed for this reason. We recognize that gaining access to hundreds of channels of audio on a network is useless if you can’t route them, turn them on or off, fire their playback, or turn an ON AIR light on when needed. Currently, to accomplish this, IP audio network manufacturers use packets to communicate command and control. Each system is different, and sometimes an ancillary PC is used for this and sometimes the intelligence is built right into the network devices, as is the case for our WheatNet-IP system.

Control is built into each WheatNet-IP connection point that is shared with other IP connection points across the network, giving you access to all sources at once as well as the presets and any associated logic that go along with each feed for controlling mic ON/OFF, changing remote mic settings for IFB, and processing and other parameters. (There we go again!)

Does AES67 pay it forward?

Yes. AES67 is extensible, meaning that you will be able to add to it as situations change. Any standard that results from AES-X210 or a similar group will add on to, not replace, AES67.


Wheatstone Navigator How To Videos

In this video series, we show you how to easily acoomplish often-used tasks in Navigator.

Videos in this series (click to watch):

• Light A Spare Button LED With A Salvo v2

• Using a Spare Button to Fire a Salvo Tutorial

• Creating a Salvo Tutorial

• WheatNet-IP Navigator Machine Start Tutorial

Your Cheat Sheet to Part 101 Wireless IP STLs

WNIP PART101_2560Part 101 frequencies have been used by businesses and others for some time. But not until 2011, when the FCC abolished the so-called “last link rule” precluding broadcasters from using these bands, did broadcasters have access to these frequencies for wireless IP STLs.

Licensed IP wireless systems (Part 101 6 GHz or 11 GHz) are useful as a main STL, such as when a station is moving and re-upping their STL in a market where 950 MHz frequencies are hard to get.


By putting up an IP link from the studio to the transmitter, your transmitter site immediately becomes part of your Ethernet network. “It’s almost like from an IP standpoint, that tower is sitting as part of your building now,” said Jeff Holdenrid, who specializes in wireless IP for broadcast and other emerging markets for DoubleRadius engineering firm. Jeff has installed dozens of wireless IP microwave systems with our WheatNet-IP audio network in the past five years, most averaging in the 20 to 25 mile range.

A WheatNet-IP IP88D BLADE into an IP wireless radio can run 8 stereo channels across a wireless IP link and still have enough bandwidth left over for video surveillance, VoIP, remote control and other periphery functions.

A licensed-frequency system is likely to be full duplex and its throughput consistent. A 100 Mbps IP wireless radio on a licensed frequency will operate at 100 Mbps whether its range is six miles or 20 miles.

One of the reasons licensed-frequency IP wireless radios are able to maintain throughput is because of adaptive modulation. “Whereas most Part 74 radios are on or off, they work or don’t, in the IP world they work at a slower speed. They’ll slow down to stay alive. That’s another advantage of what they do. If you have a 100 meg radio, and only need 50 megs, you have room to step down,” explains Jeff.

Planning for Throughput

But while greater output power doesn’t necessarily mean that you can go farther, it does often mean better signal strength and subsequently, being able to drop down in dish size to put less load on the tower. “If you’re renting space on a tower, and you can get away with a 4’ dish instead of a 6’, you’ve just saved thousands a month in rental fees for tower space,” says Jeff.

To determine how much throughput you’ll need for a licensed or unlicensed system, Jeff suggests you start with 100 Mbps per station and then add on current requirements such as whether or not you’ll need VoIP capability or video surveillance transmitted back from the transmitter site. He recommends planning for another 20 to 40 percent above that for any new requirements bound to pop up in the next several years.

Some of the unlicensed IP wireless radios and all of the licensed radios provide software upgrades that let you scale up in throughput, starting at 250 Mbps and scaling up to as much as 1 gigabit.

Licensing for Part 101

Applying for Part 101 licensed frequency for your wireless IP STL is fairly straightforward and quick. “We do a PCN – power coordination notice – just like they traditionally do with 7 gig, 13 or 950. We find channels available and issue a PCN. Once the PCN is clear, which usually takes two to four weeks, then you file. Once you file, as long as you’re not within 10 miles of a U.S. border, meaning Canada or Mexico, you have conditional approval to start operating,” comments Jeff, who says in most markets, frequencies are readily available.

Installing Part 101 Systems

For Part 101 systems, there are three different setups: all indoors, where 100 percent of the electronics and radio components are indoors and you run flexible waveguide cable up the tower to the antennas. These installs are a lot like traditional Part 74s, and can get somewhat pricey. A step down is the split system, where the radio is located up near the antenna, but the connections – Ethernet, fiber and T1 connections - are on the ground, which brings down your cost. All-outdoor installations are when 100 percent of the equipment is on the tower, which lowers costs even more.

No BS Guide to Radio Podcasting

PODCAST ARTICLE_IMAGE_1500Amateur podcasters can call them what they want, but between us broadcasters, we know those so-called subscribers are really listeners with earbuds and a cellphone.

And that means we can reach them like we usually do -- through their ears.

No one knows those ears better than broadcasters. We know about good content and good sound. What’s new to us are the codecs and the listening environments and devices used for podcasts. To explain what it all means, we asked our audio pros Jeff Keith and Mike Erickson to give us a quick sound check on podcasting.

Oh, the places they go, the things they do

The iPhone, Android and other smartphones are skewed to the vocal range for obvious reasons. Subtract from this equation the codec bit-rate reduction needed to get that sound to those earbuds, not to mention all that background noise your listeners are subjected to while listening on the move, and there’s no way you should hand them a full dynamic range of sound.

Removing program content that can’t be heard by these devices will improve the subjective quality of your audio. Jeff suggests that anything below 100Hz and above 12kHz won’t be missed. In fact, he says, “Removing those frequencies might actually help your sound, due to reduced or removed ‘codec teasers’ such as hiss or hum.”


For all those other unwanted frequencies that happen during pauses in programming or when the AC kicks on during a recording, you’ll need a noise gate same as any other program production. Any good mic processor (such as our M1, M2 or M4-IP mic processors) should have a noise gate to keep the noise floor from rising during pauses in vocal content. This, too, will give the codec less nonsense to work with and turn into noise.

Processing to the codec

Unlike processing your on-air signal in which modulation control is the goal, processing for podcasting is all about controlling what the codec sees. This is why it’s important to give the codec consistent levels and a balanced left and right, especially at lower codec bitrates. Jeff recommends switching from stereo to mono for podcasts at bitrates less than 48kbps in order to preserve audio quality. The ideal is to maintain consistency going in, although often some audio processing can be helpful to smooth out level variations than can cause the codec to overwork. Avoid overly boosted highs, any noticeable hiss or hum, and distortion due to badly clipped audio, all of which adds to the codec’s work (and bit) load.

Adding a trace of AGC or compression can add a measure of “presence” to a podcast, but careful. Keep in mind that many of your podcast listeners will be listening in on headphones, and too much compression this close to the ear could cause fatigue. Others will be listening to longer form podcasts through their sound system in the car, all the more reason why processing that isn’t fatiguing is important.

How aggressive should you set the processing for podcasting? Mike says just enough to raise the audio above any ambient noise for listeners who don't have noise cancelling headphones, but not so much that you remove all trace of quality for those who are downloading low bitrate podcasts.

Most any audio processor that you have in the chain will work. But if you have a choice, use a processor like our Aura8-IP processing BLADE (which has eight separate multiband processors, one of which you can use for podcasting). It lets you selectively add AGC, compression or limiting by bypassing the other sections, rather than require all three functions to operate interdependently. This selectivity makes it a little less tricky to get the right amount and type of processing needed.

For more information on processing for the Internet, download Jeff Keith’s white paper, "Audio Transfer Through the Internet." Wheatstone also introduced a new Audioarts console (our new Audioarts 08 has USB and balanced or unbalanced stereo mixing bus) made for podcasting that is worth checking out if you plan to set up a separate sound booth or studio for podcasts.

Clocking In with ACI

WheatstoneVClock BIGOur Kelly Parker ran across VClock made by Voceware recently, and thought it was pure genius. There are plenty of virtual clocks that are merely numbers on a wall, or virtual clocks that are designed specifically for one broadcast group only. This virtual clock is different. VClock is flexible like a certain audio network we know, so it can transform from just a single clock to a network of clocks taking in information from different sites. Everything on it is configurable, complete with up to 32 lamps that are changeable and can be turned on / off or made to flash with external triggers (such as a "mic live" signal from a mixing console or a phone call). This clock also has an embedded web browser, which allows you to show any content that you like on VClock, simply by creating a web page.


Of course, one thing led to another, and VClock is now one of our third-party add-ons that communicate to the WheatNet-IP audio network through the ACI protocol. That is, from any control panel, workstation or control surface in the WheatNet-IP network, you can trigger salvos within VClock that change its features. VClock interfaces directly into the port of an I/O BLADE access unit through ACI for IP connectivity to our SLIOs.

ACI is our control interface used by automation companies like ENCO, OMT Technologies, RCS and WideOrbit to tightly integrate WheatNet-IP audio networking with automation functions.

Wheatstone has more than 50 technology partners.

For more information about VClock, visit .

ACI: It’s Wheatstone’s DNA Needle and Thread

ACI STORY_1000We have built into all of our audio processors a control protocol we call ACI, for Automation Control Interface. ACI is how Belar’s FMHD-1 with new ADC algorithm tells our audio processors what corrections need to be made for a consistent and seamless HD blend to analog whenever HD Radio coverage is less than robust.

ACI operates over the locally connected network via TCP/IP and can touch any parameter on the processor, whether it's a setting for the diversity delay, recalling a preset, changing input sources, modifying output levels, or even lowering just the AGC band three threshold by 1.62dB during some externally triggered event. Most of the program automation systems can also talk ACI, as can our console surfaces, so ACI brings new possibilities to our audio processors as well as WheatNet-IP system.

From St. Cloud to Grand Forks, Leighton’s Dream Studios

There’s a lot of that going on here, from the usual satellite relays to the calls on-hold and lobby P.A. systems that are part of the WheatNet-IP system. (They put the phone system and lobby speakers on WheatNet-IP, and the NexGen automatically changes the station every hour for waiting guests. Cool.) They’ve even engineered the WheatNet-IP to unlock the doors in the morning. “We have programed soft keys on the consoles to unlock doors for early morning guests through the I/Os on the BLADEs,” said Tony Abfalter, DOE for Leighton.

View the embedded image gallery online at: