Subject: [AVT] 802.1as AVB pitfalls

From: Chuck Harrison <[email-masked]>
Date: Fri, 17 Nov 2006 11:19:05 -0800

Hi all,

The IEEE 802.1as WG is moving forward nicely with a spec for
distribution of precise time (basically a "submicrosecond NTP")
for audiovisual media transport thru Ethernet and wifi LANs.
Other 802.1 WGs are active defining genuine bounded-latency QoS
services for a new class of economical LAN bridges that will
support reliable streaming media in the home and elsewhere.
Clearly RTP over IP is a serious candidate for carrying high
fidelity sound and pictures in this environment.

A basic requirement is that systems based on the 802 "Audio Visual
Bridging" (AVB) standards should "do no harm" compared to the
jungle of patch cables that they replace. That means, for example:
 no corrupted data,
 no dropped samples,
 no increase in sampleclock jitter,
 no phase wander between different audio channels in a stereo
   or surround-sound installation.
The last three items are timing-related and represent unfamiliar
ground to most of the 802 community. To a great extent the level
of performance (if not the fundamental concepts) is also
unfamiliar ground to the AVT community.

I would like to raise a few "warning flags" for all engaged with
this project.

(1) while "submicrosecond NTP" may establish a uniform wallclock
     throughout the LAN it will not establish a uniform sample
     clock. A digital signal coming in over SPDIF from a component
     CD player will have a sample clock derived from its internal
     crystal. In a "just play it" application, the sample clock
     at the playback DAC must lock to the SPDIF source over the
     network. The playback clock cannot be derived "open loop", as
     41000.000 Hz referred to the wallclock, no matter how accurate
     the wallclock is. The RTCP SR's mediaclock:wallclock entries
     support this if they are carefully used.
(2) audio resampling is an essential function in the overall
     application (e.g. mixing 44.1 and 48 ks/sec streams) but
     is *not* a generic solution. Witness the Audigy "upsample
     everything to 48k" cards which sounded fine but could not
     accept AC-3 coded surround sound from a DVD player's SPDIF
     output. Also resampling introduces a delay which can be 
     problematic in an interactive recording situation.
(3) video resampling (frame rate adaptation) is *always* prone
     to artifacts. Monitor outputs must lock to the source frame
     rate if they are to look as smooth as conventional TV
     displays. Video mixing or PIP from unsynchronized sources
     is an "unsolved problem", even in the big-budget professional
     world - they will always cause some movement irregularities.
(4) in RTP the only thing you can be sure of regarding the wallclock
     is that sessions sharing a common SSRC also share a common
     wallclock. This is what you need, e.g., for precise lip sync.
     In an AVB LAN you would like to think that every RTP session
     will use the precision shared clock but this is an
     unwarranted assumption. RTP streams will enter the LAN
     from external streaming sources (internet media delivery,
     teleconference, VoIP) with uncontrolled wallclocks. A "pull"
     mindset (e.g. Apple's coreaudio) may have a hard time with
     this.
(5) ...continued...Within an 802 AVB LAN, we *will* be able to
     rely on wallclock synchronization among, say, several
     microphones attached to different PCs, and also hypothetical
     "wifi mics". Same SSRC or not?
(6) fast startup is essential. RTP has stubbed its toe on this,
     as has NTP; 802.1as may be following in our footsteps.
     Just a reminder that this is nontrivial :-)

This 802 AVB is pretty much green field development, let's do
our best with it the first time out!

Cheers,
  Chuck

links
 http://www.ieee802.org/1/pages/avbridges.html
  http://www.ieee802.org/1/pages/802.1as.html
 http://www.ietf.org/html.charters/avt-charter.html
  http://www.ietf.org/rfc/rfc3550.txt

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "Geoffrey M. Garner" <[email-masked]>
Date: Sun, 19 Nov 2006 17:22:21 -0500

Chuck,

There is no assumption that 802.1AS and AVB applications all have the same 
timing source.  The applications can, in general, have different timing 
sources.
The 802.1AS network timing (I assume this is what you mean by "wall clock") 
will be used at the ingress to the 802.1AS network to create timestamps on 
mapping the application into packets that are carried over the 802.1AS 
network.  The details of how to do the mapping are not yet decided; in the 
few discussions so far both RTP and IEC 61883 have been mentioned.  Both 
protocols have a facility for creating a timestamp at the mapper relative to 
the network clock, and using the timestamp at the demapper to play out the 
data.  Any difference between the timing signals at the mapper and demapper 
shows up as jitter and wander on the recovered application timing; however, 
we are requiring that the network timing be within the respective MTIE masks 
so that the application timing jitter, wander, and synchronization 
requirements can be met. (Note that I am calling the timing supplied by the 
802.1AS "network timing"; in practice the timing signal will be derived in 
an end device.  In this case, the timing signal will be used only by that 
application, and the filtering needed to create this timing signal can be 
more stringent for more stringent applications.)

