Improving audio latency using and the iQx and iQs consoles

Updated by Bryan Jones

This document is written to assist in achieving the lowest possible latency in the headphones and microphones. An important characteristic to remember about the iQx and iQs and it's strict adherence to the IEEE1588-2008 clocking mechanism. While Livewire+ is AES67 compliant, AES67 uses an improved style of clocking. There are adjustments to xNodes, iQx, and iQs 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
  • 3002-00056-000: iQs Virtual Mixing 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 more accurate 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 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 can generate a PTP clock and Livewire clock simultaneously and provide it to the rest of the network or synchronize to either a Livewire or a PTP clock. Having both clock mechanisms preserves the function of any equipment operating in a native Livewire environment.

The device providing clock synchronization 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 Primary PTP Clock

To establish a Primary PTP clock and to maintain Livewire clock, 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 default priority of three (3).

This setting controls an audio packet offset and is used to account for small differences in 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 essential to understand the difference between clock, as it relates 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 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 synchronization purposes 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 coming into the xNode's destinations from an iQx, iQs, or other AES67 sources, 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 receiving a stream from an iQx, iQs, or 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.  Please 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, and iQs, 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 possible latency with reliable audio.

Additionally, checking the Synchronous mode box forces strict adherence to the PTP clock. For some "deep tech" information on Synchronous vs. Syntonous mode, click here.

Note that after making any changes to the Source profile, you must reload the fader source on the console 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.

Let us know how we can help

If you have further questions on this topic or have ideas about improving this document, please contact us.

How did we do?