views:

147

answers:

1

I am trying to grab times out of recorded buffers in my AudioInputCallback function for a recording queue. Unfortunately the timestamps I'm seeing aren't as expected. Here's an example (using AudioTimeStamp.mHostTime):

2010-01-21 14:03:35.252 [61694:207] 1288747268011206    1288747396166138    -128154932
2010-01-21 14:03:35.344 [61694:207] 1288747360891024    1288747396166138    -35275114
2010-01-21 14:03:35.437 [61694:207] 1288747453770843    1288747396166138    57604705
2010-01-21 14:03:35.530 [61694:207] 1288747546652078    1288747396166138    150485940

The first timestamp is buffer time, the second is reference time (time at which the button was pressed, I am using AudioQueueDeviceGetCurrentTime) and third is the delta between the two. As expected, the buffers slightly lag "real time" and catch up after a couple buffer callbacks have been run.

Now when closing and reopening this queue, the story is much different:

2010-01-21 14:03:46.769 [61694:207] 1288755719477798    1288758853485434    -3134007636
2010-01-21 14:03:46.862 [61694:207] 1288755812365464    1288758853485434    -3041119970
2010-01-21 14:03:46.955 [61694:207] 1288755905305200    1288758853485434    -2948180234

As you can see, the timestamps (ns I suppose?) are way different the second time around. They don't catch up to real time for several seconds. This behavior is not at all reproducible -- the timestamps are sometimes right and sometimes wrong. They are always wrong the first time I open the queue however.

+1  A: 

So again taking a breather and posting on SO has solved it ;) You shouldn't get the queue's current timestamp while your queue is stopped/paused :^P

sehugg