录制期间的流延迟

当音频记录流处于“运行”状态时，WaveRT 端口驱动程序的角色最小。 如下图所示，在录制过程中，音频设备捕获音频数据并将其写入循环缓冲区。 然后，音频引擎从缓冲区读取此数据。 此活动不需要端口驱动程序的干预。 换句话说，音频数据直接在音频硬件与用户模式应用程序之间流动，而不会受到任何内核模式软件组件的触摸。

在下图中，当流流经过缓冲区时，记录和读取位置会从左向右不断进行。 当记录或读取位置到达缓冲区的末尾时，它将环绕到缓冲区的开头。

上图将 录制位置 标识为音频设备当前正在录制的样本的缓冲区位置（通过模拟到数字转换器或 ADC 从麦克风捕获）。 请注意，记录位置是音频设备在通过 FIFO 后写入示例的未来缓冲区位置。 读取位置是音频引擎从中读取下一个示例的缓冲区位置。

音频设备在 ADC 中捕获音频样本的时间延迟，直到客户端读取它只是记录和读取位置之间的分离。 这种分离是以下延迟源的总和（在关系图中标记为 A 和 B）：

延迟 A：从 ADC 捕获数据后，音频设备将数据存储在硬件 FIFO 中，直到将数据写入循环缓冲区。

延迟 B：音频设备将数据写入循环缓冲区后，数据将驻留在缓冲区中，直到客户端读取数据。

客户端无法控制完全依赖于硬件的延迟 A。 典型的 FIFO 可能会存储来自 ADC 的大约 64 个样本。 但是，客户端确实控制了延迟 B。在音频设备写入缓冲区之前，使延迟 B 过大会导致系统出现不必要的延迟，但使得读取数据的风险太小。

尽管客户端可以设置计时器来定期激活其缓冲区读取线程，但此方法不会达到最小的延迟。 为了进一步降低延迟，客户端可以将音频设备配置为每次设备完成向缓冲区写入新的捕获数据块时生成硬件通知。 在这种情况下，客户端线程由硬件通知而不是计时器激活。

通过让音频设备定期通知音频引擎，客户端可以降低延迟，否则会更小。

客户端（通常是音频引擎）可以通过向 WaveRT 端口驱动程序发送 KSPROPERTY_RTAUDIO_HWLATENCY 请求来获取音频设备导致流延迟的延迟摘要。

客户端确定要在记录和读取位置之间保持的分离量后，客户端监视记录位置的更改，以确定读取位置应滞后多少。 在 Windows Server 2008 及更高版本的操作系统中，客户端发出KSPROPERTY_AUDIO_POSITION或KSPROPERTY_RTAUDIO_POSITIONREGISTER属性请求来确定记录位置。 后一个请求方法更高效，因为它允许客户端直接读取记录位置，而无需转换为信息的内核模式例程。