来自 WebSocket 的 Webaudio 播放有丢弃

Question

我有一个软件定义的无线电，播放来自WebSocket服务器的音频流，还有一个使用数据并使用AudioBufferSourceNode播放数据的客户端。

它主要有效。唯一的问题是每隔几秒钟就会有短暂的丢失，这可能是由创建每个连续的 AudioBufferSourceNode 实例所涉及的开销引起的。WebAudio草案规范规定，AudioBuffer应该用于播放不超过一分钟左右的声音，并且应该使用MediaElementSourceNode播放更长的声音。这对我不起作用，因为我需要播放来自 WebSocket 源的音频，而且我知道没有办法使媒体元素(例如 HTML5 音频元素(与 WebSocket 一起工作。

也许我正在尝试做一些WebAudio无法支持的事情，将AudioBufferSourceNode实例串在一起，并期望它们一个接一个地无缝播放。但似乎应该有一种方法可以通过WebAudio播放WebSocket数据，事实上auroa.js(与aurora-websocket一起.js插件(似乎可以做到这一点。我使用 aurora.js 编写了一个客户端，但我遇到了其他问题，为此我在 Github 上创建了一个 auroa.js 问题。与此同时，我希望我可以在我的客户端中做他们似乎已经使用 WebAudio 从 WebSocket 无缝播放数据所做的工作。

下面是我的代码的省略视图，以显示我正在使用的实现。

var context = ...
var gainNode = ...
var playBuffer = function(buf) {
   var source = context.createBufferSource();
   source.buffer = buf;
   source.connect(gainNode);
   source.start();
};
var socket = ...
socket.binaryType = 'arraybuffer';
socket.addBinaryListener(function (data) {
     context.decodeAudioData(data, playBuffer);
});
socket.connect...

我还尝试了一种实现，其中我跟踪来自WebSocket的传入缓冲区，并在从上一个AudioBufferSourceNode接收"结束"事件后，通过AudioBufferSourceNode按接收顺序播放它们。这具有与上述实现相同的dropout问题。

Answer 1

您的流真的可以保证在每个网络块中获得完整的音频文件吗？ (解码音频数据不适用于部分 MP3 块。

似乎(从上面的代码片段中(您只是依靠网络计时在正确的时间启动流块？ 这保证不会正确排队;您需要在流中保留一点延迟(以处理不一致的网络(，并仔细安排每个块。 (上面让我畏缩的一点是 source.start(( - 没有时间参数来保持块一个接一个地调度。 即：

var nextStartTime = 0;
function addChunkToQueue( buffer ) {
    if (!nextStartTime) {
        // we've not yet started the queue - just queue this up,
        // leaving a "latency gap" so we're not desperately trying
        // to keep up.  Note if the network is slow, this is going
        // to fail.  Latency gap here is 1 second.
        nextStartTime = audioContext.currentTime + 1; 
    }
    var bsn = audioContext.createBufferSource();
    bsn.buffer = buffer;
    bsn.connect( audioContext.destination );
    bsn.start( nextStartTime );
    // Ensure the next chunk will start at the right time
    nextStartTime += buffer.duration;
}

此外，根据您的块有多大，我想知道垃圾收集是否会导致问题。 您应该在探查器中查看它。

上端路径不能很好地工作;它依赖于JS事件处理，只有在音频系统播放完毕后才会触发;所以总会有差距。

最后 - 如果声音流与默认音频设备的采样率不匹配，这将不能很好地工作;总会有点击，因为decodeAudioData将重新采样到设备速率，这将没有完美的持续时间。 它会起作用，但可能会有像点击这样的工件在块的边界。 您需要一个尚未规范或实现的功能 - 可选择的音频上下文采样率 - 以解决此问题。