Latency and Clock Recovery Performance in a Dante System, part two (Broadway)

Introduction

Two shipping dante audio io units were connected as per the diagram below. The devices were gigabit devices utilising the Broadway chip.

An investigation into the latency and clock recovery performance was undertaken.

Dante Controller latency setting

The 'Device Latency' (dante terminology, that doesn’t equate to AVB terminology) was set to 1ms:

A stereo connection was made from one device to the other using the dante controller, and the reported ‘latency’ shown in the receiver device was 333uS. This is less than the 437uS of the Ultimo devices, which is unsurprising as the gigabit link both reduces the length of any interfering traffic and also reduces the time to send each audio packet. The device contains a Marvel 88e series ethernet switch IC however (which the Ultimo devices don't), so if we assume that the latency is measured i2s->i2s (as per the Ultimo devices) then the latency includes the latency of the embedded switch.

A click track was applied to the sender device's analogue input (L) and the input signal was scoped, along with the output of the receiver device (analogue out L). The measured latency (including all ADC/DAC latencies) was 2.051ms:

Subtracting the 1ms 'network latency' from the total measured latency reveals a device latency (sender plus receiver) of 1051uS. This is almost double that of the Ultimo based devices. Perhaps these devices use an ADC and DAC both with digital filtering. Or perhaps there is an additional (device specific) processing stage accounting for the additional device latency. Let's investigate the i2s->i2s latency...

The units are opened up, and probes are attached to the i2s data lines going from ADC to Broadway in the sender unit, and from the Broadway to DAC in the receiver unit. The measured i2s->i2s latency is 1.062666ms:

Another capture, showing 1.062292ms:

Repeating a few times gives a small variation of around 300ns, so we can clearly state that the Broadway has less variance on the latency than Ultimo. Perhaps Broadway phase aligns the FSCLKs, let's see...

Clock Recovery and FSCLK phase

Probing the FSCLK on both the clock sender (yellow) and clock follower (purple) shows that clock recovery with Broadway is a lot better than with Ultimo in that it attempts to align the FSCLK edges at least! The recovery speed is also a lot snappier than with Ultimo.

Broadway has a 'nice' feature whereby if a new device appears on the network, the FSCLK wont actually be started until the device has somewhat synced clocks with the leader. I assume that under the hood there is some rapid clock recovery going on before the external FSCLK signal is enabled. This can be seen in the following capture:

From powering on the new follower device to the FSCLK being started, about 15 seconds pass, so there is definitely time for leader negotiation to take place and clock recovery to coarsely adjust the clock before the FSCLK signal is un-gated to the external circuitry.

This feature makes it more difficult to measure the clock recovery performance however, because we can't see it happening under normal circumstances, but if we let two devices power up as leader on separate networks, and then join them together we can see the full clock recovery process happening with the FSCLKs enabled.

Each device is connected to its own switch:

The two switches are connected together, forcing the lower priority device to switch into follower mode, with FSCLK enabled:

(note, the two devices were PoE devices, thus they each required connection to a PoE switch. Otherwise the two devices could have simply been connected together.)

Watching the two FSCLKs sync on the scope reveals some pretty interesting things about how Broadway handles clock recovery. Realignment of clocks that have slipped out of phase by around 180deg is, in my opinion, 'acceptable', taking about 15 seconds to phase align to within about 1/16 sample period. This was repeatable, each time the two switches were disconnected the FSCLKs of the two devices were allowed to slip by about 180deg, and then the switches were linked together again and the FSCLKs would sync:

Curiously, if the clocks were allowed to slip more than 180deg, then on reconnection the follower would pull the FSCLK back to the original position, not the 'nearest' edge of the leader FSCLK (as our devices do). Perhaps this is considered a 'feature' by Audinate, because if audio were flowing then it would allow the follower to realign the audio without any dropped samples or repositioning of the stream after a period of freewheeling, but what happens if the clocks drift apart by many samples? Let's find out. In this test we let the FSCLK of the follower drift for a minute or so, causing it to be perhaps 2 or three frames out from its original position. When the two devices were reconnected together, we witnessed this:

We certainly wouldn't allow behaviour like that in our devices!

Letting the follower freewheel for a little longer (a few minutes) and the follower seems to try to realign to the original position, after which it gives up (after pulling back about 20 frames) and then does a rapid re-sync. It's hard to see exactly what's happening here, but again, it's not something we would attempt in any of our AVB implementations:

Audinate clearly maintain some kind of 'position' for the FSCLKs, and use clock recovery to try to get back to where the 'position' was originally. This differs from our approach which is to always align to the nearest frame edge, which permits faster locking with less FSCLK slewing.

Turning on infinite persist we can see that the measured wander (measured over about one hour) was about +-250nS.

Conclusions

Broadway definitely does a better job of clock recovery than Ultimo. FSCLK edges are aligned, and clock recovery, when powering a new device onto a network, is reasonably quick and once locked, wander is minimal. The 'feature' of muting the output and gating the FSCLK until reasonably well synced does perhaps hide some ugly implementation details which can be seen when recovering from freewheeling periods.

The latency set in the Dante controller is again i2s->i2s latency (same as Ultimo) with an additional offset of about 62uS. Is it coincidence that at 48kHz the length of three sample periods is 62.5uS? I suspect not. It appears that Broadway adds three samples of latency to the configured value set in Dante Controller.

Investigation into an Ultimo based solution (for comparison) can be found here.

Both Dante devices performed very badly compared to Sienda's solutions. For comparison, a Sienda STM32 based solution is evaluated here.