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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Mar 5 08:15:02 2011