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

To answer the questions specifically:

If the talker is the grandmaster and is either only a talker, or uses LOCAL as the clock, then PTP and FIFO will be the same in the listener

FIFO/STREAM derived are the same thing and refer to recovering the clock from the PTP timestamps in the stream. The talker isn't really important, other than it generated the stream.

Consider this stream arriving in the listener:

sample	- timestamp
0	- 0
1	- 1.001
2	- 2.002
3	- 3.003
4	- 4.004
5	- 5.005
6	- 6.006
7	- 7.007
etc

(ok - so 61883-6 packets in 1722 packets only have a timestamp every 8 samples, but you could in principle derive the intermediates)

Its clear that the stream contains a sample every 1.001 PTP time units. So, we know that the stream rate is 1/1.001 Hz. If the nominal rate that the stream is advertized at is 1 Hz then we can see that it is running slow.

So, our clock recovery should set out playout rate to 1.001Hz. However, doing this is slightly tricky since the audio clock is derived from the listener's system clock, and the timestamps are in PTP clock time units. We use a PID loop to change the audio output to the correct stream rate independent of this.

The way it works is:

when the I2S plays a sample out, it sends to the FIFO a timestamp. This timestamp is a local ref clock timestamp. Some samples in the FIFO are marked with a PTP timestamp (only ever one at one point in time, although this is an implementation detail). When the clock recovery system runs from time to time, it uses the PTP time that the sample should have been played, and compares this to when it was actually played. The time when it was actually played is found by converting the ref clock of actual playout into a PTP timestamp by asking the PTP server.

A PID loop then tries to reduce this error in playout time to zero by adjusting the audio clock. Consequently, there is never a piece of code which counts samples and divides by timestamp differences to get sample rate, because a PID controller doesn't need this info. It just uses closed loop control to make it happen without forcing the output.

-----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