On Fri, Mar 04, 2011 at 11:15:30PM -0600, Duncan Gray 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.
how could a slave clock kill the clock network ? > 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.) so you are saying that the avb stream needs to have a microsecond accuracy when i send out audio packets ? i find that hard to believe. > > 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. nobody ever talked about creating a grandmaster clock in software. > > 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. why shouldnt the receiver just clock the system ? -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
