[LAD] AVB applications

torbenh torbenh at gmx.de
Fri Mar 11 19:55:55 UTC 2011

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

More information about the Linux-audio-dev mailing list