Re: [LAD] AVB applications

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.