本文讨论Windows 10中的音频延迟更改。 它涵盖了面向应用程序开发人员的 API 选项以及驱动程序中的更改，这些更改可以支持低延迟音频。 音频延迟是创建声音的时间和听到声音的时间之间的延迟。 对于几个关键方案，低音频延迟非常重要，例如：

本文档的目标是：

本文介绍：

下图显示了 Windows 音频堆栈的简化版本。

下面是呈现路径中延迟的摘要：音频处理对象

应用程序将数据写入缓冲区

音频引擎从缓冲区读取数据并对其进行处理。 它还以音频处理对象的形式加载音频效果， (ADO) 。 有关 ADO 的详细信息，请参阅 Windows 音频处理对象。

APOs 的延迟因 ADO 中的信号处理而异。

在Windows 10之前，对于使用浮点数据的应用程序，音频引擎的延迟等于约 12 毫秒，对于使用整数数据的应用程序，音频引擎的延迟等于约 6 毫秒

在 Windows 10 及更高版本中，所有应用程序的延迟已降低到 1.3 毫秒

音频引擎将处理的数据写入缓冲区。

在Windows 10之前，缓冲区始终设置为约 10 毫秒。

从Windows 10开始，缓冲区大小由音频驱动程序定义， (有关缓冲区的更多详细信息将在本文) 后面部分介绍。

音频驱动程序从缓冲区读取数据并将其写入硬件。

硬件还可以以更多音频效果的形式再次处理数据。

用户从扬声器听到音频。

下面是捕获路径中延迟的摘要：

音频是从麦克风捕获的。

硬件可以处理数据。 例如，添加音频效果。

驱动程序从硬件读取数据，并将数据写入缓冲区。

在Windows 10之前，此缓冲区始终设置为 10 毫秒。

从Windows 10开始，缓冲区大小由音频驱动程序定义， (下面) 的更多详细信息。

音频引擎从缓冲区读取数据并对其进行处理。 它还以音频处理对象的形式加载音频效果， (ADO) 。

APOs 的延迟因 ADO 中的信号处理而异。

在Windows 10之前，对于使用浮点数据的应用程序，音频引擎的延迟等于约 6 毫秒，对于使用整数数据的应用程序，则等于大约 0 毫秒。

在 Windows 10 及更高版本中，所有应用程序的延迟已降低到 ~0 毫秒。

一旦音频引擎完成数据处理，应用程序就会发出信号，表明数据可供读取。 音频堆栈还提供独占模式选项。 在这种情况下，数据会绕过音频引擎，直接从应用程序转到驱动程序从中读取数据的缓冲区。 但是，如果应用程序以独占模式打开终结点，则没有其他应用程序可以使用该终结点来呈现或捕获音频。

对于需要低延迟的应用程序，另一种常用的替代方法是使用 ASIO (音频流输入/输出) 模型，该模型使用独占模式。 用户安装第三方 ASIO 驱动程序后，应用程序可以直接将数据从应用程序发送到 ASIO 驱动程序。 但是，应用程序必须以与 ASIO 驱动程序直接通信的方式编写。

