Re: Synchronization problem in 10.2
Re: Synchronization problem in 10.2
- Subject: Re: Synchronization problem in 10.2
- From: Laurent Humbert <email@hidden>
- Date: Thu, 17 Oct 2002 09:50:24 +0200
At 2:06 PM -0700 10/3/02, Mark Cookson wrote:
On Wednesday, October 2, 2002, at 11:55 PM, Laurent Humbert wrote:
My (FireWire) audio driver would not work properly until I passed
a fixed interval to the takeTimeStamp routine. For example, it it
theoratically takes 2.321955 seconds to fill the input buffer,
the code looks like this.
UInt64 nanos;
AbsoluteTime wraptime;
nanos = ((UInt64) 2321955) * 1000;
nanoseconds_to_absolutetime(nanos, &wraptime);
ADD_ABSOLUTETIME(&wraptime,
&theAudioEngine->status->fLastLoopTime);
theAudioEngine->takeTimeStamp(true, &wraptime);
If I did thing by the book and simply called
theAudioEngine->takeTimeStamp()
then a drift would occur and the sound deteriorate gradually. The
log would fill with
>!!! firstSampleFrame->audioEngine->numSampleFramesPerBuffer
(XXXXX > YYYYY)
Actually, it would be better if you didn't always just add a specific
number to the time stamp. In theory this is the right thing to do,
but it doesn't take into account clock drift between the CPU host
clock and the FireWire (USB, PCI, etc.) clock. I've measured the USB
clock, and USB's 1ms frame takes only about 0.9999ms of the CPU's
version of a millisecond. Who's right, I don't know, but the
important thing is that they two clocks stay in sync. If I were to
always add the same amount of time to the time stamp, then I wouldn't
be keeping the two clocks in sync and things would gradually drift
apart depending on how different the clock was from advertised. This
is one of those things that you can't measure in the lab because
every computer has the potential to be different, especially given
factors of temperature and pressure which affect the crystals.
It would be best to compute the time but still keep it linked to
FireWire's version of time.
You are right and I added a check to adjust if the FireWire clock drifts
from the CPU clock. (It does at a rate of about one nanosecond every 20
seconds or so).
Speaking of synchronization, here's another one:
My driver receives data continuously, even if the audio engine isn't
running (the packets contain MIDI sequences too). The first time my
driver's performAudioEngineStart() method is called I call takeTimeStamp(false)
and initialises my variables like the current frame position etc... My FW
callback routine only calls takeTimeStamp if the audio engine's running.
Everything works fine the first time, but if the audio engine is stopped
then started again, the sound is crap. Like the audio engine is still
using some settings from the previous session... I have initialised
everything I could think of, but somehow I can't put the audio engine
back in the starting block...
Any ideas ?
Thanks
Laurent
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.