Javascript 未压缩、未加密、未更改的原始PCM音频数据通过WebRTC流传输

我正在使用WebRTC在两个电子窗口进程之间传输实时音频流。没有ICE或STUN服务器，或者类似的东西，通过电子IPC通信（基于）手动建立连接

注意：从音频流本身的技术角度来看，这与同一域上的两个浏览器选项卡之间的流非常相似（如果不相同），因此这主要不是关于Electron本身的问题，尽管Electron IPC显然会被浏览器等效物替代

音频流工作正常，我可以在生成音频时实时将音频从一个窗口传输到另一个窗口。也就是说，我可以在窗口“A”中生成音频（Web audio API）并通过

收听，当页面上基本上有任何内容时，这在生产代码中是不可用的，因为它被设计破坏了（它在UI线程上处理音频，甚至通过轻微的UI交互导致音频故障）

因此，基本上，正因为如此（据我所知），我唯一的选择是将带有WebRTC流的音频传输到另一个窗口进程，在那里执行ScriptProcessorNode处理（在该窗口中没有其他事情发生，DOM为空，因此处理总是很好且平滑），然后将结果发送回

这是可行的，但在流媒体播放过程中音频会发生变化，我希望避免这种情况（见上文）


为什么不使用AudioWorklet？
因为Electron不幸落后于Chrome的5个版本（目前为59版），而且根本没有发布AudioWorklet。
为什么不通过web套接字发送WAAPI使用的原始缓冲区？您可以在接收端设置一个循环，当接收到数据时，循环将被填充。@K3N--这不需要再次使用
ScriptProcessorNode
来澄清：进程之间的通信不是问题。我可以很容易地设置套接字连接来传输示例块，但这需要音频数据跳到主线程上，这在一个非常重要的应用程序中是不可能的。数据传输必须源于音频线程。您可以使用worker提供的web套接字来卸载主线程（使用可转移对象/类型化数组）。WebRTC面临的挑战是音频将被编码（音频/rtx）并以RTP数据包中的帧形式发送，这是我记忆中的。另一种可能的选择是使用WebRTC的数据通道。@K3N--如果不先使用
ScriptProcessorNode
将音频数据从音频线程移动到主线程，则无法将音频数据获取到web工作线程，因为
AudioContext
在工作线程中不起作用。