AES67 can be considered the ‘glue’ you may need to interface your audio gear and build an AoIP network.
In this conclusion, Part 3, of our tutorial on AES 67, we examine proper connection and configuration for AES 67 links. Understanding how each of these elements fit into the overall network will make both setup and troubleshooting easier.
In this tutorial, readers will learn how to properly configure an audio-over-IP, AES 67 network. While there are some differences between each vendors’ products, these instructions are sufficiently generic that they apply to most devices. Learn these steps and you will be an audio-over-IP guru.
2.2 Device configuration
2.2.1 IP configuration
Select the method of IP assignment: DHCP, Zeroconf, manual / static. In case of static IP assignment, make sure you don’t assign any IP address twice and that the subnet mask matches your intended network configuration. In some cases, a gateway needs to be configured (even if it won’t be used). If no gateway is present, just enter the IP address of one of your switches. An Excel spreadsheet helps tracking IP configuration. If you prefer automatic IP configuration, check if IP parameters have been properly assigned through DSCP or Zeroconf.
2.2.2 PTP configuration
Check / configure all relevant PTP parameters the device offers; follow the guidelines given in section 2.1.5 PTP.
2.2.2 Device-specific configuration
Some devices need further configuration to interoperate properly with other AES67 gear. Here are a few commonly observed settings which may have to be configured individually:
188.8.131.52 AES67 mode
Some devices require you to activate the AES67 mode (i.e. Dante devices), other devices support AES67 natively (RAVENNA, Livewire).
184.108.40.206 Multicast address range
Despite not being fully AES67-compliant, some devices only support a limited range of multicast addresses for AES67 interoperation (i.e. Dante devices). The range needs to be configured properly with all devices; note that this may even affect devices which don’t exhibit this limitation, as AES67 streams would only be identified / accepted when their multicast address is within that configured range. As some devices don’t have a general device-level configuration for multicast address range (they can work with any valid multicast address in the range 239.x.y.z), this may be have to be respected when configuring individual streams.
While most devices also use their native discovery method for announcement of AES67 streams, some devices offer the ability to enable other discovery options on demand (i.e. enable SAP support).
220.127.116.11 Audio-related configuration
Some devices support different sampling rates, but only one may be selected at any given time (usually because a device only has one clock circuitry). AES67 calls for support of 48 kHz, but other sample rates may be used; make sure you select the desired sample rate. Further device-specific parametrization may be required; check with the operator’s manual.
2.3 Check for proper synchronization (PTP)
Once all devices have been configured, check for proper synchronization. This is important because all devices on the network derive their locally generated media clocks from the network clock distributed with PTP.
2.2.4 Grandmaster selection
It is advised that you select a device as the preferred master beforehand and set every other device to slave-only mode. Follow the steps under 18.104.22.168 BMCA parameters. Once properly configured, all devices should indicate that they are listening to the same Grandmaster (IP address and / or GM-ID should be indicated identically on all slave devices). If you see different GM-IDs, the BMCA did not work as intended and at least one device is assuming a false GM role. Here’s a quick checklist:
• Check if (PTP) multicast traffic is forwarded to all nodes (nodes need to receive the ANNOUNCE messages from all other devices for proper BMCA execution). Although the PTP multicast address (22.214.171.124) is a well-known multicast address which should be forwarded by a switch by default, an IGMP request may need to be issued to activate forwarding in certain switches.
• Check priority 1 values of devices which assume a GM role unexpectedly and compare with the settings of the designated GM. You may have to lower the priority (increase the priority 1 value) of that particular device or assign “slave-only” operation. Alternatively, increase the priority (lower the priority 1 value) of the designated GM.
• It may also help (even just for analysis) to select a different device to become GM by adjusting the priority 1 fields accordingly, or by temporarily removing suspected devices from the network.
• If you have PTP-aware switches in the network, it may help to switch PTP support off to diagnose the situation. If the situation corrects after switching off PTP support, you need to carefully check all PTP-related settings in the PTP-aware switches.
2.3.2 PTP accuracy
Check PTP accuracy on all nodes – slave devices generally inform about proper sync status. They either have a sync indicator (traffic light or any other graphical means) or they indicate the current offset from master numerically; in most cases single-digit microseconds are usually sufficient, sub-microseconds are perfect. If you don’t have proper sync on all end nodes, you have to resolve this situation before proceeding any further (i.e. configuring streams). You may want to check on these potential issues:
• SYNC message rate too low: some devices require a certain sync message rate in order to reach a stable locking situation. Try to decrease the SYNC message interval at the chosen Grandmaster (i.e. try a SYNC message interval of 2^-2 or 2^-3).
• QoS not properly configured: PTP traffic needs to receive the highest forwarding prioritization. Check if PTP packets are marked with a proper DSCP value and if all participating switches in the network are configured to store packets with this DSCP value in their highest priority queue.
• Removing traffic load: If you are unsure about properly configured QoS you can also try to remove any foreign traffic on the network to reduce the bandwidth utilization (i.e. remove potential network overload). The simplest approach would be to unlink devices or network segments which are not relevant to AES67. You could also start building your network from scratch by plugging in devices incrementally and checking each time for proper synchronization.
• Mixed switch configuration (FE / GbE): In some cases the use of switches with different network link speeds may cause synchronization issues. In most cases, this will result only in a permanent offset from master without necessarily affecting the synchronization stability. The node may settle into a synchronized condition, but most likely larger latency settings will be required for streams coming from/going to this node due to a permanent displacement between local and network time. It is good advice to only use GbE switches in the network and connect end nodes with FE interfaces directly to the GbE switch ports.
• PTP-aware switches: as mentioned earlier, PTP-aware switches are certainly valuable (or even required) to improve synchronization (especially in larger networks), but they may make things more complicated and require deeper knowledge for proper configuration. Check if PTP-aware switches are part of your network and try switching PTP support (temporarily) off.
In general, PTP-aware switches can usually only support one version of the PTP protocol – AES67 mandates the use of PTPv2. Since some solutions use PTPv1 for their legacy equipment (i.e. Dante), a PTP-aware switch may not properly forward those packets, effectively resulting in synchronization problems in certain areas of the network. Also, make sure that all configuration requirements for COTS switches are in place (i.e. QoS, IGMP etc.).
This concludes Part 3 of our three-part series. An extended version of this article - including a part 4 which focuses on RAVENNA-specific practical connection examples, along with many instructional screen shots - is available from the RAVENNA web site at this link.
Links to previous articles:
Part 1 link: Your Practical Guide to AES67—part 1
Part 2 link: Your Practical Guide to AES67—part 2
Andreas Hildebrand is acting as Senior Product Manager and Evangelist for the RAVENNA technology developed by ALC NetworX, Germany. His experience is based on more 25 years of occupation within the Professional Audio / Broadcasting industry.
ALC NetworX - an R&D company in Munich, Germany – assembled a team of experts to develop the RAVENNA technology platform, which is now an established media networking standard and compatible with the recently published AES67 standard on high-performance streaming audio-over-IP interoperability.
Although product implementations of RAVENNA are executed by individual partner companies, ALC NetworX continues to keep the lead role with respect to technology definition. More info is available at: Ravenna-network.com.
You might also like...
As well as providing functionality, tangible products present the opportunity of adding worth through their aesthetic appearance, cost of manufacture and development expenditure adds to the perceived barrier to entry for other vendors, and combined with low volumes, the cost…
At the start of 2013, BCE at RTL City was a hole in Luxembourg’s ground and in less than four years they were on air broadcasting 35 different channels across Europe and Singapore. Costas Colombus is BCE’s Special Projects Manager and…
With the release of an approved SMPTE 2110 standard, the video sector of broadcast and production has additional guidance for further development. The audio portion of content generation and delivery has also some guidance, but less so. Certainly AES67 is key…
AES67 audio networking was a hot topic at IBC. To help readers better understand the technology, The Broadcast Bridge has released a 3-part series written by Andreas Hildebrand, Senior Product Manager and Evangelist for RAVENNA technology. If your work touches…
In a time of uncertainty among many parts of the broadcast industry, Broadcasting Center Europe (BCE), part of the RTL Group, a Luxembourg-based media conglomerate that operates TV and radio channels as well as production companies located throughout Europe and…