Improving audio latency using and the iQx and iQs consoles
Updated 2 weeks ago
by
Bryan Jones
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
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.
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.
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).
Adjusting the AES67 Link Offset
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.
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.
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.
