Re: clear description of AudioTimeStamp?
Re: clear description of AudioTimeStamp?
- Subject: Re: clear description of AudioTimeStamp?
- From: Kurt Bigler <email@hidden>
- Date: Mon, 21 Apr 2003 23:30:58 -0700
on 4/18/03 7:29 PM, Jeff Moore <email@hidden> wrote:
>
On Friday, April 18, 2003, at 06:26 PM, Kurt Bigler wrote:
>
>
> I would also like to understand what happens to both mSampleTime and
>
> mHostTime when a kAudioDeviceProcessorOverload occurs. In particular, if I
>
> have callbacks for several devices I would like to be able to recover the
>
> buffering relationship between the several sample-synchronized devices after
>
> one of the devices has an overload. This is for a performance situation (in
>
> which recovery matters), not a recording situation (in which you would give
>
> up and start over). Do I have to stop all the devices and start them again?
>
>
No. You shouldn't stop and restart the devices if you don't have to.
>
>
> (That would be bad.) Or can I assume that the gap in mSampleTime reflects
>
> how much the overloaded device has slipped in buffering relative to the other
>
> devices? Or is mSampleTime for some reason unreliable, so that I must look
>
> at the mHostTime field of all the devices and convert this back to samples to
>
> recover the correct buffering relationship?
>
>
When an overload happens, the HAL will take a full IO sleep cycle and
>
then begin again internally as if the IO thread just started up. It
>
establishes a new anchor point and zeroes it's internal sample counter.
>
The time stamps passed to the IOProc in the very next IO cycle after
>
the penalty period will reflect the amount of time that has passed.
>
This is the only time there should be gaps in the time line presented
>
by the time stamps.
I am finding that I am getting kAudioDeviceProcessorOverload nofications
with no gaps in mSampleTime.
Checking for gaps in mSampleTime seemed like the obvious thing to do, since
I need to know the number of samples skipped in order to resynchronize my
buffers.
However, it appears that mHostTime is showing a gap that is at least
approximately correct. So it looks like I am stuck with scaling mHostTime
in order to determine the number of scamples skipped, which seems absurd.
Is mRateScalar by any chance useful for this? This appears to be another
field of AudioTimeStamp that is undocumented, except for the phrase "system
rate scalar".
Otherwise I have to use the function that converts host time to nanos,
divide by 10e9, and multply by the sample rate.
No matter what, if the rounding to integer does not work out right, then I
am stuck.
Is there supposed to be a gap in mSampleTime? Is the fact that there is no
gap a problem with the driver or with the HAL? I kind of remember reading
that the HAL just passed on values from the driver in the AudioTimeStamp.
Thanks for any help.
-Kurt Bigler
_______________________________________________
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.