xcore/sw_avb — comment on commit 3efd9c70a80eaa697e5d3292aac732e6256cff24
File:  line 0
By DavidNorman:

There are three real clocks in a talker to listener config, regulated by the PTP gransmaster's crystal, the talkers crystal and the listeners crystal.

The PTP reference, which is assumed to be transmitted correctly to all other nodes, is a virtual clock which each unit has access to. From it, they know how fast or slow their own local clock is compared to the grandmaster.

two communicating audio endpoints are not always going to have the grandmaster as one of them, and neither are they sure that the samples generated at the talker are going to be exactly at the nominal sample rate compared to that frequency. for instance, the talker may be connected to a 48kHz DAT machine which is outputting 48001 kHz of samples via that SP/DIF to the talker, with respect to one second of PTP time. Consequently, the PTP timestamps in the stream of audio may not increment by 1/48000 sec for each sample.

In the listener, you have a stream of samples, and some sort of audio hardware to push them into. If that audio hardware generates its own clock, so you cannot control the rate which the audio hardware will consume samples, then you have a problem. You may be receiving samples at 48001Hz from the network, but the audio hardware is clocking them into itself at 39999Hz. For this situation, you can do nothing but occasionally knock out or add a sample. The XMOS s/w doesn't deal with this case at the moment.

If, however, the listener does have control of the clock stream, then it can do one of two things. It could try to make the audio hardware consume the audio at the same rate it comes in from the network. This is MEDIA_FIFO_CONTROLLED. It works by comparing the PTP time which the sample was actually played out, against the time when the PTP timestamp says it should have been played out, and minimises that time using a PID controller.

This scheme can cope with the case where the network stream delivers data at 48001Hz compared to the PTP wallclock.

Alternatively, you could assume that the network audio source (the talker) is adjusting its own audio clock so that it produces audio at exactly 48000Hz compared to the PTP clock. In this case, the PTP_DERIVED will attempt to make the rate of consmption of audio samples equal to exactly 480000Hz compared to the PTP clock too. Note that this only works when the audio source clock at the talker is able to be controlled by the firmware (as it is in the XMOS solution with I2S master). If you were an SP/DIF slave, or maybe also an I2S slave, then you would not have the option to alter the audio clock rate, and therefore PTP recovery in the listener would not be a good option.

The PTP_DERIVED is not really a valid clock recovery scheme for a non-closed system. Any real audio system will use MEDIA_FIFO_DERIVED (if any), since a media stream is the only really valid source of media timing info.

In a large professional studio, there is another clock recovery scheme widely used (expecially in TV). A second stream, a sync/black stream, is sent to all equipment. Each piece of equipment is responsible for sourcing media at the rate of the sync stream. Sink devices also lock their media frequencies to the recovered sync clock, and so all equipment is kept in frequency lock by the explicit sync stream. This stream will often carry the VITC or SMPTE time of day information. Typically, listeners/sinks will still recover phase lock from the incoming media streams, to account for the differing lengths of cables between equipment.

Hope this helps.

In short:

Ideally don't use PTP unless all of the units are doing it.
Use LOCAL on the master media unit - doesn't have to be the only talker, but should be the most important one
Use MEDIA_FIFO for all others.

-----Original Message-----
From: Oliver Keller [mailto:reply@reply.github.com]
Sent: 21 November 2011 14:02
To: David Norman
Subject: Re: [sw_avb] Disable the I2S slave until we have a complete solution (3efd9c7)

don't worry, since the code is deactivated through #if/#endif, I didn't expect it would run out of the box :-) The AVB guide link is broken at the moment (or the proxy over here), but I'm pretty shure it didn't include enough details about the media clock modes.

Following your description, I assume that if the talker is also the PTP grandmaster, FIFO and PTP mode should both result in the same behaviour on a listener. This would mean the PLL is adjusted in both modes, which I think is the case looking at the code.
But with the PTP mode on a listener I get regular interruptions and re-locking action. (but actually, I thought it was working previously in both modes, with a much older stack... I'm not sure now) Or are the XMOS talkers simply not meant to transmit a stream that could be received on a listener in PTP mode? (note I don't use an AVB switch currently). So far I thought, the FIFO mode could be read as "stream derived". Now I'm wondering if "fifo derived" (at a listener) referes to the buffering fifo at the source (in the talker) or the listener itself. Yes, I looked at the code, a lot. But it's still not 100% clear to me...
I guess it's of particular interest to AVB integrators in general, since I believe that type of implementation variants at a listener are not covered by the AVB standard itself.

---
Reply to this email directly or view it on GitHub:
https://github.com/xcore/sw_avb/commit/3efd9c70a80eaa697e5d3292aac732e6256cff24#commitcomment-734959