Re: Input callback timestamp reset and current sample time
Re: Input callback timestamp reset and current sample time
- Subject: Re: Input callback timestamp reset and current sample time
- From: <email@hidden>
- Date: Thu, 29 Sep 2005 12:51:01 -0700
> One of the good things about AUHAL is that the time stamps it
> provides also contain the host time that corresponds to the sample
> time. This allows you to use the HAL API call,
> AudioDeviceTranslateTime(), to map the sample time from AUHAL's
> timeline to a sample time in the HAL's timeline.
I tried using AudioDeviceTranslateTime(), but it seems that if
kAudioTimeStampSampleTimeValid is set in the input timestamp (normal
case) then the resulting mSampleTime is always just a copy of the
input mSampleTime, even after the HAL is reset and starts using a
different timeline. If I clear kAudioTimeStampSampleTimeValid, forcing
it to rely on mHostTime, then it does convert mSampleTime, but it's a
little off even before the HAL has been reset (e.g. input mSampleTime
is 0, but converted mSampleTime is like 8015, even though at that
point 0 is what sample time the HAL is returning).
The best I've been able to do so far is emulate the AUHAL's timeline
by recording mSampleTime and mHostTime from the input callback then
when I need the AUHAL's current timestamp outside the callback, I use
AudioGetCurrentHostTime() to get the current time, subtract my saved
off mHostTime to get the tick delta, convert that to a sample count
delta, and add that sample delta to the last saved off mSampleTime to
estimate the AUHAL's current sample time. There are a few problems
with this such as audio clock vs host clock skew and race conditions
because it relies on the input callback running before I need to
estimate the AUHAL's timestamp.
Another thing I noticed is that the timestamp passed to my input
callback is in the future (4100 or so samples, which is close to the
4096 sample buffer I configured) so I have to compensate by adjusting
by a guess of 4096 samples.
A suggestion for the future would be an API or property to get the
current timestamp for the audio unit (in sync with what will be passed
to the input callback). This should provide a reliable way to get the
current sample index that is in sync with the audio unit and insulated
from any underlying device changes. For example, with USB audio, you
can always look at the frame number to know where you're at in the
playback so it's relatively easy to correlate timelines.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden