Re: [LAD] AVB applications

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
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev