Re: [AVT] time alignment capability

["Joe Kelsey" <KELSEY at avtcorp.com>]

Our application seems very simple from the outside, exchanging audio samples for cockpit audio on the new 787.  However, getting to 10ms difference between 7 separate boxes on the airplane is tough, especially since the synchronization has to be accurate essentially as soon as the power is applied.

NTP takes about half a day to synchronize and you cannot rely on letting the plane sit around that long.

The basic problem with NTP is that you do not know how quickly you can transmit the packets, so it takes a long time to determine round-trip time to sufficient accuracy.  The basic problem is timing how long the packet transmission takes.

PTP on the other hand requires timing of all phases of packet exchange, adding packet transmission time to the other NTP times.  We would use standard PTP over Ethernet except that our Ethernet interface does not tell us when it finishes transmitting a packet.  To get around this problem we have come up with our own PTP-over-CAN protocol.

So, essentially this problem is completely outside of RTP.  If you require synchronized devices, you have to use something outside of RTP.  Adding this to RTP would be a complete waste of time.

/Joe

>>> "Tom-PT Taylor" <taylor at nortel.com> 3/2/2006 2:00 PM >>>
So does it make sense to build this capability into RTCP? Or are you 
suggesting a separate protocol session between nodes?

Joe Kelsey wrote:
> Fundamentally, neither the RTP time codes nor NTP is sufficient for precise synchronization.  If you want accurate and fast synchronization between devices, then you have to use something like PTP, since NTP takes much too long to synchronize and does not do it to a sufficient resolution.
> 
> /Joe
> 
> 
>>>>Chuck Harrison <cfharr at erols.com> 3/2/2006 1:32 PM >>>
> 
> I believe that there *are* significant use cases for something
> like Dave's "payload format independent capability". Long-time
> participants in this forum will have heard my refrain before:
> 
> RTP's original design never addressed or intended to address the
> issue of long-term phase correlation among sender and receiver
> sample clocks. In neither theory nor practice are RTP media
> sources or sinks expected to be phase synchronous to NTP time,
> and drift does occur.
> 
> There is a large class of applications wherein the resulting
> artifacts (dropped/repeated video frames, audio pops, drifting
> inter-track synchronization) are negligible and the current
> RTP architecture is sufficient. There is also a class of
> applications (largely but not exclusively of "professional"
> type) which do not tolerate such artifacts well and would benefit
> from additional features supporting phase synchronization of
> sources and receivers.
> 
> This task is nontrivial, as different use cases call for different
> types of "pulling" or "pushing" sync. Existing practice in
> professional video and audio production studios offers insight
> into the type of time alignment capabilities that are likely to
> be useful.
> 
> I do not know whether Dave's view of the issue is as broad as I
> state here, but I concur with his assessment that this is a
> "generic" capability that could beneficially apply to many if
> not all of the payload formats transported over RTP.
> 
> I do recognize that 3G gateway implementors may be impatient
> regarding the development of a "big picture" solution. But that's
> why I started posting to avt on this topic about 5 years ago ;-).
> 
> Peace,
>   Chuck Harrison
> 
> 
> David R Oran wrote:
> 
>>I'm wondering if this might be better abstracted into a payload-
>>format independent capability and use a framework like that in draft-
>>wenger-avt-avpf-ccm-02.txt?
>>
>>Dave.
>>
>>On Mar 1, 2006, at 5:10 PM, Ejzak, Richard P (Richard) wrote:
>>
>>
>>>Hi all,
>>>The editors of RFC 3267 bis are preparing a new draft for the
>>>upcoming meeting and we propose to add an optional capability to
>>>perform time alignment for AMR and WB-AMR.  Unless there are
>>>significant objections to this addition, the editors propose to add
>>>time alignment to the new draft next week.  Please provide any
>>>comments or concerns with the proposed new capability.
>>>
>>>Time alignment is useful in certain gateway-to-gateway scenarios
>>>and certain gateway-to-VoIP-terminal scenarios.  It is the ability
>>>for a receiving gateway to request that the encoder shift the time
>>>reference for encoding and packetization by a specified amount.
> 
> [...]
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org 
> https://www1.ietf.org/mailman/listinfo/avt 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org 
> https://www1.ietf.org/mailman/listinfo/avt 
> 
> 


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt