[LAD] AVB applications

[Folderol]

On Fri, 04 Mar 2011 23:15:30 -0600
Duncan Gray <duncang at catraeus.com> wrote:

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

Thanks for this. Very informative, although *way* above my abilities :(

-- 
Will J Godfrey
http://www.musically.me.uk
Say you have a poem and I have a tune.
Exchange them and we can both have a poem, a tune, and a song.