Re: Host Time epoch
Re: Host Time epoch
- Subject: Re: Host Time epoch
- From: John Iversen <email@hidden>
- Date: Wed, 09 Feb 2005 16:44:30 -0800
Hi,
I've just been working on a variant of the original problem: expressing
the same moment in time both as a host time and NSDate. I put an upper
bound on the uncertainty by bracketing the setting of the NSDate (to 'now')
with calls to AudioGetCurrentHostTime().
For what it's worth, I get an interval of ~0.02 ms, yielding an uncertainty
in the relation between my two time representations of +/- 0.01 ms (on a
TiBook 1GHz). Immediately repeating the code yields an upper bound on
relative error about 3x smaller ( +/-0.003 ms). With interpolation, as
described by the last email, one could do better.
e.g.
now_ns = AudioConvertHostTimeToNanos(AudioGetCurrentHostTime());
startDate = [NSDate date];
now2_ns = AudioConvertHostTimeToNanos(AudioGetCurrentHostTime());
maxPossibleError_ns = now2_ns - now_ns;
John Iversen
At 03:09 PM 2/9/2005, Jeff Moore wrote:
The source of the time the HAL provides is the system bus clock. It is
accessed via the routines in <mach/mach_time.h>. This counter is reset at
boot time and increments monotonically at the system bus clock speed (I
think). I'm not aware of any direct conversion routines that map this time
base to the time base that gettimeofday(2) uses or that CFDate uses.
That said, you can always figure this out by sampling the two time bases
to establish an anchor point to convert with. You would read the first
time base, then the second, and then the first again. You can usually
assume that the second time base's time is taken half way between the the
times of the first time base. You want to do this a few times. Then you
pick the sampling that had the smallest difference between the first time
base's time.
Once you have the anchor point, you also need the slope between the two
time bases to do the conversion (in other words the number of ticks it
takes of one time base to equal a tick in the other). To get this, you
have two choices. First you can assume that the system clock's conversion
to nanoseconds doesn't drift. This is not a bad assumption to make as it
is usually pretty accurate, so you can usually get away with. However
since there is a limit to the precision of the nanosecond conversion,
there is some error that will build up and cause drift over long
durations. To get a more accurate reading of the conversion factor, you
are going to need to sample the time bases over time and use the
succeeding differences to figure out what the slope is (recall that the
slope of a line defined as F(X) can be written as (F(X1) - F(X0)) / (X1 -
X0)). You'll also want to keep updating this information while you are
running to be sure that it stays up to date with what is going on in the
hardware.
On Feb 9, 2005, at 1:56 PM, Geoff Schmidt wrote:
Hi,
Simple (?) newbie question I couldn't find answered in the docs or
HostTime.h: How can I convert host timestamps (as is
AudioGetCurrentHostTime or AudioTimeStamp.mHostTime) to a calendar date
and wallclock time? In other words, a host time of 0 (or a 0 return value
from AudioConvertHostTimeToNanos) corresponds to what absolute date and time?
This comes up because I am trying to synchronize audio playback between
several machines on a network.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden