Re: IPhone's AudioTimeStamp is not mach_absolute_time
Re: IPhone's AudioTimeStamp is not mach_absolute_time
- Subject: Re: IPhone's AudioTimeStamp is not mach_absolute_time
- From: William Stewart <email@hidden>
- Date: Fri, 31 Oct 2008 14:02:12 -0700
the audio time stamp's mHostTime contains a value as you describe -
the system bus clock.
The rate scalar describes the difference between that notion of "real
time" progressing versus the idealised time of what it "should be" if
it were running exactly at the specified sample rate.
So by combining these values you should be able to derive the
progression of time for the audio hardware
We use these time stamps ourselves, so I would be concerned if the
host time was indeed behaving as you describe.
Can you file a bug report with some code to reproduce the problem so
we can take a look? (bugreporter.apple.com) thanks
Bill
On Oct 30, 2008, at 3:13 PM, Konrad Gianno wrote:
I am writing an iPhone application that continuously runs a
recording audio queue. I need to be able to extract rather precise
timing information out of the audio queue buffers passed from the
system, and I need to relate that timing information with the
current system time. From different posts on the web, I understood
that the mHostTime field of AudioTimeStamp - provided together with
the audio buffers - is the system bus clock, accessed via routines
in mach/mach_time.h. However, it seems that this is not always the
case. Experiments show that during some runs everything works as
expected: The mHostTime field of AudioTimeStamp clicks as fast as
the value returned by mach_absolute_time, and the values have
consistent magnitudes. Later however, during a different run on the
same device, the host-time of the AudioTimeStamp runs at the double
clock rate compared to the time returned by the mach_absolute_time
routine.
I can easily detect situations in which the two clocks run at
different speed, and I could create a conversion routine between the
two times by establishing an anchor point, since I know the relation
of the clock speeds. The problem is that establishing an anchor
point is not easy, since I receive the audio buffer timing
information asynchronously.
Being able to directly access the clock used by the system to fill-
in the AudioTimeStamp would solve my issues. What is the time used
in AudioTimeStamp and how can I access it?
_______________________________________________
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
_______________________________________________
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