Improving audio latency using AES67 and the iQx console

Updated 10 months ago by Bryan Jones

This document is written to assist in achieving the lowest possible latency in the headphones and microphones when using AES67. An important characteristic to remember about the iQx is that it’s primarily an AES67 console using the AES67 standard. While Livewire+ is AES67 compliant, AES67 uses a different style of clocking from Livewire+. There are adjustments to xNodes and the iQx that will improve audio latency. In some cases, this might also require software or firmware updates.

Scope

This document applies to the following products;

  • 2001-00518-000: iQx AES67 Console
  • 2001-00356-000: xSelector Router Selector Node
  • 2001-00298-000: Telos Alliance Analog xNode
  • 2001-00299-000: Telos Alliance AES/EBU xNode
  • 2001-00300-000: Telos Alliance Mixed Signal xNode
  • 2001-00297-000: Telos Alliance Microphone xNode

xNode Software and PTP clocking

An AES67 network requires a different clocking mechanism than Livewire. Specifically, IEEE1588-2008, known as PTPv2. It is different than the base IEEE1588 standard, often referred to as PTPv1. You will need to have a source of PTP on your network; if you already have xNodes providing Livewire clocking on the AoIP network, you won’t need any additional hardware to implement the PTP clock master.

Telos Alliance xNodes are capable of generating a PTP/IEEE1588 ARB (Arbitrary) class 248 clock. Please ensure your xNode is running version 2.2.2 for this. If needed, the software can be found here: https://www.telosalliance.com/Axia/xNodes

An "arbitrary" PTP clock is one which does not have any synchronization with a Grand Master clock. Generally a GM clock has some synchronization with a GPS signal. In most applications a Grand Master is not required.

The xNode has the ability to generate a PTP clock and Livewire clock simultaneously and provide it to the rest of the network.  This version of xNode can also slave to either a Livewire or a PTP clock. This is to preserve the function of any equipment operating in a native Livewire environment. 

The device providing master clock should not be connected to an edge switch, but should have a home run to the central (core) Ethernet switch. This provides the shortest path to all points.

Configure a PTP Clock Master

To establish a PTP master and to maintain Livewire clock master, set this xNode to PTP/IEEE 1588 ARB clock class 248 + Livewire Primary master as shown here;

If there is already a PTP master on the network and if this xNode is handling AES67 audio, you’ll want to set the xNode to PTP/IEEE 1588 slave only.

Note this is the "AES67 Recommended" setting.

For Livewire master where there is no AES67 streams involved, the rules established throughout the course of Axia’s life-span apply and do not fit the scope of this paper and you may leave these set as Livewire Slave.

This setting controls an audio packet offset and is used to account for small differences in the network transport. The units are in milliseconds and the default is “3.”  To further decrease latency, this can be safely set to “2.” Don’t forget to apply your changes.

Let's clear up some confusion regarding clock. It's important to understand the difference between clock, as it relateds to the "time of day," and clock as it relates to "rate". We are concerned with have a proper RATE clock for the audio packets. To that end, the NTP Server field in the SYSTEM page and the NTP SLAVE clock mode in the synchronization section are for Fraunhofer labs’ use only.  This reference to NTP does not adjust the "time of day" on the xNode nor does it apply to "rate" for purposes of synchronization in this case.

Proper configuration of the xNode audio outputs (Destinations)

We need to properly set the destinations to force them to use the higher resolution PTP clock. This is done by adding a special command into the destination channel field in the xNode. 

Navigate to the xNode’s DESTINATIONS page. For all the streams that are coming into the xNode’s destinations via AES67, add the following suffix to the channel number: ;sync-time=0. In this example, the headphone feed from the iQx is at channel 31611 and it’s located at destination 1.  So we enter, “31611;sync-time=0”:

Remember to do this for any of the destinations that are receiving a stream from an AES67 device. This forces the decoding of that stream to happen with the lowest possible latency.

iQx Source Audio Delay Setting

In addition to xNode updates and adjustments, you’ll want to make sure the iQx software is up to date.  Find the latest version on our website here: https://www.telosalliance.com/Axia/iqx-aoip-broadcast-audio-console

In each source profile in the iQx, you will find a setting called Audio delay (AES67 Link Offset).  The units are in thousandths of a millisecond with a range of 0-250ms.  This setting performs a double purpose. It can be used to delay audio playout to align with video and can be used to adjust buffer.  It defaults to a value of 1.000ms. With a high-performance network and a source device that has tight timing (as from an xNode), this default may be reduced to a minimum of 0.0ms.  if the network is somewhat jittery, and the setting of 0ms causes audio clicks or pops, the next setting to try is 0.25ms. And so on, up to higher numbers adding back buffering and latency. The goal is to achieve the lowest possibly latency with reliable audio.

Note that after making any changes to the Source profile, you must reload the source on the iQx fader for the change to be applied.

iQx: Checking for good SYNC

An important thing to keep an eye on is the status of clock sync.  The SYNCHRONIZATION page in the iQx’s GUI gives you a status indication.    We want to see SYNC in green. Here is an example of a status page showing proper synchronization.

How did we do?

TelosHelp (opens in a new tab)

Powered by HelpDocs (opens in a new tab)