Аудио очередь: метки времени для записанных буферов

Я пытаюсь получить время из записанных буферов в моей функции 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

Как вы можете видеть, временные метки (я полагаю, нс?) Во второй раз сильно различаются. Они не успевают за реальным временем в течение нескольких секунд. Такое поведение совершенно невозможно воспроизвести - временные метки иногда правильные, а иногда неправильные. Однако они всегда ошибаются, когда я впервые открываю очередь.


person sehugg    schedule 21.01.2010    source источник


Ответы (1)


Итак, снова взяв передышку и отправив сообщение на SO, вы ее решили;) Вы не должны получать текущую временную метку очереди, пока ваша очередь остановлена ​​/ приостановлена: ^ P

person sehugg    schedule 21.01.2010