mono - Chrome M34 中 MediaStreamDestination 的 AudioContext 立体声输出

Question

似乎 AudioContext.createMediaStreamDestination() 默认为单声道输出。这个默认is being changed ，但是有没有办法手动设置所需的输出 channel 数？
或者有没有其他方法可以在保留正确数量的 channel 的同时将流从 WebAudio 获取到 WebRTC？

Answer 1

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

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

小更新

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

另一个更新

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

使用编解码器

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

我找到了一个 draft为 Opus 创建 sdp。我正在调查。

编辑:找到了

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

stereo: specifies whether the decoder prefers receiving stereo or mono signals. Possible values are 1 and 0 where 1 specifies that stereo signals are preferred and 0 specifies that only mono signals are preferred. Independent of the stereo parameter every receiver MUST be able to receive and decode stereo signals but sending stereo signals to a receiver that signaled a preference for mono signals may result in higher than necessary network utilisation and encoding complexity. If no value is specified, mono is assumed (stereo=0).

sprop-stereo: specifies whether the sender is likely to produce stereo audio. Possible values are 1 and 0 where 1 specifies that stereo signals are likely to be sent, and 0 speficies that the sender will likely only send mono. This is not a guarantee that the sender will never send stereo audio (e.g. it could send a pre- recorded prompt that uses stereo), but it indicates to the receiver that the received signal can be safely downmixed to mono. This parameter is useful to avoid wasting receiver resources by operating the audio processing pipeline (e.g. echo cancellation) in stereo when not necessary. If no value is specified, mono is assumed (sprop-stereo=0).

我希望这可以帮助你。因为我希望这是为了获得更好的音频质量，我建议您通读一下 doc了解更多关于高质量音频流的信息。

缺点

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

(为什么我要写这么详细的答案？我也想了解自己:D)。