Web Audio 设计思想.pdfVIP

Chromium Web Audio 设计思想 作者：刘旭晖 Raymond 转载请注明出处 Email：colorant at 163.com BLOG：/colorant/ 本文是我在W3C Web Audio 的相关的工作中对其设计思想的一点理解，对WebAudio 是什么， 以及如何使用不打算做过多的介绍，因此这里假定你使用过W3C Web Audio，或者对其框架有 一定的了解 ；） 需求分析 W3C Web Audio （/TR/webaudio/）的设计出发点，是满足基于HTML5 的复 杂交互类程序，游戏或音频应用程序对音频处理能力的需求。通常这些应用会有如下的需求：  大量动态并发音源  精确的时间控制  动态音频处理 （支持混音，动态音频生成，以及各种音频特效处理，波形变换等）  低延迟  多声道支持  使用灵活，易于扩展 针对这些需求，Web Audio 的整体框架以及其具体实现（以Chromium 中的实现为例）都做了 相应的考量。 灵活性和扩展性 构建在结点（AudioNode ）上的流水线框架 下图引用自Web Audio Spec 可以看到，整个音频处理的过程是由各类音频处理节点构建组成的。这里需要说明的是：我所 指的流水线框架，更多的指的是数据从Source节点向Destination 节点的串行流动处理过程。 和传统的流水线概念不同的是，任何时候，只有一帧的音频数据在流水线中串行传递处理，并 没有多帧的数据同时在流水线的不同节点上被处理。 从API 开发者的角度：这种架构将各种音频处理算法模块化，易于拓展API 能力。 从应用开发者的角度：可以按照自己的需求，创建和连接各类音频处理结点，构建满足应用需 求的音频处理流程。 用户定制音频处理算法的能力 通过使用JavaScriptAudioNode （/TR/webaudio/#JavaScriptAudioNode） 可以将音频数据流从流水线的任意位置暴露给用户，从而使用户可以定制化音频处理算法。 动态音源的支持 要支持大量的动态并发音源 （如游戏中的各种音效），有几个问题需要解决 AudioNode 的生命周期管理 首先为了支持音频的Fire and Forget 的使用模式，要保证一个音源片断创建完毕并开始播放 以后，在JS 空间中无需保留对应结点对象，音频流水线还能正常工作。其次当音源播放完毕 后要能够及时销毁相关对象，减少内存占用。这就要求对AudioNode 乃至整个AudioContext 的生命周期都需要进行合理有效的管理。 Chromium 中Web Audio 的实现对音频结点按照多种方式进行了引用计数：除了正常的对象引 用计数，还按照音频结点上下游连接关系建立了Connection连接引用计数，此外对音源结点 （AudioSourceNode）使用了特殊连接引用计数方式（由AudioContext 对AudioSourceNode 默认增加连接引用计数，在音源播放完毕后移除对应的连接引用计数）从而保证Fire and Forget 模式的正常工作。 动态声道切换支持 在一个复杂的应用程序中，音频数据的来源和格式可能不同，举例来说，一个游戏中的背景音 乐可能是立体声，而环境音效等动态音源则可能是单声道的，在别的程序中则可能反过来，又 或者需要动态添加5.1 环绕立体声的效果。 在Web Audio 的实现中，有大量的代码是围绕着支持动态调整音频数据流的声道数来设计的， 比如输入输出结点的声道数自适应匹配，不同声道数音频数据流的Up/Down Mixing 混音等。 当然，由于很多的音频处理算法和音频数据流的声道数是相关联的，某些类型的AudioNode 在目前的WebAudio 实现中还不能做到对所有声道数的自适应匹配。 此外某些音频处理结点（比如 DynamicsCompressorNode）的算法依赖于历史数据，频繁的切 换声道数可能造成算法效果变差，所以这些结点对声道数的自适应还有一些特殊的处理。 音频处理的实时性和低延迟 影响音频处理实时性的因数很多，要保证低延迟，不间断的输出音频数据，就需要从各个方面 加以综合考虑，比如：在音频输出端，缓存足够长度的待输出音频数据，减小CPU 负荷波动造 成前端数据无法及时处理带来的影响；使用共享内存，减少数据拷贝等。在Chromium 的实现 中，We