Из моих тестов и из поиска, чтобы узнать больше о проблеме, я предпочитаю, что анимации CSS могут использовать физические часы, отличные от тех, которые использовались для потоковой передачи звука. Если так, возможно, ответ на этот вопрос заключается в том, что это не может быть сделано, но я спрашиваю, если я что-то упустил.
Это для моего онлайн метронома здесь .
Он может достаточно точно воспроизводить ноты в ответ на прослушиватель событий для события cite animationiteration. Eventlistener устанавливается, например, с помощью
x.addEventListener("animationstart",playSoundBall2);
См. здесь .
Однако, если я попытаюсь синхронизировать отскок с образцом точной синхронизации метода AudioContext, вот когда я столкнусь с проблемами.
Что я делаю, так это использую первый обратный вызов css только для записи времени контекста аудио в течение прошедшего времени css, равного 0. Затем я играю ноты, используя такие слова:
oscillator.start(desired_start_time);
Вы можете попробовать это с опцией на странице: «Запланируйте заметки заранее для точного сэмплирования звука» на странице здесь .
Вы можете проверить, насколько он дрейфует, включив «Добавить отладочную информацию к дополнительной информации» на той же странице.
На моей машине для разработки он отлично работает с Firefox. Но на Edge и Chrome он отходит от дребезга. И не устойчивым образом. Может подойти в течение нескольких минут, а затем отскок начинает замедляться относительно аудиопотока.
Это не проблема с активностью браузера - если я перемещаю браузер и пытаюсь прервать анимацию, худшее, что может случиться, - это то, что он может сбрасывать заметки, а если браузер не активен, он может сбрасывать заметки. Но те, которые он играет, точно в срок.
Мое лучшее предположение на данный момент заключается в том, что браузер использует системное время, а метод воспроизведения аудиоконтекста планирует его в точную точку непрерывного аудиопотока. Те, кто вполне может использовать разные аппаратные часы, из поиска в сети для проблемы.
Firefox может по какой-то причине использовать те же аппаратные часы, возможно, только на моей машине для разработки.
Если это правильно, скорее всего, нет способа гарантировать точную синхронизацию html-аудио, воспроизводимого с использованием AudioContext, с анимацией CSS.
Если это так, я бы также подумал, что вы, вероятно, не сможете гарантировать его синхронизацию с любой анимацией javascript, поскольку это будет зависеть от того, какие часы браузер использует для анимации, и как это относится к тем часам, которые используются для потоковой передачи звука. .
Но так ли это на самом деле? Что делают аниматоры, которым нужно синхронизировать звук с анимацией в течение длительного времени? Или они синхронизируют их только на несколько минут за раз?
Я бы не заметил, если бы метроном не использовался в течение длительного времени. Это может стать настолько плохим, что щелчок будет через несколько секунд после скачка всего через две или три минуты.
В другое время - хорошо, когда я писал это, у меня метроном включался в течение десяти минут в моем приложении для Windows 10, и он дрейфовал, но только на 20-30 мс относительно отскока. Так что это очень нерегулярно, так что вы не можете надеяться решить эту проблему, добавив некоторую фиксированную скорость, чтобы увеличить или замедлить их, чтобы они успевали друг с другом.
Я пишу это на всякий случай, если есть способ сделать это в javascript, все, что я пропускаю. Мне также интересно узнать, имеет ли это какое-то значение, если я использую другие методы анимации. Я не понимаю, как можно использовать звуковые контекстные часы напрямую для анимации, поскольку вы можете только планировать заметки в аудиопотоке, не можете запланировать обратный вызов в конкретное точное время в будущем в соответствии с аудиопотоком.