Насколько точно (с точки зрения времени) Windows воспроизводит звук? - PullRequest
6 голосов
/ 15 марта 2010

Допустим, я воспроизводил стереофонический WAV-файл с 317 520 000 семплов, что теоретически 1 час. Если предположить, что воспроизведение не прерывается, файл завершит воспроизведение через ровно один час, или есть некоторые незначительные изменения в скорости воспроизведения, так что он будет немного больше или чуть меньше (на некоторое количество миллисекунд) ) чем час?

Я пытаюсь синхронизировать анимацию со звуком, и я использую System.Diagnostics.Stopwatch, чтобы кадры соответствовали звуку. Но если скорость воспроизведения звука WAV в Windows может незначительно изменяться со временем, то звук будет не синхронизирован с анимацией, управляемой секундомером.

Что приводит ко второму вопросу: кажется, что Stopwatch - хотя и очень гранулированный и точный для коротких периодов времени - работает немного быстро. На моем ноутбуке Stopwatch, запускаемый ровно в течение 24 часов (согласно системному времени компьютера и реальному секундомеру), показывает, что прошедшее время составляет 24 часа плюс около 5 секунд (не миллисекунд).

Это известная проблема с Stopwatch? (Связанный вопрос был бы «я сумасшедший?», Но вы можете попробовать это сами.) Учитывая его использование в качестве инструмента диагностики, я могу видеть, где подобное расхождение проявляется только при измерении длительных периодов, для которых большинство люди будут использовать что-то, кроме Stopwatch.

Если мне действительно повезет, то и Stopwatch, и воспроизведение звука будут управляться одним и тем же базовым механизмом и, таким образом, будут синхронизироваться друг с другом в течение многих дней подряд. Есть ли шанс, что это правда?

Обновление : Я только что сделал математику, и если Stopwatch дрейфует на 5 секунд в течение 24 часов, это означает, что он будет дрейфовать на 10 миллисекунд через 172 секунды. Таким образом, через 3 минуты анимация начнет заметно пропадать.

Я экспериментирую с периодическим (каждые 10 секунд или около того) перезапуском таймера из обратного вызова waveOutWrite, но это не работает, потому что весь следующий набор событий таймера компенсируется любой неточностью обратного вызова случилось быть. Отстой, чтобы быть мной.

Ответы [ 2 ]

2 голосов
/ 15 марта 2010

Никакие часы не будут измерять время "точно", поскольку все физические устройства должны иметь некоторые отклонения и ошибки измерения. Это означает, что ВСЕ часы будут немного слишком быстрыми или слишком медленными (хотя количество ошибок может сильно отличаться в зависимости от часов).

В вашем случае аудиовыход управляется часами на звуковой карте, которая управляет ЦАП. Я не знаю платформу .NET, но я предполагаю, что секундомер - это какой-то системный таймер, что означает, что он управляется РАЗНЫМИ часами (предположительно, на материнской плате).

Теперь, в общем, две разные физические часы НИКОГДА не будут работать с одинаковой скоростью - по причинам, изложенным выше. Вот откуда вы получили несоответствие. То же самое произойдет с вашей анимацией - вы можете абсолютно никогда предполагать, что системные часы и часы ЦАП звуковой карты одинаковы - они будут отличаться!

Это означает, что если вы хотите синхронизировать два потока (видео и аудио), они должны управляться одинаковыми часами. Поскольку вы не можете изменить часы, управляющие звуковой картой, лучше всего синхронизировать все со звуковой картой.

0 голосов
/ 24 апреля 2010

Ларри Остерман предоставил ответ в комментарии:

FWIW, в Windows видео часы движимый звуковыми часами. Если вы рендеринг аудио, вы получите аудио часы, вызывая waveOutGetPosition (поскольку звук является изохронным, Положение прямо коррелируется с время). Все остальные аудио рендеринга API имеют аналогичный API "GetPosition" которые могут быть использованы для определения позиция воспроизведения звука.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...