The Role of Network Switches in Ensuring Low-latency Aes67 Audio Transmission

In modern audio networking, ensuring low-latency transmission is critical for live sound, broadcasting, and professional audio environments. AES67, an interoperability standard for high-performance audio-over-IP networks, relies heavily on the quality and configuration of network switches. These switches play a vital role in maintaining the integrity and timing of audio streams, making them essential components in AES67 deployments. As audio production workflows transition from dedicated point-to-point digital audio connections to converged IP networks, the network switch becomes the central element that determines whether the system delivers reliable, low-latency performance or suffers from dropouts, jitter, and synchronization failures.

The shift toward Audio over IP (AoIP) has been driven by the need for flexibility, scalability, and cost efficiency. AES67 emerged as the key interoperability standard that allows devices from different manufacturers to coexist on the same network. However, the promise of AES67 can only be realized when the underlying network infrastructure is properly designed and configured. At the heart of this infrastructure is the network switch, a component often overlooked by audio professionals accustomed to traditional analog or digital audio systems. Understanding the technical requirements and configuration best practices for switches in an AES67 environment is essential for anyone deploying professional AoIP systems.

Understanding AES67 and Its Requirements

AES67 is designed to facilitate seamless audio sharing across different manufacturers' equipment. It specifies a set of requirements for transporting digital audio over IP networks, including sample rates, bit depths, packet sizes, and timing protocols. The standard was developed by the Audio Engineering Society and was published in 2013, with updates following to address evolving network technologies. It requires precise timing, synchronization, and minimal latency to ensure audio data arrives accurately and promptly. Any delay or jitter can compromise audio quality and synchronization, especially in live scenarios where human perception is sensitive to even sub-millisecond timing errors.

Key technical specifications of AES67 include support for sample rates of 44.1 kHz and 48 kHz, with bit depths of 16, 20, or 24 bits per sample. The standard uses RTP (Real-time Transport Protocol) over UDP for audio data transport, with packets typically containing between 1 and 10 milliseconds of audio. The recommended packet time is 1 ms for low-latency applications, which translates to either 48 or 44.1 samples per packet depending on the sample rate. This small packet size places stringent demands on the network, as any increase in jitter or latency directly affects audio quality. AES67 also mandates support for the IEEE 1588 Precision Time Protocol (PTP) to synchronize clocks across devices, with a requirement for clock accuracy within 1 microsecond.

The standard is not a complete AoIP solution on its own but rather a profile that ensures interoperability between other protocols such as RAVENNA, Livewire, Q-LAN, and certain implementations of Dante. This means that while AES67 specifies the baseline requirements for interoperability, the actual performance of an AES67 network depends heavily on how well the network infrastructure is designed to meet these requirements.

Why Network Switches Matter for Low-Latency Audio

Network switches are the backbone of an AES67 network. They connect various devices such as microphones, mixers, and speakers, allowing for efficient data transfer. In a typical AES67 deployment, multiple audio streams are transmitted simultaneously as multicast traffic, meaning that each stream is sent once by the source and replicated by switches only to the ports that have subscribed to that stream. This multicast architecture places specific demands on switch hardware and software that go far beyond what is required for standard data networking. The key functions of switches in this context include low-latency forwarding, Quality of Service (QoS) prioritization, multicast management, network segmentation, and synchronization support.

Unlike IT networks where occasional packet loss can be handled by retransmission, audio networks have no tolerance for lost or delayed packets. A single lost packet can result in an audible click or pop, while systematic jitter can cause loss of synchronization across devices. The switch is the critical component that must handle every packet with deterministic timing, ensuring that audio streams are delivered with consistent, low latency from source to destination. The internal architecture of the switch, including its switching fabric capacity, buffer design, and forwarding logic, directly impacts its ability to meet these requirements.

Key Switch Features for AES67

Latency and Switch Architecture

