来自WebSocket的网络音频播放已经退出。

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接收到‘and’事件之后，按照接收到的顺序(通过AudioBufferSourceNode )播放它们。这与上述实现存在相同的辍学问题。

Answer 1

您的流确实保证在每个网络块中获得完整的音频文件？(decodeAudioData不适用于部分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将重采样到设备速率，而设备速率不会有一个完美的持续时间。它将工作，但很可能会有工件，如点击在块的边界。为了解决这个问题，您需要一个尚未规范或实现的特性--可选择的AudioContext示例费率。