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