似乎 AudioContext.createMediaStreamDestination() 默认为单声道输出。此默认值正在更改，但有没有办法手动设置所需的输出通道数？
或者有没有其他方法可以在保留正确数量的频道的同时将流从 WebAudio 获取到 WebRTC？
问问题
1707 次
1 回答
7
目前这似乎很难做到。经过一番研究，我发现文档说可以设置更多频道。尽管打电话context.createMediaStreamDestination(2)，我仍然在另一边收到单声道流。根据这个讨论，您似乎可以添加多个流。尝试此操作时，本地（流媒体）和远程（接收者）似乎在分别调用pc.getLocalStreams()和时都显示了正确的流pc.getRemoteStreams()。所以你可以做的是使用通道分离器将输入分成两个单声道输出，你可以将它们一起流式传输。
遗憾的是，由于 webRTC 和 webAudio 仍在开发中，我们还不能通过网络音频 API 管道接收到的流（使用context.createMediaStreamSource(<RTCStream>)，这仅适用于麦克风流），然后通过通道合并发送它以使其再次上线。我仍在测试是否将接收到的流添加到两个单独的音频元素中以提供同步音频。
小更新
在向一个流添加多个轨道然后发送该流进行了一些测试之后，接收方的<audio>标签播放了两个轨道，它实际上将它们加起来，就像包含左声道的轨道在两个扬声器上播放一样，右声道也是如此. 所以我还不能在接收端拆分它们，但至少能够通过两个不同的通道发送左右音频。所以，是的，是时候让开发人员有机会通过 Web 音频 API 管道接收到的音频了。
另一个更新
似乎由 astreamDestinationNode自动创建的流是立体声流。你可以在这里找到一个例子（记得在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 指定仅首选单声道信号。独立于立体声参数，每个接收器都必须能够接收和解码立体声信号，但是将立体声信号发送到表示偏爱单声道信号的接收器可能会导致高于必要的网络利用率和编码复杂度。如果未指定任何值，则假定为单声道 (stereo=0)。
sprop-stereo：指定发送者是否可能产生立体声音频。可能的值为 1 和 0，其中 1 表示可能发送立体声信号，而 0 表示发送方可能只发送单声道信号。这并不能保证发送者永远不会发送立体声音频（例如，它可以发送使用立体声的预先录制的提示），但它向接收者表明接收到的信号可以安全地缩混为单声道。此参数有助于避免在不需要时以立体声操作音频处理管道（例如回声消除）来浪费接收器资源。如果未指定任何值，则假定为单声道 (sprop-stereo=0)。
我希望这可以帮助你。正如我所期望的那样，这是为了获得更高质量的音频，我建议您通读该文档以了解有关高质量音频流的更多信息。
缺点
在与朋友一起测试后，似乎编码端（发送音频的端）在 chrome 34 中产生了噪音。我一直在使用 chrome 36（开发和金丝雀），并且没有出现这个错误。（当从 chrome 34 流式传输到 36 时，你会得到噪音，当从 36 流到 34 时，你不会，所以这是编码方面的问题）。
（为什么我要写这么详尽的答案？我也想了解自己：D）。
于 2014-04-26T19:54:00.897 回答