Regarding resampling, it is not surprising that there can be artifacts or 
impairments in cases where the resampling is done with a different clock 
than the original source clock.  If the clock for the resampling differs 
from the source clock, the information transfer rates are not identical and, 
over time, some kind of slip (or effect equivalent to a slip) would occur.

Best regards,

Geoff
--------------------------------------------------
Geoffrey M. Garner
Samsung

----- Original Message ----- 
From: "Chuck Harrison" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, November 17, 2006 2:19 PM
Subject: 802.1as AVB pitfalls

> ---- IEEE 802.1 Email List ----
> DELETE THIS FOOTER from copies, forwards, & replies.
> Subscription information, including changes:
>           http://www.ieee802.org/1/email-pages/pztfq906.html

---

From: Randell Jesup <[email-masked]>
Date: Mon, 20 Nov 2006 10:54:21 -0500

>jungle of patch cables that they replace. That means, for example:

Not possible as an absolute without mandating 0.000% packet loss, or using
some type of error correction (which probably implies either FEC or
retransmits).  If not an absolute, ok.

> no dropped samples,

See comments on sample-clock drift

>   or surround-sound installation.

See comments on sample-clock drift.  So long as it deals with the drift
before it gets to a noticable level, no problem, and this is not a new
issue for digital sound.  It is an inherent difference between digital and
analog.

>     world - they will always cause some movement irregularities.

Video "resampling" can only occur without* artifacts on frame boundaries,
by skipping or duplicating frames.   You can avoid the skip/dup only by
accepting other artifacts (motion, blur, etc).

*'without' means other than the effect of the skip/dup itself.

>     mindset (e.g. Apple's coreaudio) may have a hard time with

Separate RTP streams (m= lines) in a session do NOT share SSRCs; the SSRC
namespace is on a per-stream (per-port) basis, and are supposed to be
derived randomly.  You can use RTCP-derived NTP times for streams within
the same session, though you cannot assume that the sample clock rates
(timestamp rates) for separate streams are identical.  Even if the same
type of media and same supposed frequency, they can be based on different
physical clocks and can drift relative to each other.  Unusual by possible
(think for example of simultaneous audio streams in different languages
coming from different sources, or streams coming from independent networked
microphones).

>     "wifi mics". Same SSRC or not?

Same SSRC is not a valid use of SSRC.  (See above).  Also, if originating
at different sources, probably not part of the same RTP session (though
they could be part of a multi-point session).  Note however that their NTP
times used in generating SR reports should be in sync, and so whatever is
handling all the incoming RTP data from multiple sources can assume the NTP
times are properly in-sync.  It will still need to deal with sample-clock
(and playback-clock) drift, but the NTP times should allow that.

Note: it may make sense if the application needs to know about the tight
sync on NTP to signal this in session establishment.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Chuck Harrison <[email-masked]>
Date: Mon, 20 Nov 2006 13:41:47 -0800

> retransmits).  If not an absolute, ok.

Well, nothing is an absolute :-). But my understanding is that the
purpose of the 802.1 AVB QoS features (i.e reserved bandwidth,
bounded-latency bridging) is to have no additional losses above
the fundamental error rate of the PHY.

[...]
> physical clocks and can drift relative to each other.  Unusual but possible

Thanks for pointing out my misstatement about SSRC. Apologies to all.
A host is permitted to use identical SSRCs on different RTP sessions
(ports) of a multimedia session, but there is no recognized
significance (e.g. shared-wallclock, as I erroneously asserted) to
such a practice.
RFC3550:
    The SSRC identifier is a
    randomly chosen value meant to be globally unique within a
    particular RTP session (see Section 8).  A participant need not
    use the same SSRC identifier for all the RTP sessions in a
    multimedia session; the binding of the SSRC identifiers is
    provided through RTCP (see Section 6.5.1). 

BTW RFC3550 has precise definitions of "multimedia session"
and "RTP session", and there are quite a few permutations of
multicast and unicast configurations. Although one might hope, for
example, that streams coming from the same location (e.g. same
CNAME) would share a common wallclock, this is not guaranteed.
In fact there is no feature anywhere in the protocol that
specifically signals common wallclock (as is needed for inter-
stream synchronization).

> [...]  Also, if originating

Yes. When tight sync across different RTP sessions is desired, it
behooves us to be able to determine that the several sessions truly
share a wallclock, through some form of signalling. 

In a "home sound recording studio" scenario one would like to
replicate the behavior of existing recorders, mixers, etc that use
synchronized word clocks. One could add signalling for associating
a stream (RTP session + SSRC combination) with an identified sample
clock source. In the AVB world, with an accurate distributed
wallclock,
it seems it would be useful to signal those streams whose sample clock
is coherent to the AVB clock, and encourage people to implement
sources
(e.g. AD converters) that work that way.

Regards,
  Chuck

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Nov 2006 11:28:11 +0000

> specifically signals common wallclock (as is needed for inter-

You can use RFC 3388 plus the common CNAME to signal this.

Colin