(独占模式和 ASIO) 的两种替代方法都有自己的限制。 它们提供较低的延迟，但它们在上述) (有其自身的限制。 因此，已修改音频引擎，以降低延迟，同时保持灵活性。

Windows 10 及更高版本在三个方面进行了增强，以减少延迟：

以下两个Windows 10 API 提供低延迟功能：

若要确定要使用这两个 API 中的哪一个：：

本文的 度量工具 部分显示使用内置 HDAudio 驱动程序从 Haswell 系统进行的特定度量。

以下部分将介绍每个 API 中的低延迟功能。 如上一部分所述，为了使系统实现最小延迟，它需要更新支持较小缓冲区大小的驱动程序。

AudioGraph 是 Windows 10 及更高版本中的新通用 Windows 平台 API，旨在轻松实现交互式和音乐创作方案。 AudioGraph 提供多种编程语言 (C++、C#、JavaScript) ，并且具有简单且功能丰富的编程模型。

为了面向低延迟方案，AudioGraph 提供了 AudioGraphSettings：：QuantumSizeSelectionMode 属性。 此属性可以是下表中显示的任何值：

AudioCreation 示例演示如何使用 AudioGraph 实现低延迟。 以下代码片段演示如何设置最小缓冲区大小：

从Windows 10开始，WASAPI 已增强为：

上述功能将在所有 Windows 设备上可用。 但是，某些具有足够资源和更新驱动程序的设备将比其他设备提供更好的用户体验。

上述功能由一个名为 IAudioClient3 的新接口提供，该接口派生自 IAudioClient2。

IAudioClient3 定义以下 3 种方法：

WASAPIAudio 示例演示如何使用 IAudioClient3 实现低延迟。

以下代码片段演示了音乐创建应用如何在系统支持的最低延迟设置中运行。

此外，Microsoft 建议使用 WASAPI 的应用程序也使用 实时工作队列 API 或 MFCreateMFByteStreamOnStreamEx 来创建工作项并将其标记为音频或 Pro Audio，而不是他们自己的线程。 这将允许 Windows 以避免干扰非音频子系统的方式管理它们。 相比之下，Windows 会自动正确管理所有 AudioGraph 线程。 WASAPIAudio 示例中的以下代码片段演示如何使用 MF 工作队列 API。

或者，以下代码片段演示如何使用 RT 工作队列 API。

最后，使用 WASAPI 的应用程序开发人员需要根据每个流的功能，使用音频类别标记其流，以及是否使用原始信号处理模式。 Microsoft 建议所有音频流不要使用原始信号处理模式，除非了解其含义。 原始模式绕过 OEM 选择的所有信号处理，因此：

为了使音频驱动程序支持低延迟，Windows 10 及更高版本提供以下功能：

以下三个部分将更深入地介绍每个新功能。

在 Windows、驱动程序和硬件之间移动音频数据时，驱动程序在各种约束下运行。 这些限制可能是由于在内存和硬件之间移动数据的物理硬件传输，或者由于硬件或关联的DSP中的信号处理模块。

从 Windows 10 版本 1607 开始，驱动程序可以使用 DEVPKEY_KsAudio_PacketSize_Constraints2 设备属性来表达其缓冲区大小功能。 此属性允许用户定义驱动程序支持的绝对最小缓冲区大小，以及每个信号处理模式的特定缓冲区大小约束。 特定于模式的约束需要高于驱动程序的最小缓冲区大小，否则音频堆栈会忽略它们。

例如，以下代码片段演示了驱动程序如何声明支持的绝对最小缓冲区大小为 2 毫秒，但默认模式支持 128 帧，如果我们假定为 48 kHz 采样率，则这相当于 3 毫秒。

有关这些结构的更深入信息，请参阅以下文章：

此外， sysvad 示例 演示如何使用这些属性，以便驱动程序声明每个模式的最小缓冲区。

本部分中介绍的 DDI 允许驱动程序：

在使用 DSP 的情况下，此 DDI 非常有用。 但是，标准 HD 音频驱动程序或其他简单的圆形 DMA 缓冲区设计在此处列出的这些新 DDI 中可能没有太大优势。

一些驱动程序例程返回 Windows 性能计数器时间戳，反映设备捕获或显示示例的时间。

在具有复杂 DSP 管道和信号处理的设备中，计算准确的时间戳可能具有挑战性，应深思熟虑地完成。 时间戳不应反映将样本传输到 Windows 或从 Windows 传输到 DSP 的时间。

若要计算性能计数器值，驱动程序和 DSP 可能使用以下一些方法。

sysvad 示例演示如何使用上述 DDI。

为了帮助确保无故障操作，音频驱动程序必须向 Portcls 注册其流式处理资源。 这允许 Windows 管理资源，以避免音频流式处理和其他子系统之间的干扰。

流资源是音频驱动程序用于处理音频流或确保音频数据流的任何资源。 仅支持两种类型的流资源：中断和驱动程序拥有的线程。 音频驱动程序应在创建资源后注册资源，并在删除资源之前注销该资源。

音频驱动程序可以在加载驱动程序时初始化时注册资源，或者在运行时注册资源，例如，在进行 I/O 资源重新均衡时。 Portcls 使用全局状态来跟踪所有音频流式处理资源。

在某些用例（例如需要非常低延迟音频的用例）中，Windows 会尝试隔离音频驱动程序的注册资源免受其他 OS、应用程序和硬件活动的干扰。 OS 和音频子系统根据需要执行此操作，而无需与音频驱动程序交互，音频驱动程序注册资源除外。

此注册流资源的要求意味着流式处理管道路径中的所有驱动程序都必须直接或间接使用 Portcls 注册其资源。 音频微型端口驱动程序具有以下选项：

注意：

最后，为了注册资源而链接 PortCl 的驱动程序必须在其 inf 的 DDInstall 节中添加以下两行。 音频微型端口驱动程序不需要此功能，因为它们已在 wdmaudio.inf 中包含/需要。

上述行确保已安装 PortCl 及其依赖文件。

为了测量往返延迟，用户可以利用通过扬声器播放脉冲的工具，并通过麦克风捕获它们。 它们测量以下路径的延迟：

WASAPI 和 AudioGraph 之间的延迟差异是由于以下原因造成的：

如果所有应用程序都使用新 API 实现低延迟，这难道不是更好吗？ 低延迟并不总是保证更好的用户体验吗？

不一定。 低延迟有其利弊：

总之，每种应用程序类型对音频延迟有不同的需求。 如果应用程序不需要低延迟，则不应使用新 API 实现低延迟。

更新到 Windows 10 以后的所有系统是否都会自动更新以支持小型缓冲区？ 所有系统是否都支持相同的最小缓冲区大小？

否，为了使系统支持小型缓冲区，它需要更新驱动程序。 由 OEM 决定将更新哪些系统以支持小型缓冲区。 此外，较新的系统更有可能支持比旧系统更小的缓冲区。 新系统中的延迟很可能低于旧系统。

如果驱动程序支持较小的缓冲区大小，Windows 10 及更高版本中的所有应用程序是否会自动使用小型缓冲区来呈现和捕获音频？

否，默认情况下，Windows 10 及更高版本中的所有应用程序都将使用 10 毫秒的缓冲区来呈现和捕获音频。 如果应用程序需要使用小型缓冲区，则需要使用新的 AudioGraph 设置或 WASAPI IAudioClient3 接口才能执行此操作。 但是，如果某个应用程序请求使用小型缓冲区，则音频引擎将开始使用该特定缓冲区大小传输音频。 在这种情况下，使用相同终结点和模式的所有应用程序将自动切换到该较小的缓冲区大小。 当低延迟应用程序退出时，音频引擎将再次切换到 10 毫秒的缓冲区。