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 17:32:17 -0700
On Sep 29, 2005, at 5:08 PM, email@hidden wrote:
Your first problem is that you are calling AudioDeviceTranslateTime()
incorrectly to translate a host time into a sample time.
Yeah, I noted in a previous message that if I clear
kAudioTimeStampSampleTimeValid, it does the conversion instead of just
copying over the sample time. But then I notice slight differences,
possibly due to rounding/truncation error? This isn't the end of the
world because the relative delta between callbacks still seems to be
exactly 4096 samples, but it's something I noticed. For example, I
get:
Raw Input Time: 8341.000000
Translated Time: 8340.000000
It's possibly due to truncation, but I'd have to look. As I said, the
code that does all that in the HAL is all the same.
An additional problem with this approach is that when the HAL resets
(e.g. headphone plug/unplug), the timeline resets. I can deal with
resets to a certain extent by re-mapping my timeline, but there is a
race condition I would need to deal with where the reset may occur
in-between getting the current device time (outside of the input
callback) and the input callback being called.
What I'd ideally like to do is convert the other way around (current
device time -> AUHAL time) so that the time I get is always relative
to the same initial start point (when the AUHAL was started) and I
don't have to deal with device resets, etc. Is that possible?
When I set kAudioOutputUnitProperty_StartTimestampsAtZero to false,
the AUHAL seems to maintain this stable timeline (doesn't reset when
the device resets) and what I'm hoping for is a way to access that
time when I'm not inside the input callback. If I had that, I'd be all
set.
Just curious, but why are you not acting on the discontinuities in
the time line, such as when headphones are plugged in? The whole
reason that you see these is to let you know that samples were
dropped. I'd imagine that knowing this would be very important in
implementing synch so that you can skip media or whatever you need to
do in order to maintain synch.
And if you're not implementing some kind of synchronization engine
(and even if you are), most quality engines I've run into don't
really care too about the exact values of the time stamps. Just
keeping track of how much has been played so far and how much is
needed to generate in the next cycle is usually enough to do just
about anything.
Perhaps you ought to take a step back and describe what you are
trying to do and perhaps we can point you in the right direction.
Another thing to consider is that if AUHAL's time stamp handling
isn't to your liking, you always have the option of dropping down and
talking directly to the HAL. There are no intervening layers between
your app and the time stamps to alter them in any way.
--
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