User Report: AudioTX STL-IP Allows WPR to Install and Forget

IP STL Helps Extend Network Reliably and Out of State
Author:
Publish date:

MADISON, WIS. Wisconsin Public Radio is a three-network, 31-station public radio group based in Madison, Wis. Some stations in the group are licensed directly to the state, some are held as a part of the University of Wisconsin System, and others are operated by local school systems.

In early 2006, WEPS — a noncommercial FM station in suburban Chicago operated by the Elgin Area School District — expressed interest in becoming a part of Wisconsin Public Radio's "Ideas Network." Because it was outside Wisconsin and well beyond the practical and economical reach of our existing terrestrial digital telco distribution systems, I sought a creative method to deliver high-quality audio from WPR headquarters to the WEPS facilities.

Internet solution

Realizing that school systems usually have high-bandwidth Internet service already in place, I shopped for a method to pass near-real-time audio across computer networks.

With WEPS operating mostly unattended in a distant city, a top priority was reliability. Other needs on my list included adequate buffering to compensate for occasional network congestion, automatic restart and reconnection on loss of power and/or network, and professional balanced analog and AES digital inputs and outputs.

Image placeholder title

STL-IP Multi-channel Unit Thinking ahead to the future possibilities of additional stations being fed via both our private networks and the Internet, I also was interested in a system that could provide both single-point and multipoint connections, a wide variety of bitrates, both bidirectional and unidirectional audio and both acknowledged TCP/IP and unacknowledged UDP connections.

At that time only one product seemed to meet all these specifications: the AudioTX STL-IP from MDOUK, a company based in the United Kingdom and distributed by Broadcast Electronics in the United States.

A pair of units was ordered and we soon had the units set up back-to-back on the bench. An ordinary $20 Ethernet switch was used to link the two 1 RU units together and to also connect a laptop for configuration. The STL-IP unit has a Web browser-based management interface for setup and configuration of all the important network and audio parameters.

Feeding typical "Ideas Network" program audio to the unit that would become the WPR "transmit" end of the link, I experimented with the STL-IP's available linear and compressed coding methods and listened to the results out of the unit that would become the WEPS "receiver."

Uncompressed, linear coding sounded wonderful at high bit rates, and my favored MPEG Layer II compression algorithm provided excellent results at lower bandwidth settings. The "Ideas Network" is a single-channel audio service, saving additional bandwidth over similar stereo configurations.

I figured it would be wise to keep my bandwidth demands reasonable to avoid overtaxing the networks (and causing unnecessary dropouts when things get crowded), so I settled on a configuration that sounded sweet at a conservative throughput: a bidirectional connection using TCP-IP protocol, 44.1 kHz sampling for the A/D conversion, and 96 kbps MPEG Layer II mono encoding. Other choices include linear (uncompressed) audio at up to 24-bit, 96 kHz, near-linear J.41 and DAT12, MPEG Layer II and III, MPEG-4 aacPlus, AAC Low Delay and HE-AAC.

Having confirmed that the units worked fine on the bench, the next step was to put them on the WPR-HQ and WEPS computer networks. After consulting the IT staff at each of the two networks, I assigned a static IP address to each unit, and asked that the IT security gang allow an outside exception in the network firewalls for a connection between those two addresses and the specified ports. A single port is used regardless of whether the audio runs one- or two-way, and this port (as well as the management port) can be set by the user.

Installing the units in their final racks was certainly no problem, and the units immediately connected to each other and started to pass audio. Everything sounded good, so I called it good and went home. The WEPS manager monitored his station closely for the next few days and reported solid audio, no dropouts.

Few problems

The AudioTX STL-IP feed to WEPS has now been running for about three years.

Any problems encountered have been primarily related to network outages: once at the WPR end when a LAN switch failed, and a few times at the WEPS end (their IT folks confirmed that their Internet access was completely down in those periods).

After the first outage I sent an XLR A3F-to-A3M jumper to the WEPS manager so he could connect the unused but active right channel output directly to the input of his unit, looping the audio back to me at WPR. This provided a form of confidence monitoring that aided future troubleshooting efforts. The units can also be setup to send alerts of any problems by e-mail or SNMP.

Image placeholder title

STL-IP Single Channel MDOUK has provided useful and timely technical support when questions arise. But not many issues have come up. The units run reliably and do what they are told.

WPR's use of STL-IP has since grown. We use the same unit at the Wisconsin Public Radio headquarters (that feeds WEPS) to provide Ideas Network programming to a third STL-IP device at WRST in Oshkosh, Wis. Similar techniques were used for this connection with one exception: after a firewall software upgrade at the WRST network, the link went down. After much wailing and gnashing of computers we discovered that by setting the units for unidirectional UDP protocol the connection could be restored. Not needing a return feed on this link, UDP was considered fine and the IT gang withdrew from their battle with the firewall.

The STL-IP unit at WPR headquarters has also been used to provide a high-quality program link back from a remote broadcast location. At the same time it was feeding Ideas Network programming to WEPS and WRST, we temporarily installed a fourth unit at a location in far northern Wisconsin where no ISDN service was available and allowed the units to connect. This worked only because of exceptionally good cooperation from the IT staff at the remote venue. I imagine that it might often be more difficult to convince the host IT personnel to let strangers pass through their firewall — though, in reality, only an outgoing TCP/IP or UDP connection is needed for this kind of remote contribution, which should be allowed by default on most corporate networks.

In addition to these deployments, we have purchased several sets of AudioTX STL-IP units as all-purpose links for use on our private network linking our bureaus and transmitter sites. The STL-IP units have been useful as temporary program paths while T1 and other permanent links were down for maintenance or reconfiguration.

There is also now a companion software product offered designed for remotes, news and sport coverage called STL-IP Connect. This runs on a standard laptop and makes a one- or two-way connection back to an STL-IP unit at the studio and is designed for use by non-technical staff. And the STL-IP product is available in two larger versions, the STL-IP-8 and STL-IP-16, which can be used both for multi-channel links and also to distribute various audio channels to far-end units at different locations.

The AudioTX STL-IP units aren't perfect; what is?

These units are almost literally a "black box." The front panel has only are only three two-color LEDs to show system and link status (TX and RX, green = okay, red = problem), and if you have more than one connection in play those lights can be ambiguous.

There are no audio level indicators on the front panel. Instead, a suite of software programs are provided that show the state of all STL-IP units on your network at a glance and can show live audio levels on any units, whether local or remote. It would be great to have at least LEDs right on the front panel that flicker in response to the presence of audio on the inputs and outputs.

Steve Johnston is director of engineering and operations with Wisconsin Public Radio.

For information, contact Broadcast Electronics at (217) 224-9600 or visit
www.bdcast.com.

Related