当两个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语言音频的完美同步应该是可能的(就像在，这并不违反物理定律)。对于此应用程序，“完美同步”意味着侦听器C应该同时听到B在time T中听到的内容，以及B在time T中播放的。

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

• B 合并了音频.，因为B的性能已经“同步”了，所以我认为它们的合并流可能也是同步的。但是，输出仍然存在延迟。我猜，从B的本地stream.
• A接收数据到完成合并的MediaStream 的处理之间所经过的时间来看，合并的合并了音频。在这种方法中，主机A接收对等B的音频，并试图在合并之前通过DelayNode传递A的本地音频，从而解释这两个流之间的时间差。我使用WebRTC统计API尝试一些值，如STUN往返时间、抖动缓冲区延迟和MediaStream延迟估计，但是没有任何组合似乎可以提供完美的延迟偏移量。

有一个已知的方法来同步音频这种方式与WebRTC？这是一个获得正确的WebRTC统计数字的问题，还是我的方法完全偏离了？

Answer 1

对于解决方案B合并音频，延迟来自延迟浏览器=>环境和环境=>浏览器:由于B在环境中监听和播放，因此这两个流在环境中是同步的，因此B的浏览器中这两个延迟之和。这种影响的大小取决于B的硬件、操作系统和浏览器；没有办法测量它。有一些工具可用于此度量，如jack (https://sources.debian.org/src/jack-delay/0.4.2-1/README/)，但这些工具在浏览器中不起作用。由于您是在WebRTC设置中，所以我认为类似于https://github.com/ntgiwsvp/looper中的前端/交叉关联. is是您的选择。

对于解决方案A合并音频(与C合并音频类似)，到目前为止，我只知道一个经过验证的解决方案来解决这个问题，不幸的是，这是个小问题：

• 在音频轨道上增加了一个额外的信道1。如上所述，
• A将其性能提交给频道0，并向信道1提交周期性同步信号，
• B通过其往返延迟浏览器<=>环境延迟信道1。B的输出流包括她在0频道的记录和1频道的延迟同步信号。
• (比如C )一旦接收到A和B的流，就可以通过适当的延迟使用通道A1和B1来同步流，然后播放频道A0和B0.

。

在上面提到的存储库中的文件前端/client.js中，您需要的大部分内容都有一个工作实现。(您的设置有点不同，但同样的概念也适用。)