Re: clear description of AudioTimeStamp?
Re: clear description of AudioTimeStamp?
- Subject: Re: clear description of AudioTimeStamp?
- From: Jeff Moore <email@hidden>
- Date: Fri, 18 Apr 2003 19:29:56 -0700
On Friday, April 18, 2003, at 06:26 PM, Kurt Bigler wrote:
Is there somewhere a good description of the AudioTimeStamp fields?
Searching developer.apple.com for AudioTimeStamp yields only one
match, that
being the coreaudio.pdf file which contains almost no description at
all. I
believe I searched the list archives and did not find much, but
apologies if
I missed something obvious.
In particicular:
Is mHostTime the estimated host time at which the first sample in the
buffer
appears at the actual device output or input, based on latency info
presumably provided to the HAL by the driver? I assume this must be
the
case, otherwise the AudioTimeStamp would not seem to be of much use for
synchronizing devices.
The time stamps the HAL provides do not include the hardware latency
figure, but otherwise that is a reasonable definition.
Does mSampleTime start at zero for the first sample read/written after
a
device is started? Does the same apply when the device is seen
through an
output audio unit?
When the device starts, mSampleTime would be 0. But when the device
starts is only loosely related to a call to AudioDeviceStart(). The
reason why is that the device is shared amongst many processes. If
process A starts an IOProc and then process B starts an IOProc, the
device will actually start when device A started it's IOProc.
Consequently, process B won't see the beginning of the time line but
will come in somewhere in the middle.
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.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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.