在我的对象中，我得到了一个AudioBufferSourceNode对象（this.bSrc），连接到一个增益节点（this.audioDestination），该节点播放已存储的（有效）AudioBuffer对象（this.audioBuffer）。
如果this.audioDestination已连接到音频上下文最终目标this.mainContext.destination并且我在start(0)对象（AudioBufferSourceNode）上调用this.bSrc方法，则会好好玩。
如果this.audioDestination 尚未尚未连接到音频上下文最终目的地，则缓冲区将无法播放（并且没有问题），但其播放将延迟到建立连接（从而使AudioBufferSourceNode何时完成播放的任何假设无效。）
我目前正在实现一个插件架构，其中每个插件都有其audioDestination增益节点，并且不会（也不能）知道它是否间接连接到最终的音频上下文目标。对我来说合乎逻辑的是，AudioBufferSourceNode应该立即“播放”并完成，即使它没有连接到最终的音频上下文目的地。但它似乎不像这样工作。我是对的还是我弄错了？有没有办法改变这种行为？
代码：
/* Create the audio Context. */
this.mainContext = new webkitAudioContext;
/* Create an audio gain node */
this.audioDestination = this.mainContext.createGainNode();
/* [...] An AudioBuffer gets decoded and stored into this.audioBuffer*/
/* Create an AudioBufferSourceNode and try to play it immediately */
this.bSrc = this.audioContext.createBufferSource();
this.bSrc.connect (this.audioDestination);
this.bSrc.buffer = this.audioBuffer;
this.bSrc.start(0);
/* Create a callback for when the AudioBufferSourceNode finishes playing */
if (!this.bSrc.loop) {
var pbTimer = setTimeout(function() {
this.playFinishedCallback();
}.bind(this), this.audioBuffer.duration * 1000 / this.bSrc.playbackRate.value);
}
/* Connect this.audioDestination to the final AudioContext destination */
/* If this statement is executed after the previous ones, playback will start NOW */
this.audioDestination.connect(this.mainContext.destination);
答案 0 :(得分：2)
这是目前在Chrome中实现Web Audio API的方式，以及其中使用的设计。人们一直在谈论改变它;事实上，我是你描述的“音频线模型”的支持者。 :)但它不是唯一理智的模型。在当前的实现中没有任何方法可以改变这种行为。
但是，有一个简单的解决方法 - 只需将一个归零的增益节点连接到context.destination，并将所有的ABSN连接到它以及它们（最终）与context.destination的连接。
答案 1 :(得分：0)
这是有道理的。将context.destination视为stdout。没有连接到context.destination，音频无处可去。如果你在创建增益节点之后移动最后一行（连接到context.destination），我认为你不会有延迟。