Clock drift and timestamps - what's the correct way to think?
Clock drift and timestamps - what's the correct way to think?
- Subject: Clock drift and timestamps - what's the correct way to think?
- From: Neil Clayton <email@hidden>
- Date: Mon, 4 Feb 2008 17:20:00 +1300
- Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
I'm trying to confirm my understanding of the way playback has been
done in CAPlayThrough - the same app that plays data from one device
to another, using a software ring buffer and varispeed in between the
two devices.
The example code calculates a timestamp offset between the source and
destination devices, which is never recomputed after the initial
calculation.
Is the varispeed enough to counter the clock drift that could occur
between the input and output devices? I made a quick test that
resets the mInToOutSampleOffset every second or so, and was able to
observe slight drift over just a few seconds (the offset changed, so I
presume the clocks must be drifting slightly). I'm using two
difference devices for input and output.
My understanding is that while the varispeed might change the rate of
playback, but that isn't going to affect the actual timestamps of the
clocks for each device.
I'm no expert at this (hence this digging / learning). I'm presuming
the drift will be relevant over time. But perhaps it's not?
--
Regards,
Neil Clayton
_______________________________________________
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