Audio Transport

Audio Transport via MPEG or Optional Enhanced aptX™

Livewire is a professional-grade IP Audio system, used over controlled local-area networks (LAN). It is a modern replacement for older analog or TDM digital systems. There are a wide range of products made for broadcast studio facilities that take advantage of Livewire: interface nodes for analog and AES3 audio, routers, mixing consoles, dynamics processors, ISDN and POTS telephone interfaces, delay units, satellite encoders and receivers, PC-based delivery systems, and – of course – codecs. Facilities span the gamut from a single interface xNode to multi-studio installations with dozens or even hundreds of connected devices.

If you already have a Livewire-based installation, the iPort High Density is a simple and low-cost way to extend it over a wide-area IP network. Connect the local network to one of the iPort jacks and the WAN to the other, make some configuration choices, and you are ready to go. This application nicely illustrates the advantages of IP Audio – were you to do the same thing with traditional equipment, you’d have a rack full of codec boxes, expensive router interface cards, and a plethora of cables.

If you don’t already have a Livewire installation, no problem. You can use an xNode audio interface or two (available from The Telos Alliance), and still benefit from the iPort High Density's simplicity and low cost.

Because Livewire is uncompressed, it requires a lot of bandwidth - up to 5 Mbps for a stereo channel. And because Livewire needs to be very low delay, it cannot tolerate a network with too much latency or jitter. These conditions are easily fulfilled with a switched Ethernet LAN, but they don’t generally exist for wide area networks.

iPort High Density bridges the two environments. It reduces the needed bandwidth and accommodates the delay and jitter caused by WANs. Remember that 5 Mbps data rate? After MPEG AAC compression, a typical rate might be 256 kbps – about 20 times less. For most ears, a 256 kbps AAC compression rate is unimpeachable, meaning near full quality. Most of the reduction comes from the compression process, but some reduction comes from iPorts ability to use larger packets with comparatively less header overhead. iPort High Density uses state-of-the-art MPEG codec technology to conserve network bandwidth while preserving excellent audio quality.

Codec Types

The following tables list the codec types in iPort High Density, along with their related bitrates, sample rates, and input samples per channel:

MP3 Codecs

MP2 Codecs

AAC-LC Codecs (LC = Low Complexity)

AAC-LD Codecs (LD = Low Delay)

AAC-HE Codecs (HE = High Efficiency)

AAC-HE-V2 Codecs

Enhanced aptX™ Stereo/Mono Codec

Stereo / Mono Uncompressed Audio

Getting Started

A simple installation might look like the one in the block diagram above. In this case, a Livewire xNode is providing the audio interface. Both analog and AES3 xNodes are available. Each xNode provides 4 inputs and 4 outputs (more if Mono is used). These can be expanded up to the 64 channel capacity of the iPort High Density. The xNodes must be connected with a qualified Ethernet switch. You may then connect a PC for configuration to a spare switch port or use an Ethernet cross-cable for a direct connection to the iPort PLUS.\

If you will be using your iPort High Density within a facility that is already Livewire-equipped, the xNode will not be required. Just connect the Livewire port of iPort High Density to an open Ethernet port in the Livewire system (1 Gig port required). Livewire sources can be from any Axia product including xNodes, consoles, or PC software drivers. Remember, however, there must be at least one hardware Livewire xNode in the system to provide the required clock signal to the network.  If you already have a Livewire network, you like already have this covered.

Most Livewire installations will be like that found in the diagram above, with separate networks for the Livewire audio and the general network, which has the WAN interface. The iPort is ready for this case, with its two Ethernet interface ports. It keeps the two networks isolated.

Codec Configuration

Global Codec Options

From the Codec Configuration page, click the Global Options button at the right top to set the parameters that are common for all codec channels. Having done so, you will see this page:

Codec Receive Ports

The base port numbers for both UDP and TCP determine the receive port number assigned to the corresponding function of the first codec channel. Port numbers for other codec channels are incremented by one per channel automatically. Note that if multiple WAN paths are used the A and B paths MUST have different base ports defined. The defaults are shown.

As an example－using the default configuration－Codec #1 would use the receive port 9150.  Codec #2 uses 9151.  Codec #64 (on a fully licensed iPort) would use port 9214.  These are the ports that the SENDING iPort will send to.  Feel free to adjust these ports to fit your needs.  Most of the time there is no reason to change these from their defaults.  

USD Multicast ports for Path A and B settings determine a single receive port number for all multicast traffic arriving over the path.

The "Restore default port numbers" option will reset all port numbers to the factory default values as shown in the screenshot above.

The lower two s of this page are used to configure the Content Delay function - see the Optional Content Delay  of this manual.

Codec and Channel Settings

From the Codec Configuration page, click the Options button for the channel you are configuring. There is an Options button for EACH codec.

The Options Page

Transmit

Set the desired Encoder type, Bitrate, and Channel Config (stereo/mono/dual mono) for this channel.

Use the Encoder Type dropdown to select the method of MPEG encoding you wish to use. Along with several options for AAC, MP3 and MP2 encoding, you can also choose linear (uncompressed) audio or GPIO only. If the optional Enhanced aptX is licensed, you can choose options for Enhanced 16-bit and 24-bit encoding.

With AAC, up to around 10% random packet loss can be effectively concealed. This is one of the strengths of AAC. Some other codecs also have concealment, but it will not be as effective.

The Enhanced aptX encoding options are shown even thouh your unit may not be licensed to use them.  

Network links with guaranteed Quality of Service are a plus but can lead to a false sense of security. The main weakness of UDP is that it does not recover lost packets, whereas TCP does. QoS only reduces the variance of network latency for the higher-priority traffic, thus allowing the use of less buffering at the receiving end. QoS does not prevent packet loss in general.

DSCP Class of Service refers to Differentiated Services Code Point, which sets the 8-bit Differentiated Services Field (more commonly, the DS field) in the IP header for packet classification purposes. This is where you can fine-tune the management of network traffic and determine the Quality of Service. Settings range from low-latency for streaming media to best-effort for non-critical services.

Unless you are very familiar with DSCP, we recommend you keep this set for 46 Expedited Forwarding.

The Output Configuration  allows you to specify the IP of the main output, as well as up to 3 more replicated streams.

Select the Protocol Type and specify an IP Address and Port for the receiver.  Note the port used on the receiver is determined by the Global Options from the previous .

The Protocol type may be UDP, TCP, or multicast. There are tradeoffs in this choice that are only fully understood with knowledge of this aspect of IP networks. Here is a simple overview: UDP is the usual choice because it offers a lower delay than TCP and is not impaired by TCP’s flow/rate control. However, with UDP, there is no network recovery of lost packets as there is with TCP, so the codec’s concealment is used to reduce the audibility of these events.

Checking the box for the option to Stop encoded stream in the absence of LW input stream will disable all encoding (send) if the Livewire input stream fails, is disabled, or removed. Also, note that this option only disables the audio component and if GPIO is configured it will continue to be sent.

The Enable SHOUTcast protocol option is used for sending a SHOUTcast compliant stream to an external SHOUTcast server.

If you do select to use the SHOUTcast stream, the next  is where you set it up. For more information, see the Streaming section of this manual.

Receive

Scrolling further down the codec configuration page, we come to the Receive.

The Buffering drop-down box lets you choose how much buffer is applied to the received streams. A lower value gives a lower delay but depends upon the network to have low jitter. A range of values allows experimentation to find the optimum for your network conditions. One procedure is to try successively lower values until you hear audio interruptions. Then back off to a higher value allowing for margin. A good rule of thumb is to set your buffer to three times the highest jitter.  

A note about buffering. Increasing the buffer in an iPort receiver can only account for "jitter" in the receive stream. It can not account for or correct packets that are acually missing. More on this in the Diagnostics and Stream Statistics.

The Protocol type must correspond to the value set at the encode side unit, be it UDP, TCP, or multicast.

When all values are entered, click the Apply button and return to the Codec page. Here are sample configurations for the first two channels:

GPIO

Each codec channel has a robust set of options for both send and receive GPIO. They are described in the Using GPIO and Data of this manual.

FAQs

Do all the channels need to go to a single unit at the other end?

No. Each of the Zephyr iPort PLUS channels are independent and may be used individually. Simply enter the IP numbers/ports for the unit you want to use at one or more other ends. Indeed, one codec instance may send an audio stream to up to 8 different IP addresses and port numbers. Note that each iPort codec may receive from one other codec only.

Can I use the Zephyr iPort PLUS with Telos Z/IP ONE™ or Zephyr Xstream® codecs at the other end?

Yes, with some care. Only a limited subset of all iPort functionality is interoperable. For example, there is no support for user data channels or the advanced GPIO operations on other devices.

Can I use Zephyr iPort PLUS with codecs from other manufacturers?

