如何在 web 上构建音频应用程序

主讲人 Hongchan Choi 介绍了在网络上构建音频应用程序的一些想法和考虑，展示一些关于网络媒体制作的一些讨论。

首先抛出一个问题：如果你今天要创建一个网络音频应用程序，你需要考虑哪些事情

显然，您首先需要了解的是 Web 音频 API，但今天我不打算在这里讨论如何使用它。

它已经存在了十多年，我们有很多代码示例和教程。相反，我想讨论它的体系结构和性能特征。

音频 API 的体系结构和性能特征

首先，Web Audio API 是一个基于图形的音频编程环境。有几个音频节点可以相互连接以创建图形。

其次，图形渲染器由专用的高优先级线程运行，该线程通常是实时线程。

这种设计是不可避免的，因为 Web 音频 API 是 Web 平台的一部分。

直接在应用程序的主线程上处理音频流通常会导致糟糕的用户体验。这就是为什么 web 音频节点位于主线程上，而实际的音频处理（我称之为内部处理）发生在专用的独立线程上。

不管是好是坏，Web Audio API 对开发人员隐藏了低级音频实现。这意味着你不必从头开始写振荡器、滤波器或压缩器，它是由实现提供的。但这也意味着，当你想操控裸机时，事情可能会很快变得复杂，比如实现自己的过滤器来处理音频样本。

对于这种用例，Web Audio API 有 AudioWorklet。有了这个对象，您可以使用 JavaScript 和 WebAssembly 编写自己的音频处理模块。

另一个有趣的方面是：Web Audio API 是一个JavaScript API。正如你已经知道的，JavaScript 是一种垃圾收集语言，有一些有争议的怪癖，比如键入和作用域等等。在构建更大规模的真实产品时，会遇到与垃圾收集和性能相关的问题。

这是你无法控制的事情，而且在不同的浏览器中有所不同，但你必须注意。

从技术上讲，垃圾收集不应该影响 Web Audio API 的呈现程序，因为它运行在不同的线程上，但情况并非总是如此。尽管你的代码是完美的，没有创建任何垃圾，但你使用的库可能是浪费的，它可能会导致垃圾收集。一次创建太多对象最终会给音频渲染器带来压力，因为音频节点是垃圾收集的对象，尽管内部不是，但它们仍然关联在一起。

实例分析

我们可以检查和分析其性能，明白事情发生的时间和方式。

在Chrome中，你可以使用Web Audio perf toolkit，这是我今天的第一个分享。

首先是 Web Audio DevTools 面板。这是一个非常简单的工具，允许您监控音频系统的运行状况及其渲染能力。

如果您遇到音频故障，很可能是两种情况之一。

A：回调时间是不规则的，当渲染器在低优先级线程上运行时可能会发生这种情况

B: 音频处理负载超出了 CPU 容量。发生这种情况的原因有很多，但最终，你做得太多了，回调超时了。

DevTools 面板提供了这两个方面的指标。

其次，我们有音频图形可视化工具扩展。这是我们工具包中最近添加的内容。这不是 Chrome 附带的，所以你必须从 Chrome 网络商店安装，这只是一个一次性过程。

此工具至少在两种情况下有用。首先，一个更大规模的 web 音频应用程序通常会构造和销毁很多音频节点。通过阅读源代码，很难发现它们之间的错误连接。

可视化技术在精确定位错误方面有很大的优势。

其次，它允许您了解图形的冗余程度。您可能无缘无故创建了太多增益节点。使用多个增益节点包装子图是非常常见的技术。

此外，可能会创建一个孤立节点，但它没有连接到任何东西，这也非常常见。

最后，你可以使用Chrome的追踪工具。与之前的选项相比，这有点复杂，但它的功能很全面。

这个工具之所以重要还有两个原因。首先，这准确地显示了事情发生的时间和方式。你将能够看到音频流何时出现故障，比如缓冲区不足，并对原因做出猜测。

其次，当你与 Chromium 工程师交流时，这是非常有用的。我们很可能没有与您完全相同的设置，因此可能无法复制该问题。因此，在修复 bug 时，与我们交换跟踪文件确实有助于沟通。

用户隐私

当你在构建客户端应用程序时，比如乐器、录音机、编辑器或DAW，很快你就会意识到，缺乏对音频设备的访问是 web 和本机平台之间的一个巨大差距。

这意味着与设备相关的设置，例如通道数、采样率和缓冲区大小，不适合您的应用程序。

浏览器实现者，实际上已经意识到这对开发人员来说是一个巨大的痛点，但这并非没有原因。

广告商或攻击者可以利用此设备相关信息推断用户身份。这种技术被称为指纹识别，这是我们不能在网上拥有隐私的原因之一。

当然，对于这种类型的利用，有一些对策，例如基于约束的API模式。应用程序可以进行查询，平台将根据当前客户端的能力接受或拒绝查询。

保护用户隐私被认为是一件麻烦事，这肯定是 web 平台的一个限制因素，但我相信所谓的 API 设计隐私正在逐渐成为一种规范，即使在本机平台上也是如此。

如今，在 MacOS 或 Windows 等其他操作系统中，你会发现类似的保护机制，比如系统范围的麦克风访问权限 UI。

设备延迟

现在我们来谈谈延迟。至少在网络音频方面，Chrome 做得不好是一个棘手的问题。

对于音频制作应用程序，延迟非常重要，至少有两个原因。首先，在录制或监控时，尽可能减少延迟非常重要，但平台准确的延迟报告对于事后补偿音频至关重要。

但对于浏览器来说，这是一个棘手的问题。浏览器需要在许多不同的平台上支持各种配置。这意味着我们正在进行精简，可能缺少一些明显的特定于平台的优化。

当经验丰富的音频开发人员加入 Chrome 的音频基础设施，指出一些问题时，我们总是对此心存感激，而这在过去确实发生过好几次。

此外，网络音频并不是平台上唯一的音频API。WebRTC和媒体元素在Chrome中也与Web audio共享相同的音频基础设施。这使得它很难带来一个只对网络音频有利的大变化。

RTC media通常关注弹性，这意味着更多的缓冲，但 Web Audio 更关注低延迟和交互性，这意味着更少的缓冲。这种冲突使得应用只对网络音频有利的激进优化变得困难。

目前的状况是怎样的？

对于网络音频，您必须使用 getUserMedia 进行麦克风输入，输出只需进入系统默认的音频设备。

但是如果你想使用默认设备以外的音频设备呢？唯一已知的解决方案是使用音频元素。通过将网络音频输出流式传输到所选设备的音频元素。

在这里，流通常意味着在下面的某个地方有一些缓冲。这对延迟不好。

我们能做些什么？音频工作组目前正在努力创建一个新的API，允许您为音频上下文选择音频输出设备。理论上，这将保证代码路径最小化输出延迟。此外，人们还梦想为输入设备选择创建一个新的API。

来源：W3C
主讲人：Hongchan Choi
内容整理：尹文沛
链接：https://mp.weixin.qq.com/s/TKgZVdU8XG1XrjpPAiyn4g