Каково время задержки (или задержки) для обратных вызовов из метода waveOutWrite API?

У меня есть спор с некоторыми разработчиками на другом форуме о точной генерации событий MIDI (примечание о сообщениях и т. Д.). Человеческое ухо довольно чувствительно к небольшим временным неточностям, и я думаю, что их основная проблема заключается в использовании таймеров с относительно низким разрешением, которые квантовывают свои события с интервалами в 15 миллисекунд (что достаточно велико, чтобы вызвать ощутимые неточности).

Около 10 лет назад я написал пример приложения (Visual Basic 5 для Windows 95), в котором использовался программный синтезатор и проигрыватель MIDI. Основной предпосылкой была система воспроизведения с подпрыгивающим буфером, где каждый буфер представлял собой длительность шестнадцатой ноты (пример: при 120 четвертных нотах в минуту каждая четвертная нота составляла 500 мс, и, следовательно, каждая шестнадцатая нота составляла 125 мс, поэтому каждая буфер составляет 5513 образцов). Каждый буфер воспроизводился с помощью метода waveOutWrite, а функция обратного вызова из этого метода использовалась для постановки в очередь следующего буфера, а также для отправки MIDI-сообщений. Это обеспечивало синхронизацию звука на основе WAV и звука MIDI.

На мой взгляд, этот метод работал отлично - ноты MIDI не звучали даже немного не в ногу (тогда как если вы используете обычный таймер с точностью до 15 мс для воспроизведения ноты MIDI, они будут звучать заметно не в ногу).

Теоретически, этот метод будет производить синхронизацию MIDI с точностью до сэмпла, или 0,0227 миллисекунд (так как на миллисекунду приходится 44,1 сэмпла). Я сомневаюсь, что это истинная задержка этого подхода, так как, вероятно, существует небольшая задержка между завершением буфера и уведомлением обратного вызова waveOutWrite. Кто-нибудь знает, насколько велика будет эта задержка?

Ответы на вопрос(3)

Ваш ответ на вопрос