Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2

PrevNext  Index
DateFri, 04 Mar 2011 07:18:36 -0600
From Duncan Gray <[hidden] at catraeus dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToChris Caudle Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2
Follow-UpAdrian Knoth Re: [Jack-Devel] Writing an IEEE 802.1BA (AVB) compliant network backend for Jack2
On 03/03/2011 10:42 PM, Chris Caudle wrote:
> On Thu, March 3, Duncan Gray wrote:
>> I have been spoiled by pro audio.
>> I am dis-satisfied if the clock jitter is worse than 500 ps. 50 ps
>> RMS was my goal and no kernel-timed PLL will ever get there.
> You would never use a software PLL to drive the sampling clock of an ADC
> or DAC.  It would have to be a hardware clock, with a very long time
> constant (low corner frequency on the PLL loop filter) to keep the
> sampling clock and the PTP derived clock in synchronization.
I have used software loops to manage PLLs for quite some time now, I 
believe my first was some time in the late '80s. It is a hard-real-time 
problem, the kernel might not be up to it, but the time constant of the 
VCO on a hypothetical time-source (Audio word clock) card would be the 
defining element for phase jitter generation due to kernel timing 
jitter. It has been done many times in other OS systems, why not Linux 
if the hardware existed?
>> Once again ... AVB was designed for this very accurate timing
>> domain, the anticipated case was to have a PLL directly in the NIC
>> to derive a word clock.
> Yes, the ADC or DAC would definitely have a PLL.  You don't need that in
> the PC, however.  It gets confusing now that both the PC and the audio
> equipment have network interfaces.  We need to be clear what type of
> device we are talking about, because the requirements are drastically
> different.
>
"It gets confusing now that both the PC and the audio equipment have 
network interfaces. " says it upside--down. The difficulty is when the 
PC and the Network both have audio interfaces. AVB puts Audio into 
Ethernet, which is to say that there is a virtual audio card at the 
other end of the Ethernet wire. This means that two word clocks need 
either SRC on their streams, or one needs to PLL to the other.
>> True. But be careful of the word master clock. This is a reserved
>> word in the PTP dictionary and can only be the physical Ethernet
>> bit clock in the NIC.
> Are you sure about that?  I've been looking at all the 1588 information I
> can find, and I don't see anywhere that the PTP clock is referenced to the
> Ethernet phy clock.  Am I missing something?  I'll see if I can get the
> full IEEE spec.  If you have a reference to a particular section in the
> standard, I'll take a look.  I have the 2002 spec, but the IEEE server is
> having problems serving up the 2008 spec, so I'll have to get that sorted
> later.
>
The work Grand Master is the specific word in the 1588.
>> The soundcard interrupt can then be a 1788 Stream master clock
>> carried within the PTP framework.
> You've mentioned 1788 several times.  Do you actually mean 1588?  Or is
> there some connection between IEEE1788 and clock synchronization?  I
> suspect you mean 1588, "IEEE Standard for a Precision Clock
> Synchronization Protocol for Networked Measurement and Control Systems."
>
Did you know that AVB is mostly specified, at the low level, by IEEE 
1722? I am very sorry for slipping on the last two digits and saying 
1788. That is the spec that encapsulates audio samples in a 
Firewire-like frame then stamps them with PTP timestamps.
>> IEEE 1588, the grandfather of PTP,
> 1588=PTP.  Grandfather would seem to imply that PTP is some recent
> descendent.  PTPv1 is IEEE1588-2002, and PTPv2 is IEEE1588-2008.
>
> Perhaps you mean that 1588 is the father of 802.1AS  That is an Ethernet
> specific implementation of 1588, and the spec is not finalized yet.
>
The word PTP is a less precise definition for any time protocol with 
hardware assist, and in committee it referred to the watered-down 
version that doesn't have nearly the accuracy, or time-scale that 1588 
has. AVB does NOT use IEEE 1588 as its underlying PTP.
>>> the current kernel patches allow for accessing ptp clocks
>>> inside network cards. but there is no software clock yet.
> ...
>> Do you know of software-only PTP clocks anywhere?
> I believe the link I previously provided implements a software clock.
> http://ptpd.sourceforge.net/
> There are a couple of others, not sure which is likely to be best
> developed.  These seem to be a newer fork of an older project:
> http://ptpd2.sourceforge.net/
> http://ptpd1.sourceforge.net/
>
>> If the NIC doesn't have one, the timestamp resolution
>> of a kernel PTP is one jiffy.
> I think Torben already pointed out that you would probably use high
> resolution timers, and not the jiffy based timers.
>
But all PTP specs require 40 ns as the worst resolution to play in the 
PTP scheme, no lines of kernel code can get that accuracy. They rely on 
the PTP-enabled NIC PHY chip.
>> The AES-11 frequency accuracy (Grade-2) spec of 10 ppm for a
>> clock is nice, but probably won't be present in any PTP stream
>> from anyone I know of except Apogee.
> The time and instrumentation guys will definitely have better than that.
> You can already get PTP clocks from Symmetricom which will lock to GPS and
> give you long term accuracies better than 1ppb (10^-9).
> http://www.symmetricom.com/products/ieee-1588-ptp-solutions/
>
I have used many Symmetricom products in my career.
>> Absolute frequency is not AVB's strength. The local clock
>> on the motherboard, servoed to NTP will be good enough.
>> What application might demand such low jitter RTC?
> Absolute frequency accuracy and jitter are independent concepts.  There is
> no reason that the long term average frequency could not approach
> trivially close to 0 error if you are locked to a stratum 1 source such as
> GPS.
Phase is the integral of frequency, they are everything but independent.
> Jitter is a more difficult issue, and you will have the same kinds of
> problems deriving a frame or bit clock from PTP as from Firewire.
> Probably worse, you will definitely need a lot of jitter attenuation on
> your sampling clock PLL.
>
> I think we're getting off track here, though. This is jack-devel, not
> network-attached-audio-equipment-devel.  Let's start with the expectation
> that someone else (or at least on a different mailing list) will make some
> hardware that uses PTP to synchronize sampling clocks, does it properly
> with lots of jitter attenuation, does it in a way that is AVB compliant,
> and has some higher level protocol that we can use, probably based on
> RTP/UDP/IP.
> At that point, JACK just has to make sure it sends groups of packets with
> audio samples, not too fast to overrun the buffers, not too slow to
> underrun the buffers.  That should be feasible with a software clock
> implementation, either using hardware assist in the NIC, or (hopefully)
> using a fully software implemented solution so that current generation
> hardware without explicit PTP support can be used.
>
Well said! I was actually trying to prevent any soft-only PTP or AVB 
implementation, which seemed to be on the way here at Jack.
PrevNext  Index

1299244744.27531_0.ltw:2,a <4D70E6AC.3000609 at catraeus dot com>