似乎AudioContext.createMediaStreamDestination（）默认为单声道输出。此默认值将在未来更改（https://groups.google.com/a/chromium.org/forum/#!topic/blink-reviews/Ksq6xUg1YsM），但有没有办法手动设置所需的输出通道数？
或者还有其他方法可以将流从WebAudio传输到WebRTC，同时保留正确数量的频道吗？
答案 0 :(得分：4)
目前这似乎很难做到。经过一些研究后，我发现documentation表示可以设置更多频道。尽管打电话给context.createMediaStreamDestination(2)我仍然在另一边收到单声道流。根据{{3}}讨论，您似乎可以添加多个流。尝试此操作时，本地（流媒体）和远程（接收器）似乎分别在调用pc.getLocalStreams()和pc.getRemoteStreams()时显示正确的流。所以你可以做的是使用this将输入分成两个单声道
你可以一起输出的输出。
可悲的是，由于webRTC和webAudio仍处于开发阶段，我们还无法通过网络音频API管道收到的流（使用context.createMediaStreamSource(<RTCStream>)，这仅适用于麦克风流），然后通过渠道合并使其再次排队。我还在测试是否将接收到的流添加到两个独立的音频元素中，以提供同步音频。
在对流添加多个曲目然后发送该流之后进行了一些测试后，接收方的<audio>标记同时播放了这两个曲目，并且它实际上将它们添加起来，就像包含左边的曲目一样两个扬声器上都有声道，右边也是如此。所以我还没有能够将接收器分开，但至少能够通过两个不同的通道发送左右音频。所以，是的，现在是时候开发人员通过网络音频API为我们提供管道接收音频的机会。
streamDestinationNode创建的流似乎是一个立体声流。您可以找到channel splitter的示例（请记住在src字段中添加一些音乐）
这种行为也是here我们现在播放收到的流的方式 - 从中创建一个objectURL并将其分配给<audio>元素的src。
这意味着它与RTC流媒体系统本身有关。在使用RTCPeerConnection测试上述代码后，似乎只是混合了频道。
所以我想要使用另一个编解码器，Opus。我发现了一些代码将其更改为该编解码器，并搜索了将编解码器设置为使用立体声的方法。我找到了not related和this，虽然我不知道如何使用它。除了改为Opus并没有自动将其改为立体声（如果编解码器设置为自动执行此操作，可能就是这样）。
我找到了为{Opus}创建sdp的this。我正在调查。
我在draft的第三个版本中找到了它。这是一个例子，它非常简单。将stereo=1; sprop-stereo=1添加到a=fmtp行，您就完成了。该文档还包含这些属性的规范：
stereo：指定解码器是否更喜欢接收立体声或 单声道信号。可能的值为1和0，其中1指定了该值 优选立体声信号，0指定仅单声道信号 是首选。独立于每个接收器的立体声参数 必须能够接收和解码立体声信号，但发送立体声 向接收器发出信号，表示对单声道信号的偏好可能 导致高于必要的网络利用率和编码 复杂。如果未指定任何值，则假定为mono（立体声= 0）。
sprop-stereo：指定发件人是否可能生成 立体声音频。可能的值为1和0，其中1指定了该值 很可能会发送立体声信号，而发送者可能会发送0个信号 可能只发送单声道。这不是发件人的保证 永远不会发送立体声音频（例如，它可以发送预先录制的音频 提示使用立体声），但它向接收者表明了 收到的信号可以安全地下混到单声道。这个参数是 有助于避免通过操作音频来浪费接收器资源 处理管道（例如，回声消除）在立体声时不 必要。如果未指定任何值，则假定为mono （sprop-立体声= 0）。
我希望这会对你有所帮助。我希望这是为了获得更高质量的音频，我建议您仔细阅读rtp opus draft以了解有关高质量音频流的更多信息。
在与朋友测试之后，似乎编码方（发送音频的一方）在chrome 34中产生噪音。我一直在使用chrome 36（dev和canary），并且此错误不会发生那里。 （当从chrome 34流式传输到36时，你会得到噪音，当你从36流式传输到34时，你不会这样，所以这在编码方面是一个问题。）
（为什么我写下这样详细的答案？我也想知道自己：D）。