MDOUK’s Codec Transmits Audio Over IP; RS-232 Connects Call Screener to Field
I recently had the opportunity to experiment with MDOUK’s latest offering for the broadcast market, the AudioTX STL-IP, an audio codec that enables the digital transmission of audio over any IP connection. The device operates just as any other STL, in that it takes an audio input and sends it to another device on the other end of the chain, where it is returned to analog again.
I decided to use the devices in a number of scenarios to see just how they would perform. Because they are meant for both a typical STL usage and remote broadcasting, I decided to try and “break” them by putting them into some nearly impossible situations.
MDOUK is based in England. Readers may be familiar with its AudioTX line; it includes the AudioTX Communicator, which lets a PC or laptop serve as an ISDN codec. The company has been considering a U.S. dealer but at present sells to U.S. customers directly.
Getting started
Configuration, once the system is installed, is performed via a Web interface. The biggest problem with the interface is that it doesn’t work with Mozilla Firefox, my typical browser. I had to resort to using Internet Explorer – something I try to avoid – to access the interface. Because IE is the browser that most users will likely have at their disposal this discrepancy may be acceptable.
Product CapsuleTHUMBS UP:
Robust system
Highly cost effective
Easy to maintain
Versatile design
THUMBS DOWN:
Poor power switch
Terse documentation not for newbies
No easy way to set up the system initially
No U.S. distributor
PRICE: $3,000
CONTACT: MDOUK at [email protected].
I began by hooking them up to our present 5.8 GHz spread-spectrum link that connects the studio to one of our transmitter sites. We use the Motorola Canopy system, a device intended for ISPs for wireless Internet connections.
The Canopy gives us 5 megabits of bandwidth for IP data over a distance of roughly 10 miles (17 km). The Canopy is connected to the KLZ(AM) Denver transmitter site from the studio, and uses the Harris Intraplex STL system for transporting audio to and from the site.
I configured the STL-IP for MPEG-I/Layer-2 coding, and set it for a 384 kbps stream. There are many other formats available, including linear audio, but for our purposes I kept it set for the MPEG format.
I also configured it for a UDP connection, although TCP is another available option. Using that method I was able to send audio through the Canopy with a total latency of less than 100 ms. However most of the latency was due to a 50 ms “jitter buffer” that I had configured to insure the audio was dropout-free.
Tough enough
After a short time of testing I decided it was robust enough to use over the weekend in place of the Intraplex. This could have been a risky step, but I trusted the STL-IP to operate without a hitch – and it did. The audio quality surpassed the Intraplex, mostly because we have the Intraplex set to encode at 256 kbps, whereas the STL-IP was set for 384 kbps.
The next test was to make a TCP connection with no buffering and no error correction. We tested the system in that configuration and found no problems. Latency was reduced to somewhere under 50 ms in this configuration.
Then I decided to give it an impossible test. I connected it to a cable-modem through a Linksys router. The manual explains the proper way to configure the router for this scenario, and I would highly recommend the user read it thoroughly before attempting a setup like this.
However the test wasn’t successful. We were unable to determine if the problem was with my router’s throughput (the Linksys doesn’t have a way of setting QoS parameters, so there was not any possibility of optimizing the connection) or with my cable-modem speed (downloads are at 4 Mbps, but the upload speed is choked at 256 kbps). I had the STL-IP set for a TCP connection, 128 kbps MPEG-1/Layer-2. Yet the audio was choppy.
Because the unit can be used for remote broadcasts, it is possible that the user might run into this type of situation in the field. I didn’t have time to try all possibilities, but the representative I talked with at MDO-UK explained there were methods to optimize the connection and have a reliable link under these circumstances.
The final test was connecting the units back-to-back on the bench and running linear audio through them. In this configuration there was no perceptible delay to the signal, though the specifications state that the latency is about 5 ms. For those who have dedicated IP connections between their studio and transmitter site, this method would provide a simple solution to the old-fashioned analog audio path.
In addition to the standard audio connections, there are ports for RS-232 connections and external logic. For a typical STL, the RS-232 connection may seem like overkill. If you are doing remote broadcasts with the system, however, the RS-232 could be used to connect your call screener system to the man in the field.
The logic connections can provide remote tally, or even a basic remote control system for a transmitter site. There are four digital I/O channels available.
Suggestion box
There are a few things I did not like. The first thing I noticed after removing them from the box was the power switch on the back. It reminded me of the little 19-cent pushbutton switches found in the electronics bargain stores. MDO-UK assured me they were reliable.
But the switch also is located rather close to the AC line connection. An errant cord swinging around could impact the switch, turning the power off at a most inopportune time. The representative at MDO-UK informed me they would take this matter up at the next meeting of the minds.
Another issue I had was the manual that came with the unit. It is well written, but there are some areas that would leave the neophyte network administrator scratching his or her head. Suffice it to say that this equipment is meant for people who are experienced with setting up TCP/IP networking.
There wasn’t a way to return the unit to factory default condition easily. Having an internal jumper or switch to perform this task would be helpful. How many times have we engineers messed up the configuration of a device? Being able to put it back to square one quickly would reduce the profits of the aspirin companies.
Finally, there is no easy method to configure the unit initially. In order to install the STL-IP you must reconfigure a computer to operate on the default subnet for the system (in this case that subnet is 10.0.0.0/8). A better method would be to use SNMP to access the unit via a hardware (MAC) address. Then it would be a simple matter to send the configuration to the unit, regardless of where it is located on your network. Many devices use this scheme already, and it would save a lot of time and headaches in the initial setup stage.
Overall I am more than satisfied with the STL-IP. At a price of roughly $3,000 per unit it is an inexpensive alternative to other systems available. And if you use a wireless IP link, such as the Motorola Canopy system, an entire end-to-end digital STL system could be installed for less than $10,000.
