Re: Synchronization problem in 10.2
Re: Synchronization problem in 10.2
- Subject: Re: Synchronization problem in 10.2
- From: Mark Cookson <email@hidden>
- Date: Thu, 3 Oct 2002 14:06:26 -0700
On Wednesday, October 2, 2002, at 11:55 PM, Laurent Humbert wrote:
At 3:00 PM -0700 9/30/02, Mark Cookson wrote:
What we've noticed is that at certain combinations of buffer sizes
in the application and driver the HAL's IOProc thread beats against
the driver's USB completion routines, causing the USB completion
routine to be preempted or held off. If your driver is anything
like the AppleUSBAudio driver, then you queue up more frame lists to
write from the completion routine of the previous routines, and this
means that you are delayed from queuing up more writes. I've tried
to mitigate this problem in two ways.
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.
--
Mark Cookson
Engineering Droid
Apple Computer, Inc.
Core Audio CPU Software
6 Infinite Loop MS 306-2CW
Cupertino, CA 95014
_______________________________________________
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.