Testing AoIP latency in a Lawo network before a live broadcast

When the on-air light flips red in a Sydney studio or a Perth control room, every millisecond between a microphone and a transmitter matters. Audio over IP has reshaped how Australian broadcasters move sound between rooms, cities and regions, but it has also added a layer of timing complexity that analogue chains never had. Before a live broadcast, engineers need a clear picture of where delay enters the signal path and how much of it is tolerable for the format on air.

A Lawo network, built around Power Core nodes, Ruby consoles and the RƎLAY virtual toolbox, gives engineers a unified environment where latency can be measured at predictable points. Done well, a pre-show latency check is less about chasing a magic number and more about confirming that the system behaves the way it did during commissioning, regardless of whether the signal ends up in a Melbourne post suite or a remote commentary booth in Townsville.

What AoIP latency really means in a broadcast chain

Latency in an IP audio system is rarely a single value. It is the sum of packetisation time at the source, switching delay inside the network, processing buffers at each node, and reconstruction time at the destination. AES67 and SMPTE ST 2110 streams add their own framing overhead, and a single Power Core hop can introduce a few milliseconds that seem trivial until they accumulate across a multi-point route.

For radio, the tolerance is tighter than for most production tasks. A presenter listening to a delayed mixback, a remote announcer hearing studio talkback, or a cross-faded network feed joining an ARN or Southern Cross Austereo stream will notice even small offsets. That is why latency is often described in terms of perceptual transparency rather than raw numbers: the goal is a chain that feels instantaneous to talent on air.

Building a pre-broadcast testing routine

A reliable test routine starts well before the first item on the rundown. Engineers in Brisbane or Adelaide often schedule a full chain verification ninety minutes out, especially for shows that involve intercity links or remote guests. The first step is to confirm that every device on the network has synchronised to PTPv2 or the chosen precision time protocol, because a single unsynced node can add jitter that masquerades as extra delay.

The next step is to walk the signal path from source to destination with a known test signal. A click track or a 1 kHz pulse sent through the same routes that programme audio will use gives a baseline that can be compared with previous shows. Recording both ends with a portable recorder or a laptop running Reaper, then aligning the waveforms in a DAW, exposes the actual end-to-end delay rather than the theoretical value printed on a datasheet.

Measuring and interpreting delay across your network

Once a baseline exists, the trick is to read the numbers the Lawo environment exposes without over-interpreting them. Power Core dashboards show buffering and processing load per stream, while VisTool screens can be configured to surface the round-trip time of each AES67 flow. These readings are most useful when compared with measurements taken during commissioning or the previous successful broadcast, not as absolute targets.

Geography plays a role too. A signal travelling between, say, a Hobart studio and a Sydney transmission point passes through several switches and possibly a long-haul link, and the Australian regulations administered by ACMA expect broadcasters to maintain consistent audio quality regardless of route. Logging latency over several weeks reveals patterns, such as a switch that drifts at certain times of day, before they ever become on-air problems.

Tools and workflows inside the Lawo ecosystem

Lawo's broadcast stack is designed so that latency checks fit inside existing workflows rather than sitting beside them. Ruby consoles allow operators to recall specific monitoring layouts that show delay at a glance, while VisTool can be scripted to flag any stream whose buffer depth crosses a user-defined threshold. For smaller stations and outside broadcasts, the RƎLAY virtual patchbay makes it straightforward to reroute test signals through the same paths programme audio will use, then revert to the on-air configuration in seconds.

Power Core itself is a useful test endpoint. By sending a signal in through one port and returning it through another, engineers can measure the node's own contribution to delay and isolate it from the rest of the network. When this is done regularly, the data builds into a profile that makes anomalies obvious, much like a reference mix that lets a producer hear when a fader has drifted.

Putting it all together on the day

The final pre-broadcast window is rarely long, so the routine has to be short and repeatable. Many Australian engineers condense the process into a checklist: confirm PTP lock, send a pulse through the show path, check the round-trip reading on the VisTool panel, listen to a short loop of test material on the actual monitor speakers, and only then hand the studio over to the presenter. Each step takes seconds once it becomes habit.

If anything looks unusual, the network is treated as suspect until proven otherwise. The temptation to assume the issue is at the far end is strong, especially when the far end is a remote site several hundred kilometres away, but experience shows that most latency surprises live in the local patch bay or a recent configuration change. A calm, methodical pass through the routine catches these before the audience hears them.

What matters most is that the team trusts the numbers and the routine. When latency is measured in the same way, with the same tools, before every live broadcast, the results become a shared reference rather than a guess. That trust is what keeps a Lawo network ready for the moments that define a station's day, whether the signal originates in a flagship city studio or a small regional outpost across the continent.