[LAD] AVB applications

[Duncan Gray]

This is to bring a discussion from the Jack Dev list to this more 
appropriate forum as suggested by Arnold Krille.

First, I hear lots of people seemingly thinking that AVB (IEEE 1722) and 
the IEEE 1588 version of Precision Timing Protocol can be done in the 
kernel.

It cannot and it must not.  They both need hardware assist.  Period.  A 
timestamp is specified to be inserted based on the leading edge of the 
header immediately after the preamble.  If anyone ever makes some 
neighboring equipment that has done these with the required precision, 
then you will kill that clock network and there will be yet another good 
reason not to bring Linux to the workplace.
The ONLY exception is that if the listener is a stream-to-disk system, 
then the timestamp system can simply be ignored.  Such a listener will 
never turn on PTP, but that won't hurt, because it will just ask for the 
1722 stream and the talker will spit it out without knowing that that 
node doesn't play PTP.

The version of PTP that is used in AVB is from the 802.1AS 
specification.  The acronym PTP is now an ambiguous one that has at 
least these two uses, and I have heard some other hardware-assisted 
networked timing schemes called PTP.

IEEE 1588 specifies an epoch-based struct with 48 bits of seconds (This 
gives 8.9 million years before a "y2k" hits IEEE 1588) and a 32-bit 
number that specifies nano-seconds.  the 802.1AS sub-spec also uses this 
epoch-based timestamp.

PTP maintains one suite of transactions to keep itself timed.  This is 
blind to AVB.

AVB creates Word Clock timeframes using the PTP wall-clock that MUST be 
made available to the 1722 layer.  IF YOU HAVE PTP, then you can 
synthesize predictive wallclocks using a buffer-full scheme in a 
PTP-capable NIC.  That NIC has to be configured to pay out the frames 
per the 802.1Qav forwarding and scheduling spec.  This is how streamers 
will deliver streams that are well-timed, low-jitter streams.  There are 
fruit companies doing this as we speak with new NICs that have been 
enabled from Broadcom and Marvell (and any host of others.)

It is possible to fake a GrandMaster clock using kernel-timed 
calculations.  The Best Master Clock Algorithm (BMCA) of a two-node 
system will be forced to accept such a sloppy clock and the slave will 
achieve lock, but with jitter that will fail a normally specified PTP 
system.  Noisy environment listeners will not hear this, but clean 
listening will reveal the various artifacts of such jitter.

You can just make a leaky-bucket PLL at a receiver and use the DPLL 
frequency to inform SRC.  This hack will be un-noticed by the average 
media-player person, but not by the critical listener.

When the 1722 timestamp is constructed, it is a complex assembly from 
the 802.1AS timestamp.  The 802.1AS timestamp is a two-part thing, as 
specified above with its first part being simply seconds.  This will not 
roll over in the lifetime of Linux, our species or even our continents, 
let alone a recording session.  The second part is specified to roll 
over at decimal one billion-1 = 999999999 = 0x 3B9ACBFF.  The timestamp 
in IEEE 1722 rolls over at unsigned long = 4294967295 = 0xFFFFFFFF, 
which is 4.294967296 seconds.  I apologize for quoting "weeks between 
rollover" in the previous thread.

IEEE 1588 and IEEE 1722 are Ethernet-Only protocols, do not shoe-horn 
them into IP.

I have heard lots of people say that AVB is just some thing for consumers.
go to http://grouper.ieee.org/groups/1722/ and hover over some of the 
names to find where they work.  It was, in fact, designed FIRST to very 
easily accommodate Pro Audio:

Reliability.
Multiple-Node Synchronization without the need for Sample Rate Conversion.
Low-Jitter.
Unlimited (at least not limited by the protocol, only the bandwidth) 
channel count.


And then it would be a trivial subset to get two - or 5.1, 7.1 any 
surround count - channels to go from my CD player to any media player 
over some LAN. (However, as of two autumns ago, they were still 
kvetching over Wi-Fi.)

Finally, Yes, the CLOCK_REALTIME can be very simply pasted from a good 
PTP instance.