The Evolution of Audio Over IP

Audio over IP (AoIP) has fundamentally changed how professional audio systems are designed, deployed, and operated. By replacing dedicated analog or digital cabling with standard Ethernet networks, AoIP enables greater flexibility, scalability, and cost efficiency. Among the various AoIP standards, AES67 has emerged as a critical interoperability layer, allowing devices from different manufacturers—such as Dante, RAVENNA, and Livewire—to coexist and exchange audio streams. At the heart of AES67 lies the ability to use both multicast and unicast streaming, each suited to distinct operational requirements. Understanding when to apply these transmission modes is essential for network engineers, audio system integrators, and production professionals who need reliable, low-latency audio distribution.

What Is AES67?

AES67 is a standard developed by the Audio Engineering Society, formally published in 2013 as AES67-2013 and updated in subsequent revisions. It defines a set of requirements for high-performance audio streaming over IP networks, focusing on interoperability. The standard specifies audio formats (up to 24-bit, 48 kHz or 96 kHz sample rates), packet timing, network synchronization, and transport protocols. Crucially, AES67 mandates the use of RTP (Real-time Transport Protocol) over UDP for audio payloads, and it supports both unicast (point-to-point) and multicast (point-to-multipoint) delivery. While AES67 does not prescribe a specific control or discovery protocol, it aligns with widely adopted mechanisms such as SAP (Session Announcement Protocol) and RTSP (Real Time Streaming Protocol).

One of the key strengths of AES67 is its network synchronization requirement, which relies on IEEE 1588 Precision Time Protocol (PTP) to achieve sub-microsecond timing accuracy. This ensures that multiple devices can play back audio with sample-level alignment—a critical requirement for live sound reinforcement, broadcast mix-minus, and multi-room installations. AES67 also defines jitter buffers and packet loss concealment strategies, making it practical for use on managed and unmanaged networks, provided that latency and bandwidth constraints are properly engineered.

To learn more about the official AES67 specification, visit the AES Standards website.

Multicast Streaming in AES67

Multicast is a one-to-many transmission method where a single audio stream is sent to an IP multicast group address. All devices that have subscribed to that group receive the stream simultaneously. In the context of AES67, multicast is the default and most commonly used mode because it scales efficiently for large audiences. When a source sends a multicast stream, the network uses protocols like IGMP (Internet Group Management Protocol) and PIM (Protocol Independent Multicast) to replicate packets only to network segments where subscribers exist. This prevents unnecessary bandwidth consumption on links that have no interested receivers.

AES67 multicast streams typically use UDP transport and RTP payloads with a fixed packetization time (e.g., 1 ms or 4 ms). The stream is identified by a multicast IP address in the range 239.0.0.0 to 239.255.255.255 for IPv4, and a corresponding UDP port. PTP synchronization ensures that all receivers reconstruct the audio with the same clock, eliminating drift and phase differences.

Advantages of Multicast

  • Bandwidth efficiency: Only one copy of the stream traverses each network link shared by multiple receivers. As the number of listeners grows, bandwidth consumption per additional receiver is nearly zero on shared segments.
  • Simplified source management: The transmitting device sends a single stream, regardless of how many destinations need it. This reduces CPU load on the source and streamlines routing.
  • Natural synchronization: All receivers obtain the same RTP timestamp base, making it easier to align multiple speakers, monitors, or feeds across a venue.
  • Scalability: Suitable for large installations like stadiums, convention centers, or broadcast plants with hundreds of destinations.

Disadvantages of Multicast

  • Network infrastructure requirements: Switches and routers must support IGMP snooping and multicast routing. Unmanaged switches may flood multicast traffic to all ports, causing congestion.
  • Security challenges: Any device on the network can potentially join a multicast group and receive the stream. Encryption is not part of the base AES67 standard, though optional methods can be layered on top.
  • Limited error recovery: Because multicast uses UDP, there is no automatic retransmission of lost packets. Redundancy relies on network design (e.g., redundant streams or path diversity).

Typical Multicast Use Cases

  • Live concert audio distribution: Sending the main mix to front-of-house, monitor consoles, recording trucks, and broadcast mixers simultaneously.
  • Broadcast studio infrastructure: Distributing program audio from a master control room to multiple studios, edit suites, and transmission paths.
  • Large conference systems: Delivering interpretation channels or a common audio feed to numerous meeting rooms or floor boxes.
  • Public address and emergency systems: Broadcasting announcements across a campus or transportation hub with synchronized playback.

Unicast Streaming in AES67

