Implementing AES67 Timing Master Selection Across a Lawo AoIP Network

AES67 allows separate audio-over-IP devices to exchange uncompressed, synchronised audio over a standards-based network. In a large Lawo environment, the quality of that exchange depends on more than multicast routing and sample-rate settings. Every endpoint must share a reliable timing reference, and the network must select the right Precision Time Protocol (PTP) grandmaster when conditions change.

For radio facilities using Ruby consoles, Power Core nodes, VisTool, RƎLAY and AutoMix, timing should be treated as shared infrastructure. A well-designed PTP system supports clean audio handovers between studios, contribution rooms, control rooms and remote production spaces, while poor timing selection can create slips, clicks or intermittent loss of streams.

Australian broadcasters often operate across wide sites, separate buildings and regional locations. A Sydney network may connect multiple technical areas over fibre, while a Perth facility may need to account for longer transport paths and different support windows. Planning for the local broadcast market means allowing for staged upgrades, mixed-vendor equipment and the occasional late-afternoon “arvo” maintenance window.

Map The Timing Architecture

Begin by documenting every device that can provide or consume PTP. This includes Lawo Power Core audio nodes, mixing consoles, AES67-compatible third-party equipment, switches, gateways and any dedicated grandmaster clocks. Record each device’s PTP domain, profile, priority values, network interface and physical location.

The preferred architecture usually has two independent grandmasters, with each connected to a separate network path. A grandmaster may be a dedicated clock appliance with GNSS or other reference input, while a capable network device can provide a secondary source. The important point is that the selected clock must remain traceable, stable and reachable when a primary component fails.

Set The PTP Profile And Domain

AES67 commonly uses PTP version 2 with settings aligned to the AES67 media profile. All participating devices need compatible values for the PTP domain, transport, delay mechanism, announce interval and synchronisation interval. A device configured for a different domain will not join the same timing system, even if it is connected to the correct VLAN.

Use a dedicated media timing domain for the AoIP system rather than allowing unrelated corporate or facility networks to share it casually. Keep the configuration consistent across studios and technical cores. If a Lawo installation includes several operational zones, document whether they use one common timing domain or deliberately isolated domains with defined gateway behaviour.

Select Grandmasters With BMCA

PTP uses the Best Master Clock Algorithm to select the active grandmaster. The decision is influenced by clock quality, accuracy, stability, priority and identity. Lower priority values generally make a clock more preferable, so set the primary and secondary grandmasters deliberately rather than relying on factory defaults.

A practical arrangement is to give the preferred clock the best priority and the backup a slightly lower preference. Avoid making every device eligible to become grandmaster. If a Power Core node, switch or third-party endpoint unexpectedly announces itself as a superior source, the network may change timing masters during normal operation.

For large facilities, review Announce messages and BMCA state during a controlled failure test. Disconnect the preferred grandmaster, observe the election, and verify that the backup assumes control without audio services losing lock. Restore the primary and confirm whether the intended reversion behaviour is stable and predictable.

Build A Network That Carries Timing

PTP traffic needs a network design that treats timing packets as operationally important. Use managed switches with documented support for PTP, multicast handling and boundary or transparent clock functions where appropriate. Keep media VLANs consistent across the Lawo core, studio switches and inter-building links.

Boundary clocks can reduce the scale of a PTP domain by regenerating timing for downstream segments. Transparent clocks can correct for residence time through supported switches. Mixing these modes without understanding the vendor implementation can produce confusing results, so test the actual switch models and firmware used in the facility.

Fibre is often the sensible choice between buildings or technical rooms, particularly where electrical isolation and long cable runs matter. In an Australian campus, a fibre path between a main studio and an OB preparation area may be more dependable than extending copper through multiple plant rooms. Specialist advice from optical timing specialists can help when fibre, clock distribution and network timing intersect.

Coordinate Lawo And AES67 Endpoints

Configure Lawo devices to use the selected PTP domain and verify that their clock status reports the expected state. Power Core and other networked audio resources should show a locked or synchronised condition before they are placed into production service. Check sample rate, packet time, stream format and multicast addresses as separate items; timing lock alone does not guarantee an interoperable AES67 stream.

Ruby consoles and VisTool workflows may depend on many network audio sources at once. Test sources from different studios, contribution paths and control positions rather than checking one local stream. RƎLAY virtual radio tools and AutoMix processing should be observed under realistic load, including source changes and redundant-path operation.

Test Failover And Monitor Drift

A commissioning test should cover loss of the primary grandmaster, loss of a timing uplink, switch restart and recovery after a power event. Measure the time required for a backup clock to become active and confirm that endpoints remain within their acceptable lock range. Watch for audio artefacts, stream interruptions and devices that fail to return automatically.

Monitoring should include PTP state, offset from master, path delay, announce receipt, clock identity and grandmaster changes. Export these values to the facility’s monitoring platform if possible. Alerts are more useful when they distinguish a brief clock transition from a persistent fault, especially for stations operating across several Australian cities or regional sites.

For configuration reviews, fault analysis and product-specific guidance, the Lawo support team can help correlate device status with the wider Broadcast 3.0 workflow. Keep exported switch logs and PTP event records with the Lawo project documentation.

Document A Repeatable Commissioning Process

Use a written test sheet so that the same checks can be repeated after firmware upgrades, switch replacement or studio expansion. Record the expected master, the backup master, the permitted domains and the alarm thresholds. Include a simple network diagram showing clock sources, boundary points and redundant paths.

Area	Verification	Desired result
Grandmaster selection	Primary and backup priorities	Intended clock wins BMCA
PTP domain	Lawo and AES67 endpoints	All required devices synchronise
Network transport	Multicast and PTP forwarding	Announce, Sync and Follow_Up reach endpoints
Failover	Primary clock removed	Backup takes over without unstable elections
Audio operation	Streams across studios	No slips, clicks or sustained loss of lock
Monitoring	Offset and master identity	Alarms identify actionable faults

The essential principle is simple: select timing masters intentionally, carry PTP through a controlled network, and prove failover before the system goes live. On a large Lawo AoIP network, reliable AES67 performance begins with a disciplined clock hierarchy and ends with evidence that every endpoint responds correctly when that hierarchy changes.