Chrome 一直在默默地不断改进对 Web Audio API 的支持。在 Chrome 49（自 2016 年 2 月起为 Beta 版，预计将于 2016 年 3 月推出稳定版）中，我们更新了一些功能以跟踪规范，还添加了一个新节点。
decodeAudioData() 现在会返回一个 promise
AudioContext 上的 decodeAudioData() 方法现在会返回 Promise，从而支持基于 Promise 的异步模式处理。decodeAudioData() 方法始终将成功和错误回调函数作为参数：
context.decodeAudioData( arraybufferData, onSuccess, onError);
不过，现在您可以改用标准 Promise 方法来处理音频数据解码的异步性质：
context.decodeAudioData( arraybufferData ).then(
(buffer) => { /* store the buffer */ },
(reason) => { console.log("decode failed! " + reason) });
虽然在单个示例中，这看起来比较冗长，但 Promise 可让异步编程变得更简单、更一致。为了实现兼容性，系统仍支持“Success”和“Error”回调函数（如规范所述）。
OfflineAudioContext 现在支持 suspend() 和 resume()
乍一看，对 OfflineAudioContext 使用 suspend() 似乎很奇怪。毕竟，suspend() 之所以添加到 AudioContext 中，是为了让音频硬件进入待机模式，而当您渲染到缓冲区时，这似乎毫无意义（当然，OfflineAudioContext 就是用于此目的）。不过，此功能的重点是一次只能构建“得分”的一部分，以尽可能减少内存用量。您可以在渲染过程中暂停时创建更多节点。
例如，贝多芬的《月光奏鸣曲》包含大约 6,500 个音符。每个“音符”可能都会解构为至少几个音频图表节点（例如 AudioBuffer 和 Gain 节点）。如果您想使用 OfflineAudioContext 将整个七分半钟的内容渲染到缓冲区，可能不想一次创建所有这些节点。您可以改为按时间段创建这些报告：
var context = new OfflineAudioContext(2, length, sampleRate);
scheduleNextBlock();
context.startRendering().then( (buffer) => { /* store the buffer */ } );
function scheduleNextBlock() {
// create any notes for the next blockSize number of seconds here
// ...
// make sure to tell the context to suspend again after this block;
context.suspend(context.currentTime + blockSize).then( scheduleNextBlock );
context.resume();
}
这样，您就可以最大限度地减少在渲染开始时需要预创建的节点数量，并降低内存需求。
IIRFilterNode
该规范为想要创建自己精确指定的有限脉冲响应的音响爱好者添加了一个节点：IIRFilterNode。此过滤器可与 BiquadFilterNode 搭配使用，但允许完整指定滤波器响应参数（而不是使用 BiquadFilterNode 的易用 AudioParams 来指定类型、频率、Q 等）。IIRFilterNode 允许精确指定之前无法创建的滤波器，例如单阶滤波器；不过，使用 IIRFilterNode 需要对 IIR 滤波器的工作原理有深入的了解，而且它们也无法像 BiquadFilterNode 那样进行调度。
之前的更改
我还想提及之前进行的一些改进：在 Chrome 48 中，BiquadFilter 节点自动化功能开始以音频速率运行。为此，API 没有任何更改，但这意味着滤镜扫描的声音会更加流畅。此外，在 Chrome 48 中，我们通过返回要连接到的节点，向 AudioNode.connect() 方法添加了链接。这样可以更轻松地创建节点链，如以下示例所示：
sourceNode.connect(gainNode).connect(filterNode).connect(context.destination);
以上就是目前的所有内容，祝您一切顺利！