Implementing AES67 standards in a large-scale radio network can significantly enhance audio interoperability and streamline operations. This case study explores how a national radio network successfully adopted AES67 to improve their broadcasting infrastructure, delivering measurable gains in synchronization, reliability, and cost efficiency. The following account details the challenges faced, the decision-making process, the phased implementation, and the transformative results achieved.

Background of the Radio Network

The national radio network operates over 40 regional stations spread across a diverse geographic area, serving millions of listeners daily. Prior to the AES67 project, each station used a patchwork of legacy audio protocols — some proprietary, some older open standards like MADI and AES3 — resulting in significant interoperability issues. Audio synchronization across stations during live simulcasts was a persistent problem, with delays ranging from 5 to 20 milliseconds. Content sharing required manual conversions, and remote production setups often demanded expensive dedicated lines and custom bridging hardware. The engineering team spent an average of 15 hours per week troubleshooting audio routing mismatches and sync errors, draining resources that could have been used for content innovation.

The network’s engineering team, led by the Director of Technology, recognized that the existing infrastructure was not scalable. Budget constraints limited the ability to replace all equipment at once, and the diversity of vendors (including mixing consoles from Calrec, Lawo, and Yamaha, plus codecs from Tieline and Comrex) made protocol unification essential. After a six-month evaluation period, AES67 emerged as the clear choice over proprietary AoIP solutions such as Dante or Ravenna due to its open standard nature and guaranteed cross-vendor compatibility. The team also considered SMPTE ST 2110-30, which embeds AES67, but determined that starting with pure AES67 would allow the broadest device support and a smoother transition path for their existing infrastructure.

Why AES67 Was Chosen

The technical team selected AES67 because of its status as an open, profile-based standard for audio-over-IP interoperability, formally defined by the Audio Engineering Society. Unlike proprietary systems that lock organizations into single-vendor ecosystems, AES67 ensures that equipment from different manufacturers can discover, synchronize, and exchange audio streams with predictable latency and quality. Key deciding factors included:

  • Multi-vendor interoperability — AES67 is supported by nearly every major broadcast equipment maker, including Calrec, Lawo, Yamaha, Digigram, and Axia. This allowed the network to keep existing consoles and codecs while adding AES67 capability via interface cards or firmware updates.
  • No licensing fees — The standard is freely implementable, avoiding recurring costs associated with proprietary solutions. This was critical for a public-service broadcaster with strict cost-control mandates.
  • IEEE 1588 Precision Time Protocol (PTP) integration, enabling sub-millisecond synchronization across geographically distributed sites. The network’s existing timing infrastructure from GPS and NTP was not accurate enough for the demanding phase alignment required in live simulcasts.
  • Flexible sample rates and bit depths — Support for 24-bit, 48 kHz and up to 96 kHz ensures future-proofing for high-resolution audio. The network chose 48 kHz/24-bit as the baseline to maintain consistency with legacy archive formats.

The network also evaluated SMPTE ST 2110-30 (which embeds AES67) and Ravenna, but determined that pure AES67 offered the broadest device support for their existing infrastructure. Ravenna, while closely related, had fewer supported codecs in the field at the time. The open nature of the standard meant that the network could negotiate competitive pricing from multiple vendors, rather than being tied to a single supplier’s roadmap. A pilot test at the flagship station demonstrated that AES67 streams could coexist with existing IP traffic on a segmented network, with measured latency under 1 millisecond end-to-end.

Implementation Process

The rollout was planned in four phases over 18 months, designed to minimize disruption to daily broadcasts while building internal expertise. The project team included five senior engineers, two IT specialists, and a project manager reporting to the CTO. External consultants from an AES67 integration firm provided peer review and commissioning support. A steering committee of station managers and the head of programming ensured that operational needs were always considered in technical decisions.

Phase 1: Network Readiness and Equipment Audit

Each station underwent a thorough audit of existing network infrastructure: switch models, cabling (Cat6a minimum required), power over Ethernet availability, and bandwidth utilization. The core network was upgraded to support IGMP snooping for multicast traffic, and a dedicated VLAN for audio was configured to isolate AES67 streams from data and control traffic. PTP grandmaster clocks were installed at the main hub and two regional distribution centers, using the default profile defined in AES67-2018 (IEEE 1588-2008). Redundant PTP paths were established to ensure failover without losing synchronization. The team also conducted a detailed bandwidth analysis: each AES67 stream at 48 kHz/24-bit consumes approximately 4.6 Mbps of multicast traffic. With up to 64 simultaneous streams at larger stations, the network core needed at least 300 Mbps of reserved capacity, which was easily accommodated after upgrading to 10 GbE backbone links.

Phase 2: Equipment Integration and Compatibility Testing

Gradual integration began at the largest station, where the main Calrec Artemis console was updated with a Ravenna/AES67 interface card. Simultaneously, Tieline Bridge-IT codecs were configured to output AES67 streams, replacing the legacy G.722 and APT-X connections. The team developed a compatibility matrix documenting every device’s AES67 capabilities — sample rates supported, PTP domain configuration, and RTP payload types. Some older codecs required firmware updates to expose AES67 modes; in a few rare cases, the vendor had to release a specific patch. Throughout this phase, the team used Neutrik opticalCON fiber runs for long-distance connections between studios and transmitters, ensuring no degradation in PTP accuracy over distances exceeding 100 meters. A temporary test rig was set up in the engineering lab to validate every combination of sender and receiver before any device was placed into production.

Phase 3: Staff Training and Operational Playbooks

