Chrome M34 中 MediaStreamDestination 的 AudioContext 立体声输出

Question

似乎 AudioContext.createMediaStreamDestination() 默认为单声道输出。此默认值正在更改，但有没有办法手动设置所需的输出通道数？

或者有没有其他方法可以在保留正确数量的频道的同时将流从 WebAudio 获取到 WebRTC？

Answer 1

这目前似乎很难做到。经过一番研究，我发现文档说可以设置更多频道。尽管打电话，context.createMediaStreamDestination(2)我仍然在另一边收到单声道流。根据此讨论，您似乎可以添加多个流。尝试此操作时，本地（流媒体）和远程（接收者）似乎分别在调用pc.getLocalStreams()和时显示正确的流pc.getRemoteStreams()。因此，您可以做的是使用通道分配器将输入拆分为两个单声道输出，您可以将它们一起流式传输。

遗憾的是，由于 webRTC 和 webAudio 仍在开发中，我们还不能通过网络音频 API 对接收到的流进行管道传输（使用context.createMediaStreamSource(<RTCStream>)，这仅适用于麦克风流），然后仅通过通道合并将其发送以使其再次连接。我仍在测试将接收到的流添加到两个单独的音频元素是否会提供同步音频。

小更新

在将多个轨道添加到流中然后发送该流进行一些测试之后，接收方的<audio>标签播放了两个轨道，并且实际上将它们相加，就像包含左声道的轨道在两个扬声器上播放一样，右侧也是. 所以我还没有能够将它们分开接收端，但至少能够通过两个不同的通道发送左右音频。所以是的，现在是开发人员给我们机会通过网络音频 API 传输接收到的音频的时候了。

另一个更新

似乎streamDestinationNode自动创建的流是立体声流。你可以在这里找到一个例子（记得在src字段中添加一些音乐）。
这种行为也与我们现在播放接收到的流的方式无关- 从中创建一个 objectURL 并将其分配给<audio>元素的 src。
这意味着它与 RTC 流媒体系统本身有关。用一个 测试了上面的代码后RTCPeerConnection，它似乎只是混合了通道。

使用编解码器

所以我考虑使用另一个编解码器 Opus。我找到了一些代码将其更改为该编解码器，并搜索了将编解码器设置为使用立体声的方法。我发现了this和this，虽然我不知道如何使用它。除此之外，更改为 Opus 并不会自动将其更改为立体声（如果编解码器设置为自动执行此操作，则可能是这样）。

我找到了为 Opus 创建 sdp 的草稿。我正在调查。

编辑：找到了

我在rtp opus draft的第三版中找到了它。这是在一个例子中，它非常简单。添加stereo=1; sprop-stereo=1到a=fmtp行中，您就完成了。该文档还包含这些属性的规范：

立体声：指定解码器更喜欢接收立体声还是单声道信号。可能的值为 1 和 0，其中 1 指定首选立体声信号，0 指定仅首选单声道信号。独立于立体声参数，每个接收器都必须能够接收和解码立体声信号，但将立体声信号发送到表示偏好单声道信号的接收器可能会导致高于必要的网络利用率和编码复杂度。如果未指定值，则假定为单声道（立体声 = 0）。

sprop-stereo：指定发送方是否可能产生立体声音频。可能的值为 1 和 0，其中 1 指定可能发送立体声信号，0 指定发送方可能只发送单声道。这并不能保证发送方永远不会发送立体声音频（例如，它可以发送使用立体声的预先录制的提示），但它向接收方表明接收到的信号可以安全地缩混为单声道。此参数有助于避免在不必要时以立体声方式操作音频处理管道（例如回声消除）而浪费接收器资源。如果未指定值，则假定为单声道 (sprop-stereo=0)。

我希望这可以帮助你。正如我期望这是为了获得更好的音频质量，我建议您通读该文档以了解有关高质量音频流的更多信息。

缺点

与朋友对此进行测试后，似乎编码端（发送音频的端）在 chrome 34 中产生噪音。我一直在使用 chrome 36（开发和金丝雀），并且在那里没有发生此错误。（从 chrome 34 流式传输到 36 时会产生噪音，而从 36 流式传输到 34 时则不会，因此这是编码方面的问题）。

（为什么我要写这么详细的答案？我也想了解自己：D）。