Q-LAN & AES67 Networking
Yes, AES67 and Q-LAN are both IT standards based networked audio solutions. They both have the same Quality of Service (QoS) requirements and both use the same IEEE1588-2008 (PTPv2) network clocking system.
The AES67 standard specifies methods to achieve point-to-point latency performance from 125µs up to 4ms. Manufacturers implementing AES67 are free to choose the latency options that best suit their application.
However, every manufacturer must implement the mandated 1ms option in order to ensure compatibility with all other AES67 devices; this is the default setting in the AES67 components within Q-SYS Designer Software. Q-LAN v5.3 upwards also uses 1ms point-to-point for its network latency.
Total system latency is the sum of all A/D, D/A, network and processing latencies and those figures may vary from product to product. Q-SYS v5.3 upwards offers a fixed total system latency of 3.167ms for any analog input to any analog output.
As described above, the mandated AES67 1ms latency is the same as the Q-LAN 1ms latency however Total System Latency may vary with AES67 source and endpoints depending upon their architecture, A/D and D/A performance.
AES67 networked audio channels use the same resources as Q-LAN. As a result, the total networked audio channel count specified for each Core model is shared between Q-LAN and AES67.
|Core Model||Networked Audio Channel Capacity|
|Core 110f||128 x 128|
|Core 500i||128 Flex Channels (shared between in and out)|
|Core 510i||256 x 256|
|Core 1100||256 x 256|
|Core 3100||512 x 512|
No, the number of channels per stream is based on a number of factors including network latency setting, the bit depth and the sample rate of the transmitted audio. At 24-Bit, 48kHz and 1ms latency (as is used by Q-SYS and all other AES67 compliant devices) there is a maximum of 10 channels per AES67 stream.
IEEE1588-2008 (PTPv2) typically uses a single device on the network to act as the clock master for all devices on the network. A PTPv2 priority setting can allow the user to manipulate the PTPv2 Grandmaster negotiation process that happens automatically between all PTPv2 aware devices. In Q-SYS v5.3 or higher, you can set the PTPv2 Priority in the new Design Properties dialogue found in the File menu. Other products may or may not offer the ability to manually configure the PTPv2 Priority.
Integrating with Dante based AES67 devices or any other product using SAP for Connection Management
No, AES67 is implemented natively on the Q-LAN networked audio ports on all Q-SYS Cores running v5.3 software or higher. Of course, if you have the Q-SYS Dante card in your design already then you should continue to use Dante networked audio to share audio with other Dante devices. AES67 audio exchange with Dante devices is only required when there is no Q-SYS Dante card in your design.
Both AES67 and Dante use the same QoS protocols (Differentiated Services Code Point) to mark high priority traffic to assist with transmission across the network. However, Dante Audio streams use the exact same DSCP marking as AES67 (and Q-LAN) PTPv2 Clock traffic which causes degradation in performance if both systems share the same network. As a result, there are a few solutions to consider;
- Place Dante and AES67 on separate physical networks.
○ This is only possible if the AES67 device that you are trying to communicate with is not a Dante based device.
- Use the new Design Properties dialogue in Q-SYS v5.3 to adjust the Q-SYS DSCP markings.
○ These changes affect Q-LAN and AES67 streams to/from Q-SYS so can be used to ensure that Dante, Q-LAN and
Q-SYS AES67 streams can share the same network.
- Use the network switch to dynamically change the DSCP markings of certain traffic on the network.
○ This is more complex and only available on some network switches, but does allow for remapping of DSCP values in Dante,
Q-LAN and AES67 traffic on the network.
Dante uses SAP as the method to set up connections with 3rd party devices using AES67. The Q-SYS AES67 TX and RX components both offer a “Connection Mode “property where “Auto Mode” is one of the available options. When set to Auto mode, the Q-SYS AES67 TX and RX components also implement SAP for simple, single click connection to any SAP based AES67 device including compatible Dante devices.
In the Q-SYS AES67 TX (Transmitter) component, ensure that the Connection Mode is set to Auto, then enter an appropriate Stream Name and if required, a specific Multicast Address. Once complete, the AES67 stream from Q-SYS should be visible in Dante Controller and can be patched to any compatible Dante based AES67 device. Note that Dante based AES67 devices default to a Multicast IP Address range of 239.69.xxx.xxx/16 (the 1st octet is fixed, 2nd octet is configurable, 3rd and 4th octets are randomly generated). Dante Controller will only identify multicast streams that are in the same range so your Q-SYS AES67 TX Multicast Address 1st and 2nd octets must match the configuration shown in Dante Controller.
Q-SYS is a software-based processing platform running on QSC's own Linux distribution that adds real-time extensions required for high performance audio processing. This allows QSC to customize the behavior of Q-SYS using software changes rather than requiring new hardware whenever QSC wants to do something new, as is often the case with most other products in our market. In the case of AES67, we were able to add support to our network drivers without compromising the existing Q-LAN capability. Because of this, the Q-SYS Cores can run AES67 and Q-LAN on the same network interface ports simultaneously. Additionally, since Q-SYS is fully software based, this new firmware can be installed on every Q-SYS Core ever sold giving those 1st generation Q-SYS Core processors, access to this new functionality.
The Q-SYS AES67 implementation offers networked audio at 24-Bit, 48kHz and 1ms latency from transmitter to receiver.
Two Q-SYS Core processors could communicate with each other using AES67 Transmitter and Receiver components but given that Q-SYS already offers built-in, Q-LAN TX/RX components which are easier to manage, there would be no real benefit to using AES67 in this instance.
No. Q-SYS peripheral devices are designed to communication with the Q-SYS Core using Q-LAN only. The Q-SYS Core is the only device that provides the bridge to AES67 streams.
Working with Other Manufacturers
AES67 is an open standard so any company interested in sharing high performance audio over an IP network can implement it. The Media Networking Alliance is a not-for-profit trade organization dedicated to promoting the adoption of AES67. The MNA is a great resource for those interested in learning more about AES67 as well as the group of industry manufacturers who are actively seeking to promote and implement AES67. For more information, please visit the MNA here; http://medianetworkingalliance.com/
The Q-SYS AES67 TX/RX components offer both Auto and Manual Connection Mode options.
In Auto mode, the AES67 I/O components currently offer SAP functionality for simple integration with any device using SAP for Connection Management, including compatible Dante based devices.
In Manual mode, the user has the ability to customize the control connections in order to integrate with any other AES67 capable device that does not support SAP.
Each manufacturer is free to implement the control and management of their device using whatever software is most appropriate for their device. Some manufacturers will use dedicated software such as Q-SYS Designer and Dante Controller. Other manufacturers may prefer to offer Web GUI’s that can be accessed using a standard web browser. For more details on this, please contact the vendor of the device that you wish to communicate with via AES67.