• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: IPhone's AudioTimeStamp is not mach_absolute_time
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
References: 
 >IPhone's AudioTimeStamp is not mach_absolute_time (From: "Konrad Gianno" <email@hidden>)

  • Prev by Date: AU which outputs MIDI?
  • Next by Date: Re: writing audio from a AUGraph to disk
  • Previous by thread: IPhone's AudioTimeStamp is not mach_absolute_time
  • Next by thread: writing audio from a AUGraph to disk
  • Index(es):
    • Date
    • Thread