Как точно (с точки зрения времени) Windows играет аудио?
Скажем, я играю файл WAV стерео с 317 520 000 образцов, который теоретически 1 час длиной. Не принимая прерываний воспроизведения, файл закончит играть точно через один час или является там некоторой случайной крошечной вариацией в скорости воспроизведения, таким образом, что это было бы немного больше или немного меньше (некоторым количеством миллисекунд), чем один час?
Я пытаюсь синхронизировать анимацию с аудио, и я использую a System.Diagnostics.Stopwatch сохранять кадры, соответствующие аудио. Но если скорость воспроизведения аудио WAV в Windows может варьироваться немного со временем, то аудио будет дрейфовать из синхронизации с управляемой Секундомером анимацией.
Который приводит к второму вопросу: это появляется это a Stopwatch - в то время как очень детализированный и точный на короткое время - работает немного быстро. На моем ноутбуке, a Stopwatch выполненный в течение точно 24 часов (как измеряется к системному времени компьютера и реальному секундомеру) показывает прошедшее время 24 часов плюс приблизительно 5 секунд (не миллисекунды).
Это известная проблема с Stopwatch? (Связанный вопрос был бы, "действительно ли я являюсь сумасшедшим?", но можно попробовать его за себя.), Учитывая его использование как инструмент диагностики, я вижу, где несоответствие как это только обнаружилось бы при измерении долгих продолжительностей, на которые большинство людей будет использовать что-то другое, чем a Stopwatch.
Если я действительно удачлив, то оба Stopwatch и воспроизведение звука управляется тем же базовым механизмом и таким образом останется в синхронизации друг с другом очень долго. Шанс это верно?
Обновление: Я просто сделал математику, и если Stopwatch дрейфы на 5 секунд более чем 24 часа, это означает, что будет дрейфовать 10 миллисекундами после всего 172 секунды. Таким образом через 3 минуты анимация начнет быть ощутимо из синхронизации.
Я экспериментирую с периодически (каждые 10 секунд или так) перезапуск таймера от waveOutWrite обратного вызова, но это не работает, потому что затем целый следующий набор событий таймера смещается тем, чем погрешность обратного вызова, оказалось, была. Сосет, чтобы быть я.
2 ответа
Ларри Остерман предоставил ответ в комментарии:
FWIW, в Windows видеочасы управляются аудиочасами. Если вы визуализируете звук, вы получаете звуковые часы , вызывая waveOutGetPosition (поскольку звук изохронен, позиция напрямую коррелируется с {{1 }} время). Все остальные API-интерфейсы рендеринга аудио имеют аналогичный API "GetPosition" , который можно использовать для определения позиции рендеринга аудио.
Никакие часы не будут измерять время «точно», так как все физические устройства должны иметь некоторые отклонения и ошибки измерения. Это означает, что ВСЕ часы будут немного слишком быстрыми или слишком медленными (хотя количество ошибок может сильно отличаться в зависимости от часов).
В вашем случае аудиовыход управляется тактовой частотой звуковой карты, которая управляет ЦАП. Я не знаю платформу .NET, но предполагаю, что секундомер - это своего рода системный таймер, что означает, что он управляется ДРУГИМИ часами (предположительно, теми, что на вашей материнской плате).
В общем, два разных физических генератора НИКОГДА не будут работать с одинаковой скоростью - по причинам, изложенным выше. Вот откуда у вас возникло несоответствие. То же самое произойдет и с вашей анимацией - вы не можете абсолютно предполагать, что системные часы и часы ЦАП звуковой карты одинаковы - они будут отличаться!
Это означает, что если вы хотите поддерживать синхронизацию двух потоков (видео и аудио), они должны управляться одними и теми же часами. Поскольку вы не можете изменить часы, которые управляют вашей звуковой картой, рекомендуется синхронизировать все со звуковой картой.