合并两个 WebRTC 对等点时是否可以同步音频？

Question

我正在开发一个 WebRTC 应用程序，正好有 2 位音乐家合作进行现场表演，并将组合的音频流式传输给第三方。由于不可能让两位音乐家完美同步地听到对方的声音，我的方法是：

音乐家A是主持人，按他们认为合适的方式表演
音乐家B是客人，他听到主持人的音频，然后根据他们从远程流中听到的内容及时表演
使用网络音频API、A和B的音频流合并，并且此合并后的音频在新流中共享给听众 C

A ----> B    (host streams to guest over WebRTC)
 \     /
  \   /
   ┙ ┕
    C        ("host" and "guest" streams merged using Web Audio API)

我相信为 C 实现完美的音频同步应该是可能的（例如，不违反物理定律）。出于本申请的目的，"perfect synchronization" 表示听众 C 应该听到 B 听到的在时间 T 与 B 在时间 T.

播放同时进行

我试过两种方法，都没有成功：

B 合并音频 因为演出已经出现"in-sync" for B，我认为他们的合并流也可能是同步的。但是，输出仍然包含延迟。我猜测从 B 的本地 MediaStream 接收数据到该数据完成合并流的处理之间经过的时间。
A 合并音频。 在这种方法中，主机 A 接收对等 B 的音频，并尝试通过在之前通过延迟节点传递 A 的本地音频来解决两个流之间的时间差合并。我使用 WebRTC 统计数据 API 来尝试 STUN 往返时间、抖动缓冲区延迟和 MediaStream 延迟估计等值，但似乎没有任何组合可以提供完美的延迟偏移。

是否有已知方法可以通过这种方式与 WebRTC 同步音频？是获取正确的 WebRTC 统计信息的问题，还是我的方法完全偏离了？

Answer 1

解决方案B合并音频，延迟来自延迟浏览器=>环境和环境=>浏览器：由于B在环境中听和播放，所以两个流将在环境中同步，因此在 B 的浏览器中将上述两个延迟的总和关闭。这种影响的大小取决于 B 的硬件、操作系统和浏览器；没有办法衡量这一点。有可用于此测量的工具，例如 jack-delay（https://sources.debian.org/src/jack-delay/0.4.2-1/README/), but these do not work in the browser. Since you are in the WebRTC setting, I think something similar to frontend/crosscorrelation.js in https://github.com/ntgiwsvp/looper 是您的选择。

对于解决方案 A 合并音频（并且类似地对于 C 合并音频），我知道只有一个经过验证的解决方案到目前为止的问题，不幸的是有点hack：

向音轨添加额外的声道 1。
A 向通道 0 提交其性能，向通道 1 提交周期性同步信号
B 通过她的往返延迟浏览器 <=> 环境延迟频道 1，如上所述。 B 的输出流由她在通道 0 中的录音和通道 1 中的延迟同步信号组成。
一旦有人，比如 C，同时收到 A 和 B 的流，他们可以使用通道 A1 和 B1 通过适当的延迟同步流，然后播放通道 A0 和 B0。

在上述存储库的 frontend/client.js 文件中，您需要的大部分内容都有一个有效的实现。（您的设置略有不同，但适用相同的概念。）

合并两个 WebRTC 对等点时是否可以同步音频？

Is it possible synchronize audio when combining two WebRTC peers?

audio

streaming

webrtc

web-audio-api

live-streaming