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: Jeff Moore <email@hidden>
- Date: Thu, 29 Sep 2005 14:10:54 -0700
On Sep 29, 2005, at 12:51 PM, email@hidden wrote:
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).
It sounds like you have things somewhat confused. The time stamps the
HAL passes to an IOProc are generated with the same code that does
the translations in AudioDeviceTranslateTime() and calculates the
current time in AudioDeviceGetCurrentTime(). So, they are all
internally coherent and provide the same figures. It is not possible
for them to disagree. However, it is very easy for apps to get
confused about what the numbers are saying, especially in this case
where you are resolving AUHAL's time line against the actual device's.
I imagine that you have some mechanical or possibly semantic issues
in your code with accessing the time and resolving the AUHAL time
against it. Perhaps you might want to start posting code, rather than
explanations because it's easy to get this wrong if you're not careful.
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.
Yup. Those are all reasons not to go that route and to use the
methods I'm describing.
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.
Now I know you're confused because the input time stamps are always
in the past.
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.
IMHO, we have ample API for this and it is just your own confusion on
the issues that is getting in your way. I really think it's time to
start talking about actual code, because you clearly have some
misconceptions about how time works and what the time stamps mean.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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