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

On 02/28/2011 09:45 PM, torbenh wrote:
> On Mon, Feb 28, 2011 at 07:59:01PM -0600, Duncan Gray wrote:
>> I sat on the IEEE1788 standards committee when we were working on
>> the timing portion of the spec and the beginning of the
>> zeroconf-like discovery protocols.
>>
>> To implement AVB, the intention (as far as Jack would be concerned)
>> would be to get a NIC card that will most definitely implement the
>> timing protocol. A consumer app that only does streaming is the
>> "killer app"; and that was the only concern of Broadcom and Marvell
>> -- who were major participants. This does not concern itself with
>> latency, but rather with delivery. These apps stream with virtual
>> timing from disk. Then the reproduce to iPods that will recover
>> timing as cheaply as possible to achieve robust buffering with
>> fairly low jitter playback.
> i dont really understand this.
> you mean streaming from harddisk to multiple endpoints,
> all playing phase synced ?
Yes
> with soundcards that generate their own clocks, and dont allow for rate
> control ?
No. ... SRC would be needed for these
> if one allows 3ms of diff, we can do this with netjack for quite some
> time. 3ms is not relevant for comsumer applications imo.
3 ms of difference is not a rate difference, only time difference. Time 
difference grows unbounded for a frequency difference between the source 
and the sink. There will be a jitter buffer xrun at a periodic rate for 
that situation.
> if the soundcard allow software to gradually adjust the clock, we could
> do this without resampling.
> the problems start when there is packet loss and high jitter.
> (such as an internet connection over the atlantic or somthing, here it
> gets interesting.)
I didn't know that there were sound cards that allow fine-set frequency 
control to allow implementation of a good low-jitter PLL.
>
>> The anticipated audio app (consumer or pro) is that a VERY SPECIAL
>> Audio NIC would be created that would buffer the stream and present
>> it to the hardware with a strict-timed interrupt and look like an
>> audio card. That card has an analog Phase-Locked-Loop controlled by
>> the AVB (which is a derivative of IEEE 1588) and the timing
>> information in the stream control of IEEE 1788.
> you mean an audio nic in a computer ?
> or in the embedded audio soundcard ?
>
Can be done either way. The anticipated case would be a NIC that has an 
appearance that looks like a sound card. Otherwise, (conceptually, not 
designed AFAIK) the timestamped 1788 packets could be sent to a 
soundcard to implement PTP's PLL.
>> Such NICs will become available on a very long schedule, and a
>> company called Lab-X can point you to vendors leading the way.
>> Perhaps someone from the Jack core crew should speak to Lee Minich
>> at Lab-X about a push to open some for driver work. There is also an
>> industry alliance for AVB, AVnu (Akin to the dreaded Firewire
>> industry alliance.)
> well... there seems to be some silicon out there....
> ptp patches seem to be ready for mainlining. and will probably hit the
> tip tree soon.
> http://www.spinics.net/lists/arm-kernel/msg116310.html
>
> with a reasonably good ptp timer in the kernel.
> this is all easy stuff.
>
REALLY GLAD to see that the PHYTER has made it into the source tree. I 
am amazed that it has gone this quickly.

Kernel PLLs, however, will have lots of jitter. Once again, consumer 
will be OK (maybe some surging and low-freq noise like USB externals I 
know.) The adaption from a PTP aware PHY to allow paced pay-out of 
packets to D/As or to allow a D/A to drive the PTP as a master is 
brilliant. Without a PLL-able sound card, though, SRC must be done the 
hard way, in software.

1299030655.15112_0.ltw:2,a <4D6DA259.8050904 at catraeus dot com>