Training was delivered in two tiers. The engineering team attended a two-day intensive workshop covering AES67 transport, PTP timing, and troubleshooting using Wireshark and AES67-specific analyzers. Operators and production staff received half-day sessions focusing on daily workflows: how to route audio streams using the new AoIP control interfaces, how to recognize synchronization errors, and how to escalate issues to engineering. A playbook was created for each station, documenting IP addresses, stream IDs, and multicast group assignments. The playbook also included step-by-step recovery procedures for common failure modes, such as PTP clock drift or multicast group timeout. Additionally, a mobile app was developed that allowed operators to quickly look up the stream assignment for any remote feed or studio, reducing confusion during fast-paced live events.

Phase 4: Full Rollout and Continuous Improvement

With the flagship station operating stably for three months, the rollout expanded to all 40 stations at a rate of two per month. Each station was cut over to AES67 during a scheduled maintenance window (typically 0200–0600 local time). Post-cutover, the engineering team monitored audio sync and latency using a proprietary measurement tool based on ITU-T J.209 recommendations. Any station showing jitter above 50 microseconds was rechecked for PTP boundary clock connectivity. By the end of the rollout, all stations were operating on AES67 with a measured end-to-end latency of 0.9 ms (±0.2 ms). A continuous improvement process was established: monthly reviews of synchronization logs and network traffic patterns, with quarterly firmware updates for PTP-capable switches.

Results and Impact

Six months after completion, the network documented the following quantitative and qualitative gains:

  • Audio synchronization error reduced by 95% — Simulcast delays dropped from an average of 12 ms to under 1 ms, enabling seamless regional programming without audible artifacts. This was particularly important for live news coverage where multiple correspondents contributed from different locations.
  • Interoperability improved by 100% — Every device from every vendor now communicates without proprietary gateways, simplifying upgrades and allowing mix-and-match procurement. The network saved an estimated $200,000 annually in bridging hardware and protocol conversion licenses.
  • Remote production setups cut from 45 minutes to 8 minutes — Connecting an outside broadcast truck now involves simply assigning an AES67 stream to the correct multicast group, versus configuring multiple hardware bridges. This freed up technical staff to handle more productions per week.
  • Capital expenditure on audio routing hardware reduced by 30% — The network replaced expensive proprietary matrix switches with standard managed switches, and leveraged software-based routing via AES67. The savings were redirected toward upgrading studio acoustics and monitoring systems.
  • Operational reliability increased — PTP-based synchronization eliminated the manual calibration required under the previous system, reducing on-air audio drift incidents by 80%. The network’s mean time between failures (MTBF) for audio routing improved from 90 days to over 400 days.

The network also reported significant improvements in staff productivity. Operators no longer needed to maintain separate knowledge of multiple audio protocols; a single playbook and control interface covered all stations. The IT team found that network monitoring for audio streams became simpler: they could use familiar SNMP traps to detect multicast stream loss or PTP clock issues, rather than relying on vendor-specific diagnostics. Furthermore, the ability to quickly reassign audio streams allowed the network to launch a new regional digital radio service within weeks, rather than months, by reusing existing IP infrastructure.

Lessons Learned

The implementation revealed several important insights for future AES67 adopters. First, the importance of PTP profile consistency cannot be overstated. The team initially attempted to use the default IEEE 1588 profile, but discovered that certain devices required the AES67-specific profile to negotiate correctly. Once they standardized on the AES67-2018 profile (which mandates a specific set of PTP attributes), all devices synchronized properly. Second, network segmentation must be carefully planned: while AES67 traffic is inherently multicast, mixing it with legacy control traffic on the same VLAN caused occasional packet loss. The team resolved this by dedicating a separate VLAN for audio and implementing traffic shaping for PTP messages using DiffServ DSCP 46 (Expedited Forwarding). Third, comprehensive documentation of stream assignments proved critical for troubleshooting, especially during temporary line-ups for sports events or breaking news. The network developed a web-based stream registry that allowed engineers to quickly see which multicast groups were in use and which were available.

Future Expansion Plans

Building on the success of AES67, the network is now exploring the adoption of SMPTE ST 2110-30 for video contributions, which shares the same audio layer as AES67. A trial at the main production center demonstrated that AES67 audio streams can be seamlessly embedded into ST 2110-30 video streams, allowing unified IP transport for both media types. The network is also evaluating AES67 redundancy features, such as stream encryption using AES67 Stream Encryption (ASE) and redundant unicast streams, to meet emergency broadcast requirements. In the longer term, the engineering team is researching the integration of AES67 with cloud-based production workflows, using RAVENNA for remote contribution and AES67 for synchronization between cloud and on-premises resources. A proof-of-concept with a major cloud provider showed that with appropriate network optimization, AES67 streams could maintain sub-2ms latency over distances up to 500 km, opening the door to centralized production for regional stations.

Conclusion

This case study demonstrates that adopting AES67 can lead to substantial operational benefits for large broadcast networks. By embracing an open standard, the national radio network not only solved its interoperability and synchronization challenges but also achieved significant cost savings and operational agility. The success of this project serves as a model for other organizations seeking to modernize their audio infrastructure without being locked into a single-vendor ecosystem. The key takeaways for any broadcaster considering AES67 are: invest in thorough network readiness assessment, prioritize PTP clock infrastructure, document everything, and phase the rollout carefully to maintain on-air reliability. With these practices, AES67 can be the foundation for a scalable, future-proof broadcast audio network. As the industry moves toward all-IP production, standards like AES67 and ST 2110 will only become more essential. Organizations that start their adoption now will be well positioned to take advantage of emerging capabilities in remote production, cloud integration, and immersive audio.