了解如何使用 about://tracing 和 Audion（Chrome DevTools 中的 WebAudio 扩展程序）分析 Chrome 中 Web Audio 应用的性能。
您可能因为正在开发使用 Web Audio API 的应用，并且遇到了意外故障（例如输出中出现爆音），或者您听到了意想不到的声音而访问了这篇文章。您可能已经参与了 crbug.com 讨论，并且 Chrome 工程师要求您上传“跟踪数据”或查看图表可视化。本文介绍了如何获取相关信息，以便我们了解问题并最终解决根本问题。
Web Audio 分析工具
在分析 Web Audio 时，有两个工具可以为您提供帮助：about://tracing 和 Chrome DevTools 中的 WebAudio 扩展程序。
何时使用 about://tracing？
当发生神秘的“故障”时。使用跟踪工具分析应用可让您深入了解：
- 不同线程上特定函数调用花费的时间片
- 时间轴视图中的音频回调时序
它通常会显示错过的音频回调截止时间或可能导致意外音频故障的大型垃圾回收。此信息有助于了解根本问题，因此 Chromium 工程师通常会要求提供此信息，尤其是在本地重现不可行的情况下。有关跟踪的一般说明，请访问此处。
何时使用 Web Audio DevTools 扩展程序？
当您想要可视化音频图并实时监控音频渲染器的性能时。音频图是 AudioNode 对象的网络，用于生成和合成音频流，通常变得很复杂，但图拓扑在设计上是不透明的。（Web Audio API 没有用于节点/图自检的功能。）您的图表中发生了一些更改，现在您听不到声音。那么现在是时候通过聆听进行调试了。这绝非易事，当您有更大的音频图时，它会变得更加困难。Web Audio DevTools 扩展程序可以通过可视化图表来帮助您。
借助此扩展程序，您可以监控渲染容量的运行估计值，该值指示 Web Audio 渲染器在给定的渲染预算（例如，大约 2.67 毫秒 @ 48KHz）内的性能。如果容量接近 100%，则意味着您的应用很可能会产生故障，因为渲染器无法在给定的预算内完成工作。
使用 about://tracing
如何捕获跟踪数据
下面编写的说明适用于 Chrome 80 及更高版本。
为了获得最佳效果，请关闭所有其他标签页和窗口，并禁用扩展程序。或者，您可以启动 Chrome 的新实例，或使用来自不同发布渠道（例如 Beta 或 Canary）的其他版本。准备好浏览器后，请按照以下步骤操作
- 在标签页中打开您的应用（网页）。
- 打开另一个标签页，然后转到
about://tracing。 - 按记录按钮，然后选择手动选择设置。
- 在记录类别和默认禁用类别部分中，按无按钮。
- 在记录类别部分中，选择以下各项
audioblink_gcmediav8.execute（如果您对AudioWorkletJS 代码性能感兴趣）webaudio
- 在默认禁用类别部分中，选择以下各项
audio-worklet（如果您对AudioWorklet线程的启动位置感兴趣）webaudio.audionode（如果您需要每个AudioNode的详细跟踪）
- 按底部的记录按钮。
- 返回到您的应用标签页，然后重做触发问题的步骤。
- 当您有足够的跟踪数据时，返回到跟踪标签页并按停止。
跟踪标签页将可视化结果。
按保存以保存跟踪数据。
如何分析跟踪数据
跟踪数据可视化了 Chrome 的 Web Audio 引擎如何渲染音频。渲染器有两种不同的渲染模式：操作系统模式和 Worklet 模式。每种模式都使用不同的线程模型，因此跟踪结果也不同。
操作系统模式
在操作系统模式下，AudioOutputDevice 线程运行所有 Web Audio 代码。AudioOutputDevice 是来自浏览器的音频服务的实时优先级线程，由音频硬件时钟驱动。如果您在此通道的跟踪数据中看到不规则性，则意味着来自设备的回调时序可能不稳定。已知 Linux 和 Pulse Audio 的组合存在此问题。有关更多详细信息，请参阅以下 Chromium 问题：#825823、#864463。
Worklet 模式
在 Worklet 模式下，其特点是从 AudioOutputDevice 到 AudioWorklet 线程 的一个线程跳转，您应该在两个线程通道中看到对齐良好的跟踪，如下所示。当 worklet 激活时，所有 Web Audio 操作都由 AudioWorklet 线程渲染。此线程当前不是实时优先级线程。此处常见的异常是由垃圾回收或错过的渲染截止时间引起的大块。这两种情况都会导致音频流出现故障。
在这两种情况下，理想的跟踪数据的特点是音频设备回调调用对齐良好，并且渲染任务在给定的渲染预算内完成良好。上面的两个屏幕截图是理想跟踪数据的绝佳示例。
从真实世界的示例中学习
示例 1：渲染任务超出渲染预算
下面的屏幕截图（Chromium 问题 #796330）是 AudioWorkletProcessor 中的代码花费时间过长并超出给定渲染预算的典型示例。回调时序良好，但 Web Audio API 的音频处理函数调用未能在下一个设备回调之前完成工作。
您的选项
- 通过使用更少的
AudioNode实例来减少音频图的工作负载。 - 减少
AudioWorkletProcessor中代码的工作负载。 - 增加
AudioContext的基本延迟。
示例 2：worklet 线程上的大量垃圾回收
与操作系统音频渲染线程不同，垃圾回收在 worklet 线程上进行管理。这意味着如果您的代码执行内存分配/释放（例如，新数组），它最终会触发垃圾回收，从而同步阻止线程。如果 Web Audio 操作和垃圾回收的工作负载大于给定的渲染预算，则会导致音频流出现故障。以下屏幕截图是这种情况的极端示例。
您的选项
- 预先分配内存并在可能的情况下重复使用它。
- 使用基于
SharedArrayBuffer的不同设计模式。虽然这不是一个完美的解决方案，但一些 Web Audio 应用使用与SharedArrayBuffer类似的模式来运行密集型音频代码。示例
示例 3：来自 AudioOutputDevice 的抖动音频设备回调
音频回调的精确时序对于 Web Audio 至关重要。这应该是您系统中最精确的时钟。如果操作系统或其音频子系统无法保证可靠的回调时序，则所有后续操作都将受到影响。下图是抖动音频回调的示例。与前两张图像相比，每个回调之间的间隔差异很大。
您的选项
- 通过调整
latencyHint选项来增加系统音频回调缓冲区大小。 - 如果您发现问题，请在 crbug.com 上提交问题，并附上跟踪数据。
使用 Web Audio DevTools 扩展程序
您还可以使用专门为 Web Audio API 设计的 DevTools 扩展程序。与跟踪工具不同，这提供了对图表和性能指标的实时检查。
此扩展程序需要从 Chrome 网上应用店安装。
安装后，您可以通过打开 Chrome DevTools 并单击顶部菜单上的“Web Audio”来访问面板。
Web Audio 面板有四个组件：上下文选择器、属性检查器、图表可视化工具和性能监视器。
上下文选择器
由于页面可以有多个 BaseAudioContext 对象，因此此下拉菜单允许您选择要检查的上下文。您还可以通过单击左侧的垃圾桶图标手动触发垃圾回收。
属性检查器
侧面板显示用户选择的上下文或 AudioNode 的各种属性。不支持检查 AudioParam 中的动态值。
图表可视化工具
此视图呈现用户选择的上下文的当前图表拓扑。此可视化效果会实时动态变化。通过单击可视化效果中的元素，您可以在属性检查器上检查详细信息。
性能监视器
底部的状态栏仅在选定的 BaseAudioContext 是 AudioContext（实时运行）时才处于活动状态。此栏显示选定的 AudioContext 的瞬时音频流质量，并且每秒更新一次。它提供以下信息
回调间隔 (ms)：显示回调间隔的加权平均值/方差。理想情况下，平均值应稳定，方差应接近于零。如果您看到很大的方差，则意味着系统级音频回调函数具有不稳定的时序，这可能会导致音频流质量不佳。（请参阅上面的示例 3。）
渲染容量（百分比）：当容量接近 100% 时，这意味着渲染器在给定的渲染预算内做了太多工作，因此您应该考虑减少工作量（例如，在图表中使用更少的
AudioNodes对象）。
您可以通过单击垃圾桶图标手动触发垃圾回收器。
旧版 WebAudio DevTools 面板
该扩展程序现在是 Chrome Web Audio 团队推荐的方法，但旧版 WebAudio DevTools 面板也可用。您可以通过单击 DevTools 右上角的“三个点”菜单，然后转到更多工具，再转到 WebAudio 来访问此面板。
结论
调试音频很困难。调试浏览器中的音频更加困难。但是，这些工具可以通过为您提供有关 Web Audio 代码性能的有用见解来减轻痛苦。但是，在某些情况下，您可能会在 Chrome 或扩展程序中发现问题。那么请不要害怕在 crbug.com 上提交错误或在扩展程序问题跟踪器上提交错误。
Jonathan Velasquez 在 Unsplash 上拍摄的照片