[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140716150010.GA4951@sirena.org.uk>
Date: Wed, 16 Jul 2014 16:00:10 +0100
From: Mark Brown <broonie@...nel.org>
To: Clemens Ladisch <clemens@...isch.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
Daniel Thompson <daniel.thompson@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>,
Stefan Richter <stefanr@...6.in-berlin.de>,
linux-kernel@...r.kernel.org,
linux1394-devel@...ts.sourceforge.net,
John Stultz <john.stultz@...aro.org>
Subject: Re: firewire: CLOCK_MONOTONIC_RAW exposure
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.
For ALSA the behaviour is optional and users can always opt to use the
NTP corrected monotonic clock if they prefer.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists