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

On Tue, Mar 01, 2011 at 07:50:17PM -0600, Duncan Gray wrote:
> 
> 
> 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.

i wasnt talking about rate differences.
the resampling happens in the alsa_out module. 
anyways.... lets talk avb.

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

i dont see a need for a NIC that looks like a soundcard.

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

its not inside the source tree yet. but i think it will be there soon.

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

not if that soundcard is the only one, and the ptp master clock.


my real question is now is: does the assumption holds, that the ptp master
clock can also serve as CLOCK_REALTIME ?

the current kernel patches allow for accessing ptp clocks inside network
cards. but there is no software clock yet. so in the software case ptpd
will end up servoing CLOCK_REALTIME. i dont think that is desired, and
there should be a software ptp clock too, if the NIC doesnt have one.



-- 
torben Hohn

1299061125.23994_0.ltw:2,a <20110302101824.GC4903 at siel dot b>