Unicast provides a one-to-one connection between a source and a single receiver. The source sends a dedicated stream with its own RTP session to the IP address of the specific destination. Although AES67 primarily targets multicast for interoperability testing, many AES67-compatible devices also support unicast transmission for specialized applications. Unicast can be implemented over UDP (non-reliable) or, less commonly, over TCP (reliable but with higher latency).

In a unicast configuration, each receiver requires a separate stream from the source. If five devices need the same audio, five identical unicast streams must be transmitted. This obviously consumes more total network bandwidth compared to multicast, but it offers distinct benefits in select scenarios.

Advantages of Unicast

  • Stream-specific customization: The source can tailor each stream’s quality, sample rate, or channel mapping per receiver. For example, a monitor engineer could receive a stereo mix while a broadcast mixer receives a 5.1 surround version.
  • Improved security: Because unicast streams are point-to-point, unauthorized devices cannot accidentally capture the stream unless they are explicitly addressed or the network is compromised.
  • Simpler network design for small deployments: In a studio with only two or three devices, unicast may eliminate the need for multicast routing configuration and IGMP management.
  • Possible use of TCP for reliability: In non-real-time applications (e.g., file transfer or recording backup), TCP can ensure packet delivery, though this is not typical for live AES67 audio due to latency constraints.

Disadvantages of Unicast

  • Bandwidth scaling: Each additional receiver consumes a full stream’s worth of bandwidth on all links from the source to that receiver. This can overload the source NIC or the uplinks if many unicast listeners are present.
  • Higher source processing load: The transmitting device must generate and manage separate RTP sessions, timestamps, and synchronization for each unicast flow.
  • Potential for clock sync issues: If each unicast stream uses its own PTP context, receivers may experience slight differences in timing unless the grandmaster clock is common across all streams.

Typical Unicast Use Cases

  • Personal monitoring in recording studios: Each musician receives a unique headphone mix derived from the same multi-track source but with custom levels and effects.
  • Remote audio management: An engineer dials into a specific device over a WAN connection to troubleshoot or adjust settings, using a unicast stream for point-to-point control.
  • Individual device testing or calibration: A technician sends a test tone to a single loudspeaker or amplifier without affecting other devices on the network.
  • Secure streams for confidential communications: Government or corporate facilities may require that sensitive audio is only delivered to one endpoint, avoiding multicast broadcast.

Detailed Comparison: Multicast vs. Unicast in AES67

Choosing between multicast and unicast depends on multiple factors, including the number of receivers, network topology, latency requirements, and administrative overhead. Below is a structured comparison of key attributes.

Attribute Multicast Unicast
Bandwidth efficiency High for many receivers Low when many receivers
Source CPU load Low (one stream) Increases linearly with receivers
Network configuration Requires IGMP, PIM, careful subnetting Simple; no multicast protocols needed
Synchronization All receivers share one RTP stream and PTP Each stream can have independent sync (but should use same grandmaster)
Security/Privacy Lower; any subscribed recipient can listen Higher; stream addressed to specific IP
Latency Low and consistent (UDP, no retransmit) Low if UDP; TCP may add delay
Error resilience No retransmission; rely on FEC or redundant streams Can use TCP for reliability (high latency) or UDP with FEC

For a deeper look at multicast network design for professional audio, refer to the Audinate article on multicast vs unicast in Dante (note: Dante uses AES67 in interoperability mode).

Network Considerations for AES67 Streaming

Both multicast and unicast AES67 streams place demands on the underlying network infrastructure. Careful planning ensures low latency (<10 ms), high reliability, and deterministic performance. Key factors include:

Clock Synchronization (PTP)

AES67 requires IEEE 1588-2008 (PTPv2) for clock distribution. A grandmaster clock is selected (often via Best Master Clock Algorithm), and all devices synchronize to it. The network must support PTP transparent clocks or boundary clocks to maintain accuracy across switches. Failure to properly configure PTP can result in clock drift, audio pops, or complete loss of sync. Use PTP-aware switches with low packet delay variation (jitter).

Quality of Service (QoS)

AES67 audio packets must be prioritized over other network traffic to avoid queuing delays and dropped packets. Assign DSCP (Differentiated Services Code Point) values: typically EF (Expedited Forwarding, DSCP 46) for audio RTP, and CS7 for PTP events. Configure switch QoS to trust these markings and to allocate dedicated hardware queues for high-priority traffic.

Bandwidth Estimation

