Re: [RE] Time sensitivities in ResE. Part 1: Synchronization
Michael,
>> If the clock has short term jitter or modulation, then the
>> reproduced data suffers from distortion.
I agree. Supportive arguments follow.
The ear is a very sensitive device and audiophiles can detect
_very_ small amounts of jitter in their clocks. The problem
is that large signals in ear-insensitive frequencies can
be modulated to small signals in ear-sensitive frequencies.
Within this environment, simply broadcasting a strobe signal
is insufficient. The delay in this signal is variable and can
deviate from its nominal (near zero) value by frameSize*count,
where count is the number of bridges in the path.
The problem with such frame-sized deviations is that they are
not just "noise" within the home, and hence not easily filtered.
In fact, heartbeat-like signals are likely to cause delays with
significant harmonic content.
With the Internet, more success with frequency jitter is possible,
due to the wide range of traffic (and hence) its relatively
wideband (read effectively filtered) statistics. Not in the home.
Fortunately, the 1588-like techniques allow the jitter to be
reduced to PHY-fifo-size (as opposed to max-frame-size) numbers.
Actually, with some PHY-implementation support, even bit-sized
jitter delays are achievable (although unlikely to be mandated
by an RE specification).
This discussion, of course, is with respect to the end-point
clocks in A/D and D/A converters. Data delivery requirements
are much less stringent and certainly will be on the order
of multiple max-frames.
Cheers,
David V. James
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Michael Johas Teener
>> Sent: Tuesday, April 12, 2005 3:31 PM
>> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
>> Subject: [RE] Time sensitivities in ResE. Part 1: Synchronization
>>
>>
>> There seem to be some misunderstandings on what the SG is asking for in
>> terms of time-sensitive data. Let me try to explain what I think is the
>> intent. I will be doing this in two separate emails since I
>> expect that we
>> will end up with separate threads of discussion.
>>
>> Endpoint synchronization:
>>
>> There are two primary reasons that endpoints in a media-streaming
>> interconnect need to be synchronized.
>>
>> 1) At the source of the stream there frequently is a time base
>> that is not
>> under the immediate control of the local network. It could be the
>> transmission of an MPEG stream from a broadcast source
>> (terrestrial, cable,
>> satellite) ... or most extreme, the sampling clock of an audio A/D. At an
>> endpoint where the stream is being reconstructed this sampling
>> clock must be
>> reproduced very accurately. If the clock has long term drift (frequency
>> mismatch) then you eventually have to drop/add data to get the buffers
>> aligned. If the clock has short term jitter or modulation, then the
>> reproduced data suffers from distortion. For lack of a better
>> term, perhaps
>> we could call this "sample clock synchronization". The general
>> rule for this
>> is to do as good as possible ... hence the rather fuzzy
>> requirements in the
>> SG objectives list.
>>
>> 2) When a stream has multiple destination endpoints, and those endpoints
>> reproduce the data together in a way to create a coherent
>> environment, then
>> requirements are placed on how accurately the timing of the
>> reproduction of
>> the stream on one endpoint is done with respect to the timing on
>> the other
>> endpoint(s). For example, an MPEG stream is sent to both a TV
>> and an audio
>> amplifier ... lipsink must be maintained, requiring
>> synchronization on the
>> order of 10-20ms (one field or less). For digital speaker systems, the
>> synchronization between speakers must be on the order of 200us (some
>> audiophiles argue for 10us, but the majority of the imaging
>> information is
>> below 3kHz). This kind of thing might be called "presentation time
>> synchronization". This is one place where the SG received conflicting
>> information, so the more restrictive number was used ... since existence
>> proofs (IEEE 1588 and IEEE 1394) shows that this kind of
>> synchronization can
>> easily be done with very low complexity.
>>
>> The numbers I quote here are open for discussion. I think we
>> should all do
>> what we can to document the requirements further, with appropriate
>> references.
>>
>> Comments? Additions? Corrections?
>>
>> --
>> ---------------------------------------------------------------
>> Michael D. Johas Teener ‹ mikejt@broadcom.com
>> office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845
>> http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
>> ---------------------------------------------------------------
>>