Можно ли синхронизировать звук при объединении двух пиров WebRT C? - PullRequest
1 голос
/ 07 апреля 2020

Я работаю над приложением WebRT C, в котором ровно 2 музыканта совместно работают над живым выступлением и передают объединенный звук третьей стороне. Поскольку невозможно, чтобы оба музыканта услышали друг друга с идеальной синхронизацией, мой подход таков:

  • Музыкант A - хост, и он работает так, как считает нужным
  • Музыкант B - гость, который слышит звук хоста, а затем вовремя выполняет то, что слышит из удаленного потока
  • Используя API Web Audio, A * Аудиопотоки 1013 * и B объединены , и этот объединенный звук передается слушателю в новом потоке C
A ----> B    (host streams to guest over WebRTC)
 \     /
  \   /
   ┙ ┕
    C        ("host" and "guest" streams merged using Web Audio API)

Я считаю, что получение идеальной синхронизации звука для C должно быть возможным (как, например, не нарушает l aws физики). Для целей данного приложения «идеальная синхронизация» означает, что слушатель C должен слышать то, что B слышит в то время T одновременно с тем, что B сыграно в то время T.

Я пробовал два подхода к этому, ни один из них не был успешным:

  • B объединяет аудио. Поскольку исполнение уже отображается "in-syn c" для B , я подумал, что их объединенный поток может быть синхронизирован c как хорошо. Тем не менее, выход по-прежнему содержит задержку. Я предполагаю, что прошло время между B локальным MediaStream, принимающим данные, и этими данными, завершающими обработку для объединенного потока.

  • A объединяет аудио. В этом подходе хост A получает аудио равноправного B и пытается учесть разницу во времени между двумя потоками, передавая A локальное аудио через DelayNode перед объединением. Я использую WebRT C Статистика API, чтобы попробовать значения, такие как время выполнения STUN, задержка дрожания буфера и оценка задержки MediaStream, но ни одна комбинация не дает идеального смещения задержки.

Is существует известный способ для синхронизации аудио таким образом с WebRT C? Это вопрос получения правильной статистики WebRT C, или мой подход полностью отключен?

1 Ответ

0 голосов
/ 11 апреля 2020

для решения B объединяет аудио , задержка происходит из-за задержки browser => environment and environment => browser: так как B прослушивает и воспроизводит в среде, два потока будут синхронизированы c в среде, так что сумма этих двух задержек в браузере B. Величина этого эффекта зависит от аппаратного обеспечения B, операционной системы и браузера; нет способа обойти это измерение. Для этого измерения доступны инструменты, такие как задержка домкрата (https://sources.debian.org/src/jack-delay/0.4.2-1/README/), но они не работают в браузере. Поскольку вы находитесь в настройке WebRT C, я думаю, что нечто подобное фронтенду / кросскорреляции. js in https://github.com/ntgiwsvp/looper - ваш путь к go.

Для решения A объединяет аудио (и аналогично для C объединяет аудио ), я знаю только одно проверенное решение этой проблемы на данный момент, которое, к сожалению, является своего рода взломом:

  • Добавить дополнительный канал 1. к звуковой дорожке.
  • A передает свое исполнение на канал 0, а периодический c сигнал синхронизации - на канал 1
  • B. задерживает канал 1 своей браузерной средой с задержкой в ​​оба конца <=>, как описано выше. Выходной поток В состоит из ее записи в канале 0 и сигнала синхронизации с задержкой в ​​канале 1.
  • Когда кто-нибудь, скажем, C, принимает потоки А и В, он может использовать каналы А1 и В1 для синхронизации Потоки через соответствующую задержку, затем воспроизводите каналы A0 и B0.

Существует рабочая реализация большинства того, что вам нужно, в файле frontend / client. js в вышеупомянутом репозитории. (Ваши настройки немного отличаются, но применяются те же понятия.)

...