AES67 streams vary in size depending on sample rate, bit depth, and channel count. A 1-ms packetization at 48 kHz/24-bit stereo uses roughly 6 Mbps. For 96 kHz/24-bit 8-channel, expect closer to 24 Mbps. Multiply by the number of simultaneous streams (unicast or multicast) to ensure your switch uplinks and source NICs have headroom.

Jitter Buffers

Receivers use jitter buffers to absorb network timing variations. AES67 recommends buffers of 1 ms to 5 ms depending on network quality. Larger buffers increase latency but improve resilience. In unicast, jitter may differ per stream, while multicast receivers can share a common buffer tuning.

VLANs and Network Segmentation

To isolate audio traffic from data traffic, place AES67 devices on a dedicated VLAN. This simplifies QoS and reduces interference from broadcasts or large file transfers. When spanning multiple VLANs, use multicast routing (PIM) if multicast is needed across subnets.

For a comprehensive guide on AoIP network design, see the AudioScience AoIP Network Design Guide.

Choosing the Right Method for Your Use Case

The decision between multicast and unicast in AES67 should be based on a practical evaluation of your environment. Consider the following checklist:

  1. How many receivers need the same audio? If more than 3–5 devices require identical content, multicast is more efficient. For 1–2 receivers, unicast may be simpler.
  2. Is network infrastructure multicast-ready? If you have managed switches with IGMP snooping and PIM support, multicast is viable. If equipment is unmanaged or unknown, prefer unicast or test carefully.
  3. Do you need per-stream customization? Unicast allows different sample rates or channel counts per receiver. Multicast forces all listeners to accept the same format.
  4. What are your security requirements? If the audio stream must not be accessible by unauthorized devices (e.g., in a corporate boardroom or government facility), unicast provides better isolation. Encrypted tunnels can be added to both methods.
  5. Is synchronization across multiple streams critical? Multicast inherently synchronizes all receivers to one RTP clock. With unicast, ensure all streams reference the same PTP grandmaster to avoid drift.
  6. What is your tolerance for network configuration overhead? Multicast requires careful VLAN and routing setup, plus monitoring of IGMP group membership. Unicast is more “plug-and-play” but may stress the source.

In many large installations, a hybrid approach works best: use multicast for the main distribution backbone (e.g., program feeds to all studios) and unicast for specific point-to-point needs (e.g., engineer’s personal monitor). AES67 devices typically support both, so you can combine them without issue.

Implementation Best Practices

To get the most out of AES67 streaming, follow these guidelines:

  • Use a fixed packetization time: Stick to 1 ms or 4 ms as defined in the AES67 profile. This ensures compatibility across devices and low latency.
  • PTP boundary clocks: Deploy PTP boundary clocks at switch boundaries to maintain accuracy across large networks. Avoid transparent clocks if possible, as they can introduce asymmetry.
  • Monitor network statistics: Use tools like Wireshark with RTP analysis, or device dashboards, to check for packet loss, jitter, and timing errors. Address any issues before a live event.
  • Redundancy: For critical applications, implement redundant multicast streams (e.g., two different multicast groups) or redundant unicast paths. Many AES67 devices support seamless switching.
  • Label streams clearly: Use SAP-based announcements or a central control system to advertise stream names and parameters. This simplifies discovery and reduces configuration errors.

For practical configuration examples, the RAVENNA network technology page provides detailed insights into AES67-compliant setups.

The Future of AES67 and AoIP

AES67 continues to evolve, and its interoperability role has been reinforced by newer standards like SMPTE ST 2110 (for broadcast video and audio) and the emerging AES67-2023 update. The AoIP ecosystem now encompasses high-channel-count systems, immersive audio formats (e.g., Dolby Atmos), and cloud-based production workflows. In these advanced scenarios, the choice between multicast and unicast may shift: cloud environments often rely on unicast due to virtual network constraints, while on-premises production facilities favor multicast for its deterministic behavior. AES67 remains the glue that ensures equipment from different vendors can exchange audio without proprietary lock-in. Understanding when to use each transport method is a foundational skill for anyone building modern audio networks.

Conclusion

AES67 provides a robust framework for audio over IP, enabling both multicast and unicast streaming to meet a wide range of professional use cases. Multicast excels in scalability and bandwidth efficiency, making it the standard choice for large-scale distribution of synchronized audio. Unicast offers flexibility, security, and per-stream customization, ideal for point-to-point applications and smaller deployments. By carefully evaluating the number of receivers, network infrastructure, synchronization requirements, and security needs, you can select the optimal streaming method—or combine both—to build a reliable, high-performance audio network. As the AoIP landscape continues to mature, mastery of these fundamentals will ensure your system remains adaptable and future-proof.