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: Mon, 30 Sep 2002 15:00:15 -0700
On Friday, September 20, 2002, at 11:33 AM, Cameron Jones wrote:
My USB driver (a kext) shows synchronization problems with certain
applications in 10.2. The driver works fine with all applications in
10.1.5. In 10.2, certain applications (like Reason) seem to get
behind the
current timestamp and the audio output drops out. Other applications
(such
as iTunes and CuBase X) seem to work fine in 10.2.
Has anyone else seen this problem and are there any clues to what is
going
on?
To expand on what Doug posted earlier, the problem seems mainly to do
with jitter in the time stamps that the driver takes, and the driver
being prevented from queueing more data.
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.
The first is to make sure that you have enough of a safety offset and
that you are taking accurate time stamps with minimal jitter. Use the
safety offset to make sure that the HAL doesn't get any closer than the
accuracy of the time stamps, which is about 3ms. Furthermore, the
driver could be held off right before it wants to take a time stamp, so
just calling takeTimeStamp() isn't good enough. You need to look at
the current USB frame and keep a prediction of what USB frame you
should be on when you have to take the time stamp. Compute the
difference between the ideal time and the current time (this is how
long the completion routine was held off), and then subtract that from
the current time. Pass this as the time parameter to takeTimeStamp().
The second way that I've tried to reduce dropouts is to use the
clipOutputSamples() call to queue up a frame list if I fall below a low
water mark of frames queued. You can't just use this solution instead
of queuing more from the write completion routine because you don't
know how often clipOutputSamples() will be called, but it works as a
stop-gap measure in some circumstances (like when the monitor is
dimming/waking). I look at the current USB frame number, and the last
frame that I have queued, and if I have less than one frame list of
audio queued up I call the USB write completion routine from the
clipOutputSamples() function. In the write completion routine, if I
have more queued up than I should when the frame list completes, then I
know that I already queued the next frame list and I just exit the
completion routine without doing anything. This works well because I
only have two frame lists queued now, the one in progress, and one
queued for when it finishes. I'm using a pool of 4 frame lists as
well. This saves a little memory, allows for some flexibility, but
also causes a few headaches like this.
The first solution should be available in the current sources on
Darwin. The second isn't since I was just implemented it last week.
Hopefully you can add these tricks to your driver and get something
that works well until we come out with a solution that will work better.
--
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.