Messages in this thread | | | Date | Thu, 17 Jul 2014 15:19:55 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: firewire: CLOCK_MONOTONIC_RAW exposure |
| |
On Thu, 17 Jul 2014, Daniel Thompson wrote:
> On 16/07/14 16:00, Mark Brown wrote: > > On Wed, Jul 16, 2014 at 04:16:35PM +0200, Clemens Ladisch wrote: > >> Peter Zijlstra wrote: > >>> On Wed, Jul 16, 2014 at 01:34:21PM +0200, Clemens Ladisch wrote: > > > >>>> The purpose is to get a stable clock, i.e., to avoid clock rate changes > >>>> caused by NTP corrections. > > > >>> That's maybe half an answer; what do you need that for? > > > >> According to the original report, "for applications which need to > >> synchronise with external timebases such as broadcast TV applications". > >> Such external clocks are not synchronous with any available clocksource, > >> so proper resampling requires that the (relative) rate of the two clocks > >> (sender and playback device) is measured accurately. > > > >> (I don't have numbers for the errors caused by NTP adjustments. Daniel?) > > > > Right, the goal is to get a clock which is guaranteed to never have any > > adjustments that might cause discontinuities or rate changes applied to > > it. My understanding is that the users are already doing their own rate > > matching and it's much more important to them to get a stable clock than > > it is to get a clock at a specific nominal rate, and given the set top > > box applications I expect they also need this from very soon after boot. > > We are trying to match rates with a broadcast device that "shouts" the > current time many times per second (MPEG transport stream PCR packets). > These packets are timestamped on arrival with a local clock and the > resulting data is used to recover the broadcast clock. However due to > variable transmission delay of the packets we require very long > control loops to extract any useful information from this data (varies > between five minutes and half and hour). > > An NTP rate correction can change the rate of CLOCK_MONOTONIC > sufficiently to confuse our clock recovery algorithms so we use > CLOCK_MONOTONIC_RAW as the master view of time. > > Both audio and video must be presented synchronized to the recovered > broadcast clock which in practice this means comparing them to > CLOCK_MONOTONIC_RAW and doing some maths. > > In is, of course, possible to convert ALSA's CLOCK_MONOTONIC > timestamps into CLOCK_MONOTONIC_RAW values so we can compare ALSA time > to the broadcast clock. In fact its not even that hard compared to the > other time conversions we have to do. Nevertheless it is a redundant > conversion and adds an extra dimension to a problem that only just fits > in most craniums ;-)
Thanks for the explanation!
tglx
| |