The switching architecture has a direct impact on end-to-end latency. Most enterprise switches use a store-and-forward architecture, where the switch receives the entire packet before forwarding it. This introduces a small but predictable latency that is generally acceptable for AES67 applications when using modern switches with low-latency ASIC designs. Some high-performance switches offer cut-through switching, which begins forwarding the packet as soon as the destination address is read, reducing per-hop latency significantly. For AES67 networks with multiple hops between devices, cut-through switching can provide measurable latency benefits

Regardless of the switching mode, the internal switching fabric must be non-blocking, meaning that the switch can handle all ports at full line rate simultaneously without dropping packets. A non-blocking switch ensures that audio streams are never delayed due to contention within the switch itself. This is specified as the switching capacity, typically measured in gigabits per second, and should exceed the sum of all port speeds for a fully non-blocking design.

Quality of Service Configuration

Proper QoS settings prioritize audio packets over other network traffic, reducing jitter and packet loss. In an AES67 network, audio traffic must be given priority over data traffic such as file transfers, web browsing, or control traffic. This is achieved through the use of DiffServ (Differential Services) marking, where audio packets are marked with specific DSCP (Differentiated Services Code Point) values. AES67 recommends using DSCP value 46 (Expedited Forwarding, or EF) for audio traffic, which ensures that these packets are placed in the highest priority queue on each switch port.

Configuring QoS on a managed switch involves several steps. First, the switch must trust the DSCP markings received from audio devices. Second, the switch must map these DSCP values to the appropriate hardware queues. Most enterprise switches support 4 or 8 priority queues per port, and audio traffic should be assigned to the highest queue. Third, the scheduling algorithm on the egress ports must be configured to provide strict priority or low-latency queuing for the audio queue, ensuring that audio packets are always transmitted before lower priority traffic. Weighted Fair Queuing (WFQ) or Deficit Weighted Round Robin (DWRR) are generally not suitable for audio traffic as they can introduce variable delay in the presence of competing traffic.

It is important to note that QoS must be configured consistently across all switches in the network path. A single switch that does not respect the QoS markings can introduce jitter and packet loss that degrades audio quality for all downstream devices. Network administrators should verify QoS configuration using traffic generation and analysis tools before deploying the system for live use.

Multicast Management

AES67 uses IP multicast to deliver audio streams from one source to multiple receivers efficiently. Without proper multicast management, every audio stream would be flooded to all ports on the switch, consuming bandwidth and creating security concerns. IGMP (Internet Group Management Protocol) snooping is the mechanism that allows switches to listen to IGMP messages between audio devices and learn which ports are interested in which multicast groups. The switch then forwards each multicast stream only to the ports that have explicitly requested it.

IGMP snooping must be enabled and properly configured on all managed switches in the AES67 network. Key configuration parameters include the IGMP querier, which is responsible for periodically asking devices if they are still interested in receiving specific multicast groups. In a network with multiple VLANs, each VLAN requires its own IGMP querier. Some switches also support IGMP filtering, which allows the administrator to restrict which multicast groups are allowed on specific ports, providing an additional layer of security and control. Without IGMP snooping enabled, the switch would treat all multicast traffic as broadcast traffic, flooding it to every port and potentially overwhelming the network with unnecessary traffic.

Precision Time Protocol Support

Synchronization is one of the most critical requirements for AES67, and the network switch plays a central role in maintaining accurate timing. AES67 uses the IEEE 1588 Precision Time Protocol (PTP) to synchronize clocks across all devices on the network. The standard specifies the use of the PTPv2 profile, with a requirement for clock accuracy within 1 microsecond. The switch must support PTP in one of two modes: as a transparent clock or as a boundary clock.

A transparent clock switch measures the residence time of PTP packets as they pass through the switch and updates the packets with this information, allowing the receiving device to correct for the delay introduced by the switch. This is the preferred approach for AES67 networks because it preserves the end-to-end timing relationship while allowing the switch to remain transparent to the PTP protocol. A boundary clock switch acts as a PTP endpoint, recovering the clock from the upstream port and generating a new clock on downstream ports. While boundary clocks can provide better timing accuracy in large networks, they introduce additional complexity and must be carefully configured to avoid creating timing loops.

When selecting switches for AES67, it is important to verify that the switch hardware supports PTP transparent clock functionality with low latency and high accuracy. Some switches implement PTP in software, which can introduce significant jitter and is not suitable for AES67 networks. Hardware-based PTP support, implemented in the switch ASIC or an FPGA, is required for reliable performance.

VLANs for Network Segmentation

Segmenting traffic with VLANs helps isolate audio streams, preventing congestion and interference from other network traffic. In a converged network where audio and data traffic coexist, placing AES67 traffic on a dedicated VLAN ensures that broadcast storms, DHCP requests, or other data traffic do not affect audio performance. The audio VLAN should be configured with strict QoS policies and should have IGMP snooping enabled for all multicast streams.

VLAN configuration also simplifies troubleshooting by creating a logical separation between audio and data traffic. Network administrators can monitor audio VLANs independently and apply specific security policies without affecting other services. When designing VLANs for AES67, it is important to ensure that the VLAN spans all switches that carry audio traffic and that trunk ports between switches carry the audio VLAN along with any other required VLANs.

Redundancy and Resilience

In professional audio environments, system reliability is paramount. Network switches should support redundancy protocols such as Rapid Spanning Tree Protocol (RSTP) or Multiple Spanning Tree Protocol (MSTP) to provide link-level redundancy without introducing excessive convergence times. RSTP can typically recover from a link failure in 1 to 2 seconds, which may be acceptable for some applications but could cause audible dropouts in live sound or broadcast environments where continuous audio is required.

For higher availability, Link Aggregation (LAG) allows multiple physical links to be combined into a single logical link, providing both increased bandwidth and redundancy. If one link in the LAG fails, traffic is automatically redistributed across the remaining links without any interruption. Some advanced switches also support features like Fast Link Failover or Automatic Backup Paths that can provide sub-50 millisecond failover times, which is essentially seamless for audio applications.

Dual homing, where each audio device is connected to two separate switches, provides an additional layer of redundancy. This requires that the switches support features like LAG or active-active uplinks, and that the audio devices themselves support redundant network connections. In such designs, careful attention must be paid to PTP timing, as the two switches must be synchronized to the same PTP master to avoid clock inconsistencies.

Bandwidth and Port Speeds

AES67 streams can consume significant bandwidth, especially when multiple channels are transmitted at high sample rates. A single AES67 stream carrying 8 channels at 48 kHz and 24 bits requires approximately 12 Mbps of bandwidth. In a large installation with hundreds of channels, the aggregate bandwidth can easily reach into the gigabits per second range. Gigabit Ethernet is the minimum recommended port speed for AES67 switches, with 10 Gigabit Ethernet recommended for backbone links in larger installations.

When calculating bandwidth requirements, consider that multicast traffic is replicated on multiple ports, so the bandwidth consumed on trunk ports may be significantly higher than on access ports. Network administrators should monitor port utilization during peak operation to ensure that no single link is oversubscribed. Oversubscription leads to packet loss, which directly affects audio quality.

Choosing the Right Switches for AES67

When selecting switches for AES67 networks, consider several factors beyond just port count and speed. PTP support is essential and should be hardware-based for accurate timing. Managed switches are mandatory for AES67 because they allow configuration of QoS, VLANs, IGMP snooping, and PTP features. Unmanaged switches lack these capabilities and should never be used in professional audio networks.

Build quality and reliability are important because a switch failure in a live audio environment can bring down the entire system. Switches designed for industrial or professional AV environments often include features like redundant power supplies, fanless cooling for silent operation, and extended temperature ranges. While enterprise-grade switches from major networking vendors can also work well, they may require additional configuration and may not be optimized for the low-latency, multicast-heavy traffic patterns typical of AES67.

Consider the port density and interface types required for the installation. While most AES67 devices use standard RJ45 Ethernet ports, some may use SFP or SFP+ fiber interfaces for longer distance runs. The switch should provide the appropriate combination of copper and fiber ports to match the deployment requirements. Power over Ethernet (PoE) is another consideration if audio devices such as microphones or speakers are powered over the network. PoE+ (IEEE 802.3at) provides up to 30 watts per port, sufficient for most professional audio devices.