Zephyr iPort PLUS creates and consumes standard MPEG streams with standard RTP/UDP/IP packet formatting - nothing proprietary or special. Theoretically, it should work with other manufacturers codecs, but we cannot make any guarantees. We recommend you do some experimentation on your own before committing to an equipment purchase or broadcast of a major event.

Does Zephyr iPort PLUS conform to the ITU N/ACIP specification?

No, it does not. Zephyr iPort PLUS is intended for a different class of applications. The N/ACIP standard envisions VoIP call-like operation with SIP control, whereas the iPort is generally used in a ‘nailed-up’ way.

The Telos Z/IP ONE codec does conform to N/ACIP.

What about firewalls?

You will need to open the appropriate ports in your firewall to accept incoming IP-audio streams. The IP and port numbers are easily set/determined from the Zephyr iPort PLUS's Web pages, so you know which have to be opened. Port translation in the router is allowed if that technique is valuable to your network operation. This follows from the usual nailed-up applications for which Zephyr iPort PLUS is intended.

Telos Z/IP ONE codecs have sophisticated technology for automatically traversing most kinds of firewalls. To do so, it uses a special ZIP Server that resides outside the firewall. (You can use the one we operate as a complimentary service to Z/IP ONE users.) The Zephyr iPort PLUS has no way to use such a server because it does not use SIP for call set-up.

Which codec type should I use?

There are tradeoffs among those available in the Zephyr iPort PLUS, with each having advantages and disadvantages. That’s why we give you the choice. Here are some guidelines:

AAC is the best all-round codec for bitrates of 96kbps and above (stereo). It has excellent packet-loss concealment.

AAC-HE (AAC+) should be used at rates under 96kbps. It has good audio quality at 64kbps and is pretty good even down to 48kbps. It also has good packet-loss resilience, but not as good as AAC.

AAC-HEv2 is the most efficient codec for stereo. It has a new “parametric stereo” function that kicks-in at low bitrates. Rather than sending the left/right channels discretely, it sends a core mono signal together with steering control. This makes reasonable quality stereo possible down to 32kbps, and useful stereo even to 24kbps.

AAC-LD has the lowest delay of the psychoacoustic codecs and is the best choice when inter-activity is important, such as for on-air interactions with remote guests. It has about 30% less efficiency than AAC, which means that for equal quality, you would need to use 30% higher bitrate. Its packet loss concealment is good, but not as good as AAC.

MP3 (MPEG layer 3) is not as efficient as AAC and has the worst packet-loss concealment. It is included mostly for compatibility with codecs and software players that only support MP3.

Where can I learn more about TCP, UDP and Multicasting?

Any good network engineering book would explain these in detail. One of our favorites is Computer Networking by Kurose and Ross. There is a  in our Introduction to Livewire that introduces networking concepts to audio engineers, including a discussion of TCP and UDP. If a copy was not included with your iPort PLUS, you can download one from our website. Indeed, the TelosAlliance.com site has a number of papers and other resources that could be useful to you.

I need to calculate the actual network bitrate. There will be packet overhead, right?

Yes, the network rate is higher than the codec rate, owing to the headers for the IP packets taking some additional bandwidth. MPEG streams are very efficient in this regard, however. The overhead varies with the specific codec but is typically under 15%.

Will Zephyr iPort PLUS work over the public Internet?

That depends. There are no guarantees of any kind on most Internet connections. This is certainly true when multiple ISPs are involved, since nobody can take full responsibility for the entire link. When you choose AAC as your codec, Zephyr iPort PLUS provides quite good packet-loss concealment up to 10% random loss. That’s pretty good and would probably allow many Internet links to work reasonably well. Higher buffer time helps, of course, but at the expense of delay.

If you can take even more delay, you can use the TCP protocol option. In this case, lost packets are recovered by re-transmission, making bad links more usable. This is why streaming audio over the Internet works fairly well. The streaming servers use TCP to connect to players. Delay is not an issue. Indeed, multiple seconds of buffering is the norm.

As we mentioned before, the Telos Z/IP ONE is intended for such applications. It has a suite of adaptive technologies to accommodate bad and variable network conditions.

What's Next?

In this chapter, we showed you how to configure the codecs in Zephyr iPort PLUS to send and receive high-quality audio. In many Zephyr iPort PLUS installations, there's a fair amount of remote control, tally and status overhead that needs to accompany each of the codec channels. The GPIO capabilities of Zephyr iPort PLUS are very robust, so we've devoted an entire chapter to explaining how to set it all up. That's coming up next.