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 17:08:37 -0700
> 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
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.
> Bill and I were talking about this and we're confused (well I'm
> confused at any rate). Everything you've said so far made me think
> that you were talking about getting the input data captured from a
> given hardware device using AUHAL. Conversely, Bill thought that you
> were talking about sending output data to the device for it to put
> out the speaker.
Sorry for any confusion. I'm only sending output data to the device to
play. I find and open the default output audio unit, initialize it,
then install an input callback. I construct the audio data myself and
then provide that data to the input callback when it calls me.
_______________________________________________
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