Network Design Best Practices

The topology of an AES67 network should follow a star or hierarchical structure, with all audio devices connected to managed switches and switches interconnected through high-bandwidth trunk links. Daisy-chaining switches should be avoided because each additional hop increases latency and reduces reliability. In larger installations, a two-tier architecture with access switches connecting to a central distribution switch provides the best balance of performance and manageability.

Cable quality is important for reliable Gigabit Ethernet performance. Category 6a or higher cabling is recommended for installations where runs may exceed 55 meters or where 10 Gigabit Ethernet speeds are required. For fiber connections, single-mode fiber with LC connectors is the standard choice for long-distance links. All cabling should be tested and certified to ensure compliance with the required performance standards.

Configuration should follow a systematic process. Start by configuring VLANs and trunk ports, then enable IGMP snooping on the audio VLAN. Configure PTP on all switches, ensuring that one device is selected as the grandmaster clock. Apply QoS policies that prioritize audio traffic with DSCP 46 and map it to the highest priority queue. Test the configuration with a single audio stream before deploying the full system, and verify that latency and jitter are within acceptable ranges using network analysis tools or protocol analyzers.

Common Pitfalls and Troubleshooting

Several common issues can degrade AES67 performance even when using high-quality switches. One frequent problem is incorrect QoS configuration, where audio traffic is not properly prioritized and competes with data traffic for bandwidth. This can cause intermittent jitter that is difficult to diagnose. Another common issue is IGMP snooping not being enabled or not working correctly, resulting in multicast traffic being flooded to all ports and consuming unnecessary bandwidth.

PTP configuration errors are also common, especially in networks with multiple switches. If PTP is not configured as a transparent clock on all switches in the path, the cumulative delay can exceed the timing budget and cause synchronization failures. Network administrators should also verify that all devices in the PTP domain are using the same PTP profile and that the grandmaster clock is stable and accurate.

When troubleshooting AES67 network issues, start by verifying physical connectivity and port speeds. Check that all switches are showing link at the expected speed and duplex. Use the switch management interface to monitor port utilization, error counters, and QoS statistics. If packet loss is detected on a specific port, investigate the connected device and the switch configuration on that port.

The Future of AES67 and Network Audio

AES67 continues to evolve, with ongoing work to align with the SMPTE ST 2110 standards for professional media over IP networks. ST 2110-30 specifies audio transport using AES67, and the two standards are converging to provide a unified approach for both audio and video over IP. This convergence means that the same network infrastructure can carry audio, video, and ancillary data, further increasing the importance of well-designed and properly configured networks.

Time-Sensitive Networking (TSN) is another emerging technology that promises to improve deterministic delivery for time-critical applications like audio. TSN includes standards for precise timing, traffic shaping, and frame preemption that can further reduce jitter and latency in converged networks. While TSN is not yet widely deployed in AES67 networks, it represents the next generation of network technology for professional audio and is likely to become more important in the coming years.

Conclusion

Network switches are fundamental to achieving low-latency, high-quality AES67 audio transmission. Properly chosen and configured switches ensure that audio data is transmitted accurately and in real-time, supporting professional audio applications worldwide. The decision to invest in managed switches with PTP support, combined with careful configuration of QoS, multicast management, and VLANs, directly determines the reliability and performance of the audio network. As technology advances, the importance of reliable network infrastructure continues to grow, making switches a critical component of any AES67 setup. For audio professionals transitioning to IP-based workflows, understanding the role of network switches is not optional, it is essential for delivering the performance that modern audio production demands.

For further reading, consult the AES standards page for the official AES67 specification, and consider reviewing IEEE 1588 Precision Time Protocol documentation for deeper insight into PTP configuration. The RAVENNA network standards page also provides useful context on AES67 interoperability. For practical guidance on switch configuration, Cisco's QoS for voice documentation contains principles that apply directly to AES67 audio traffic. Finally, the Audinate technical documentation library offers detailed networking best practices that are applicable to any AES67 deployment.