Re: Timing problem on PPC based Macs (PortAudio)
Re: Timing problem on PPC based Macs (PortAudio)
- Subject: Re: Timing problem on PPC based Macs (PortAudio)
- From: Thomas Tempelmann <email@hidden>
- Date: Sat, 21 Mar 2009 09:54:20 +0100
On Sat, Mar 21, 2009 at 05:19, Ross Bencina <email@hidden> wrote:
>
> I don't know how they compare, but one factor to consider is that often
> these machines use NTP to synchronise their time APIs to a network time
> base -- afaik the synchronisation algorithms calibrate correction factors
> for the local clock rate vs. a network standard time base, and this can
> become "pretty accurate" over time. I'm not sure how tempurature affects
> things though.
Now, this one I can answer, because I thought the same first during my
development of my networked sound app:
Instead of using the Microseconds call I used to fetch the CFDate's
current time. Bad idea! That time is _gradually_ self-adjusting to a
time from NTP. And NTP's time may easily be off by a few ms. Hence,
you'll see that that time often runs a bit faster or slower to "catch
up" with the "real" time from NTP. So, never ever use that time for
timing measurements. So, while, when looking at that time value over a
longer time does indeed get it a pretty accurate global time, it's
still only correct on _average_. Not suitable for timing measurements
in the sub-second area.
The Microseconds (and system's UpTime) are, OTOH, precise to their
crystal clock and won't de-/accelerate.
--
Thomas Tempelmann, http://www.tempel.org/
_______________________________________________
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