音频队列：记录缓冲区的时间戳
我试图从我的 AudioInputCallback 函数中的记录缓冲区中获取记录队列的时间。不幸的是，我看到的时间戳与预期不符。这是一个示例（使用 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
第一个时间戳是缓冲时间，第二个时间戳是参考时间（按下按钮的时间，我使用 AudioQueueDeviceGetCurrentTime）第三是两者之间的差异。正如预期的那样，缓冲区稍微滞后于“实时”，并在运行几个缓冲区回调后赶上。
现在，当关闭并重新打开这个队列时，情况就大不相同了：
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
正如您所看到的，时间戳（我想是ns？）第二次有很大不同。他们有几秒钟没有赶上实时。这种行为根本不可重现——时间戳有时是正确的，有时是错误的。然而，当我第一次打开队列时，他们总是错的。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
因此，再次喘口气并在 SO 上发帖已经解决了这个问题；）当您的队列停止/暂停时，您不应该获得队列的当前时间戳:^P
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