CPU 使用率不高，声音为什么还会断？── 从缓冲区和截止时间说起

听音乐时，声音偶尔会“噗”地断一下。任务管理器里的 CPU 使用率只有 10% 左右，唯独声音不稳定。遇到这种情况，CPU 明明还有余力，为什么声音还会中断？

即使 CPU 使用率很低，只要下一批音频数据没能在截止时间前补充上，声音就可能中断。这是因为必须在缓冲区里剩余的声音播放期间，把下一批数据交过去。等待数据或锁、所需逻辑 CPU 上的 DPC/ISR 等原因造成的补充延迟，即使没有把整个 CPU 用满也会发生。Exclusive-Mode Streams、CPU Analysis

不过，仅凭听到的“噗”一声，还不能断定是欠载（underrun）。音源、应用、音频效果、输出设备等也会引起类似的症状。首先用同一个音源，每次只改变一个条件、再恢复原状进行比较；如果这样仍无法缩小范围，再记录断音前后的情况。Fix distorted or crackling audio in Windows

本文讨论这个疑问，以及随之而来的“是不是把缓冲区调大就行”“比较什么、记录什么才能缩小原因范围”。本文不会仅凭 CPU 使用率或听到的声音，就确定个别故障的原因。

讨论对象主要是 Windows 11 上的音频输出。比较对象包括内置、有线、USB、蓝牙等输出；对于音乐制作软件（DAW），也涉及应用或驱动程序提供缓冲区设置时的比较。本文没有全面涵盖整个录音系统的设计，也没有涵盖针对各个设备的无线通信诊断。

说明以共享模式为基本示例。实际的路径、缓冲区大小和处理周期因应用、API、驱动程序和设备而异，也不存在所有应用通用的缓冲区设置界面。Low Latency Audio

文中给出的 CPU 使用率、10 毫秒的剩余量、补充时刻等，都是用于说明的假设。这不是在特定电脑上实测复现或改善效果的报告。后半部分的操作，是供读者在自己的环境中进行的确认步骤。

原理部分可以从下一节“音频播放缓冲区”开始依次阅读。调查断音的操作在“比较复现条件”和“用 WPR 记录断音”两节中。

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 5 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

音频播放缓冲区

仅仅保存好音乐文件，扬声器是不会发声的。应用要准备好音频数据，再经由 Windows 和驱动程序送到输出设备。音频播放缓冲区是临时存放接下来要播放的数据的区域。在设备播放当前数据的同时，供应方准备好下一批数据并补充进去。Rendering a Stream

flowchart TB
    accTitle: 先存一点后面的声音再播放
    accDescr: 把准备好的音频数据补充到缓冲区，并在设备端继续播放的同时准备下一批数据的流程。
    A["准备下一段声音"] --> B["补充到缓冲区"]
    B --> C["播放已存的声音"]
    C -.->|"用完之前"| A

图1：要持续播放，补充必须跟得上声音的消耗。

图1 是只表示补充与消耗之间关系的概念图。它并没有把实际音频路径上的多个缓冲区看作物理上的同一个区域。Low Latency Audio

缓冲区的作用是吸收准备声音的一方与使用声音的一方之间短暂的时间差，使播放连续不断。不过，缓冲区的容量和其中当前尚未播放的数据量是两回事。“有 10 毫秒的容量”并不意味着始终剩有 10 毫秒的数据。Rendering a Stream

本文把“必须在正在播放的数据用完之前送达所需的下一批数据”这一时间上的约束，称为补充截止时间。音频处理需要做到“在发声的时刻之前准备好”。仅仅“最后总算计算出来了”是不够的。供应来不及、可播放的数据耗尽的状态就是欠载，会导致断音或咔哒声。即使数据迟些送到，也无法事后填补已经听到的中断。Exclusive-Mode Streams

音频数据的路径

在通常的共享模式下，Windows 的音频引擎接收播放应用准备好的数据，将多路声音混合或施加效果之后，再交给驱动程序和输出设备。播放应用既负责读取音源，也负责向输出端供应数据；驱动程序和输出设备则把数据送到设备端并播放出来。Low Latency Audio

flowchart TB
    accTitle: 共享模式下音频数据经过的路径
    accDescr: 音频引擎对播放应用准备的数据进行混音和效果处理后交给驱动程序，再由输出设备播放。
    A["播放应用：准备数据"] --> E["音频引擎：混音与效果"]
    E --> D["驱动程序：送往设备"]
    D --> O["输出设备：播放"]

图2：这是共享模式的示例。中间的处理和缓冲区因 API 和设备而异。

设备端有时也有自己的处理和缓冲区，整体延迟并不只由应用端的缓冲区决定。这里的说明以共享模式的路径为前提，并不表示所有 API 都经过相同的处理。Low Latency Audio

剩余 10 毫秒时的补充

假设缓冲区里现在还剩 10 毫秒的未播放数据。如果下一次补充在 8 毫秒后，就能在数据还没用完时接上；但如果要到 12 毫秒后才能补充，那么在这个简化的例子中，数据会在第 10 毫秒时耗尽。

flowchart TB
    accTitle: 同样剩 10 毫秒，补充时刻不同结果也不同
    accDescr: 以说明用的假设为例：对于剩余 10 毫秒的播放数据，8 毫秒后补充可以赶上，12 毫秒后补充则已经用完。
    A["剩余 10 毫秒"] --> B{"下一次补充"}
    B -->|"8 毫秒后"| C["接得上"]
    B -->|"12 毫秒后"| D["第 10 毫秒耗尽"]

图3：这是把时间简化后的例子。重要的不只是有没有补充上，还有是什么时候补充上的。

CPU 使用率与补充延迟

CPU 使用率反映的是一段时间内的繁忙程度。它和音频处理能否在需要的瞬间执行，看的不是同一件事。即使 1 秒中的大部分时间 CPU 都有余力，只要有一次出现 12 毫秒无法补充的区间，这一次延迟就可能造成中断。之后剩下的处理能力余量，无法挽回已经过去的播放时刻。CPU Analysis

flowchart TB
    accTitle: 平均的余力与一次补充延迟
    accDescr: 即使 1 秒中的大部分时间 CPU 都有余力，只要有一次出现 12 毫秒无法补充的区间，这一次延迟就可能使声音中断。
    A["1 秒内大半时间 CPU 有余力"] --> B["仅一次 12 毫秒无法补充"]
    B --> C["这一次就使声音中断"]

图4：即使平均有余力，已经过去的播放时刻也无法挽回。

挤占截止时间余量的不只是计算时间。开始处理之前的等待，以及所需数据送达之前的等待，也都包括在内。因此，调查时要问的也不只是“CPU 是百分之几”，而要换成“声音中断的那一刻，下一段声音在等待什么”。

等待数据和锁

假设准备音频数据的处理正在等待文件读取完成。等待应用内其他处理持有的锁时也是一样。正在等待的处理本身几乎不占用 CPU，但设备端仍在继续播放，剩余的声音不断减少。Results for the Streaming Media Performance Assessment、CPU Analysis

flowchart TB
    accTitle: 不占用 CPU 的等待期间，播放也在继续
    accDescr: 音频处理等待数据或锁时，该处理不使用 CPU，但播放仍在推进、剩余量不断减少，补充一旦延迟，缓冲区就可能耗尽。
    A["音频处理等待数据"] --> B["该处理不占用 CPU"]
    B --> C["其间播放仍在继续"]
    C --> D["补充一迟就会耗尽"]

图5：没有占用 CPU，不等于需要做的工作已经完成。

DPC/ISR 与音频线程

ISR 是响应设备中断的处理。DPC 是为了缩短中断处理，把剩余工作推迟执行的机制。普通的 DPC 会先于同一逻辑 CPU 上的普通线程执行；在普通 DPC 或 ISR 运行期间，该逻辑 CPU 无法执行普通线程。Introduction to DPCs、CPU Analysis

即使 CPU 整体有余力，如果这些处理在音频处理所需的 CPU 上持续过久或频繁发生，供应就可能延迟。微软关于音频和视频性能分析的资料中，也把网络、存储、图形等驱动程序造成的较长 DPC/ISR 列为断音的可能原因。只检查发声的设备未必就够了。Results for the Streaming Media Performance Assessment

flowchart TB
    accTitle: 响应设备的处理拖慢音频执行的情况
    accDescr: 如果音频处理所需的 CPU 上普通 DPC 或 ISR 持续过久，线程的执行就会延迟，并可能影响补充截止时间。
    A["同一 CPU 上的 DPC/ISR"] -->|"持续过久时"| B["音频执行被迫等待"]
    B --> C["下一段声音补充延迟"]
    C --> D["剩余耗尽就会断音"]

图6：发声设备以外的处理，有时也会间接影响音频的补充。

无法划出“DPC 只要低于多少微秒，任何电脑都不会断音”这样的通用界线。性能评估资料中的警告值是在该评估条件下得出的数值，本文不会脱离实际的补充截止时间和缓冲区余量，把它当作安全标准。Results for the Streaming Media Performance Assessment

缓冲区大小与播放延迟

在相同条件下，预先存储的声音越多，就越容易吸收暂时的补充延迟；但另一方面，新生成的声音要排在已存储的声音后面等待。只听音乐时可以接受的等待，到了弹奏键盘，或者把麦克风的人声加工后自己监听时，操作和声音之间的错位就会令人在意。Exclusive-Mode Streams、Low Latency Audio

flowchart TB
    accTitle: 缓冲区余量与响应延迟
    accDescr: 预先存储的声音增多后，更容易吸收暂时的补充延迟，但新声音播放前的等待时间也会增加。
    A["增加预存的声音"] --> B["更易吸收补充延迟"]
    B -->|"代价是"| C["新声音排在后面等"]
    C --> D["从操作到出声变慢"]

图7：增大缓冲区，是以响应速度为代价换取余量的调整。

既不是“越小性能越高”，也不是“越大越正确”。要在保留所需响应速度的同时，留出不会中断的余量。

增大缓冲区的调整，是为应对暂时的供应延迟留出余量。如果平均供应本身就跟不上消耗，那么增大有限的缓冲区也只是推迟耗尽的时间，同样解决不了设备断开连接的问题。本文也不是在推荐“使用独占模式就能解决一切”。Exclusive-Mode Streams

48kHz、480 帧的音频

PCM 的帧是把同一时间点要播放的所有声道的采样合在一起的单位。并不是因为是立体声，就要把帧数乘以 2 来计算时间。帧数所代表的声音长度用“帧数 ÷ 采样率”求得，48kHz 下 480 帧就是 480 ÷ 48000 秒，也就是 10 毫秒。在 48kHz 不变的情况下增加帧数，能存储的声音时长也会变长。Rendering a Stream

这个时间不同于从按下琴键到听见声音的总延迟。因为其中还有应用、驱动程序、设备，以及其他缓冲区和处理所需的时间。DAW 的设置值也要先确认单位和所指的缓冲区再解读。Low Latency Audio

flowchart TB
    accTitle: 由帧数算出的时间与总延迟
    accDescr: 480 帧除以 48000 得到的 10 毫秒是缓冲区所代表的时间，再加上应用、驱动程序、设备等的处理，才是从琴键到声音的总延迟。
    A["480 ÷ 48000"] --> B["缓冲区代表的 10 毫秒"]
    B -->|"再加上其他处理"| C["从琴键到声音的总延迟"]

图8：由帧数算出的时间只是总延迟的一部分。

比较复现条件

先缩小能复现问题的组合范围，只在必要时才进入详细记录。以下是用于确认原因的步骤，并不是要把所有设置改动一次性全部执行的对策清单。

请先保存工作，等正式的会议或录音结束之后，再以不伤耳朵的音量进行测试。记下原来的输出目标、音频增强、缓冲区值等，确保可以恢复原状。没有提供相应设置的项目就跳过，不要为了调出设置项而修改注册表等。

1. 确定同一段简短的音源和观察时间，在原来的条件下确认能否复现。

   记录 Windows 的版本、应用名称和版本、输出设备、连接方式、驱动程序的版本。发生断音的时刻、操作和次数也要记下来。如果在原来的条件下无法复现，不要判断为已经改善，而要回头确认能复现的条件。

2. 从下表中选择一项比较，只改变该条件进行播放。

   要比较的条件	要调查的内容
   本地保存的音源与经网络播放	是否只在经网络播放时发生。即使内容相同，如果格式或处理路径不同，也要一并记录。
   用另一个应用播放同一音源	是否集中出现在特定应用上。
   蓝牙等输出与内置、有线输出	是否集中出现在特定输出路径上。
   音频增强的开启与关闭	是否因与效果处理的组合而发生变化。
   DAW 等的当前缓冲区与大一级的值	增加预存余量后是否有变化。从操作到出声的延迟是否也可以接受。

3. 比较音频增强时，在目标输出上暂时关闭该设置。

   在 Windows 的“设置”→“系统”→“声音”中选择目标输出，在可用的环境中关闭“音频增强”。如果显示内容或项目的有无与此不同，请查看该版本和设备的说明。Fix distorted or crackling audio in Windows

4. 把改过的设置恢复原状，用同样的音源和观察时间再试一次。

   把“原来的条件”“改变一项后的条件”“恢复原状后的条件”的结果并列比较。没有效果的改动要先恢复原状，再进行另一项比较。如果不断变换设置组合，就搞不清到底是什么起了作用。

5. 如果要尝试更换驱动程序，请先确认官方发布渠道和恢复方法再进行。

   使用 Windows Update 或设备厂商的官方发布版本，并记录更改前后的版本和设置。事先确认能否恢复原状；如果是受管理的电脑，请与管理员商量。不要因为更新后马上能正常播放一次就认为问题已经解决，而要在相同的复现条件下确认。Fix distorted or crackling audio in Windows

想要得到的结果，是像“在这个应用中使用这个输出时会复现”这样，把症状和条件联系起来的记录。即使找到了能改善的设置，也要把它与查明原因区分开来。

flowchart TB
    accTitle: 改变一个条件再恢复原状的比较
    accDescr: 用同一音源确认复现，改变应用或输出等其中一个条件，并记录恢复原状后的结果。
    A["以原组合播放"] --> B["改变一个条件播放"]
    B --> C["恢复原状播放"]
    C --> D["记下中断的条件与时刻"]

图9：比起一次好转，更要确认条件与症状能反复吻合。

改变条件前后的复现性

“症状得到抑制”“条件已经缩小”“已查明根本原因”是不同的阶段性结果。要按照实际观测到的范围记录结论。

flowchart TB
    accTitle: 显示与条件相关的三个结果
    accDescr: 若在原条件下复现、改变一个条件后改善、恢复原状后再次复现，就成为显示与该条件相关的线索，但要与查明原因区分开来。
    A["原条件下复现"] --> B["改变一项后改善"]
    B --> C["恢复后再次复现"]
    C --> D["与该条件相关的线索"]

图10：即使三项都满足，能知道的也只是相关的线索。

CPU 使用率低并不能证明音频的截止时间得到了遵守。同时，仅凭发生了断音，也不能说补充延迟就是根本原因。要比较音源、应用的处理、效果、输出路径等，在观测到的范围内作出判断。Fix distorted or crackling audio in Windows

采用临时规避方法时，要记下原来的设置、更改内容、观察时间、是否复发，以及可以接受的延迟。如果根本原因尚未确定，也要把这一点记录下来。

用 WPR 记录断音

这一步在仅靠条件比较无法缩小范围，或者需要调查驱动程序端的处理时进行。WPR 是用于记录的工具，WPA 是用于分析已保存时间轴的工具。需要准备 Windows Performance Toolkit、记录所需的权限，以及 ETL 的保存位置。在受管理的电脑上安装工具并记录时，请委托管理员进行。显示名称和可用的配置文件，请以所安装的版本为准进行确认。Windows Performance Recorder

ETL 中可能包含进程名称、文件路径等信息。记录之前请确认公司内部规定和共享对象，不要原样附加到公开的地方。如果有其他记录会话正在运行，不要擅自停止，应先向负责人确认。WPR How-to Topics

1. 打开 WPR 的“More Options”，选择符合目的的记录配置文件。

   内置配置文件中有“Audio glitches”和“CPU usage”。选择能够调查音频不连续和 CPU 活动的设置。可用的配置文件、显示名称和收集内容请在所安装的版本中确认，不要设置成长时间记录所有类型。Built-in Recording Profiles

2. 在复现断音之前开始记录。

   如果出现是否停止现有记录的确认提示，不要直接继续，而应取消开始，并向负责人确认。要使条件与不记录时保持一致，同时也要考虑到记录本身的负载可能改变症状。WPR How-to Topics

3. 用比较中找到的条件播放，记下中断的时刻和操作。

   在症状前后也包含一小段没有问题的区间。没有复现的记录要注明这一事实，不要把它当作捕捉到原因的记录。

4. 复现之后用“Save”结束记录，保存 ETL 文件。

   使用“Cancel”不会保存。记下保存位置、复现条件、是否有记录，以及有无事件丢失的警告。在有丢失的记录中，不要把看不到的区间判断为正常。WPR How-to Topics

备齐 ETL 文件和记有断音时刻、操作、条件的笔记后，就做好了在 WPA 中对照的准备。仅仅保存了记录，并不代表一定获取到了所需的事件。接下来在“断音前后的执行与等待”中确认其内容。

flowchart TB
    accTitle: 获取包含断音的简短记录
    accDescr: 用 WPR 开始记录，复现症状并记下时刻，停止并保存后，在 WPA 中检查记录。
    A["用 WPR 开始记录"] --> B["同条件下复现断音"]
    B --> C["记下时刻和操作后保存"]
    C --> D["在 WPA 中放大前后区间"]

图11：症状结束后再看 CPU 使用率是不够的，需要症状发生区间的记录。

断音前后的执行与等待

准备好已保存的 ETL 和记有复现时刻的笔记。以下是在 WPA 中调查的起点。如果需要包括堆栈和符号在内的详细分析，请注意记录的处理方式，并委托管理员或开发人员进行。

1. 在 WPA 中打开 ETL，根据已获取的音频事件和复现时刻，放大断音前后的区间。

   没有症状的区间也要保留下来用于比较。不要只看最大值的排名，而要统一到相同的时间范围进行比较。

2. 在同一范围内查看“DPC/ISR”和“CPU Usage (Precise)”。

   如果没有所需的数据，请确认所用配置文件能否获取这些数据，然后回到 WPR 的记录步骤。没有记录和没有问题是两回事。CPU Analysis、Built-in Recording Profiles

3. 区分与音频相关的线程是明明可以执行却在排队等待，还是在等待数据等。

   如果是前者，就对照相关逻辑 CPU 上是否有 DPC/ISR 等长时间运行。如果是后者，就借助已获取的事件和堆栈，追查是什么解除了等待。由于正在运行的线程也可能被中断打断，不要只盯着 Ready 时间，还要把 DPC/ISR 的区间叠加起来看。CPU Analysis

4. 把与断音在时间上的吻合情况、相关的 CPU、改变条件后的结果一并记录下来。

   不要仅凭长时间 DPC/ISR 的模块名称，就确定某个设备或驱动程序是原因。看到的也可能是其他时刻的大数值，或者多个设备共同经过的公共部分。

flowchart TB
    accTitle: 在断音区间调查等待方式
    accDescr: 放大断音前后的区间，查看音频线程的状态。如果是可执行状态下的排队等待，就与同一 CPU 上的 DPC 或 ISR 对照；如果是等待数据等，就追查解除等待的处理。
    A["放大断音前后区间"] --> B{"线程的状态"}
    B -->|"排队等待"| C["DPC/ISR"]
    B -->|"等待数据"| D["解除等待的处理"]

图12：不要只挑最大值，而要与音频处理所需的区间叠加起来解读。

如果无法查明，就以“尚未确定”的状态移交调查。随附的信息包括：OS、应用、设备和驱动程序的版本，复现步骤，更改前后的结果，发生时刻，收集用的配置文件，以及有无丢失警告。ETL 要遵循公司内部规定，只与负责调查的人员共享。

音频应用的预先读取

自己开发音频应用时，要把填充下一个缓冲区的处理设计成每次都能赶上期限。WASAPI 提供了通过事件接收“可以处理缓冲区的时机”的方法。Exclusive-Mode Streams

MMCSS 是向有时间约束的多媒体处理线程分配 CPU 资源的机制。它不具备预先从磁盘准备数据或消除锁等待的功能。即使利用 MMCSS 进行分配，也仍然需要另外设计数据准备和减少等待的方式。Multimedia Class Scheduler Service

flowchart TB
    accTitle: MMCSS 负责的范围
    accDescr: MMCSS 向有时间约束的处理线程分配 CPU 资源，但数据准备和减少锁等待要靠另外的设计来实现。
    M["MMCSS：分配 CPU 资源"] -.->|"另外需要"| D["数据准备与减少等待"]

图13：分配 CPU 资源，和让数据及时到位的设计，是两项不同的工作。

设计方针是把从文件或网络读取数据的处理，与交付音频的处理分开。耗时难以预估的准备工作要提前进行，交接时使用预先分配好的缓冲区。音频这一侧要设计成不必等待 UI 的响应、长时间的锁或同步的日志写入。

flowchart TB
    accTitle: 把耗时难以预估的准备与音频供应分开
    accDescr: 通过预先处理完成读取等工作，再经由缓冲区把准备好的数据交给音频处理，从而减少截止时间前长时间等待的设计。
    A["预先处理准备数据"] --> B["预先分配的交接区域"]
    B --> C["音频处理交付所需部分"]
    C --> D["供应给音频输出端"]

图14：把耗时的工作从声音交付的前一刻移开。

如果准备一侧长时间停滞，即使做了这样的分离，存量也会耗尽。不仅要记录平均处理时间，还要用不干扰音频处理的方式，记录出现长时间处理或等待的那几次，以及未能供应的次数。实际选定的缓冲区大小和周期要通过 API 或驱动程序确认，不要假定指定值会被原样采用。Rendering a Stream、Low Latency Audio

文中的数值示例和设计示例都是用于说明的，既不是针对特定设备的推荐设置值，也不保证在任何环境下都不会断音。

实时优先级的影响

不建议用户一概把整个播放器的优先级改为“实时”。这样做有妨碍其他重要处理的风险，而且提高普通线程的优先级，也并不能消除 DPC/ISR 或等待数据、锁的时间。开发时应使用 MMCSS 等机制，以及不把长时间等待带入音频供应的设计。Scheduling Priorities、CPU Analysis

flowchart TB
    accTitle: 改为实时优先级后仍然存在的等待
    accDescr: 即使把播放器设为实时优先级，普通线程也无法抢在同一 CPU 上的 DPC 或 ISR 之前，等待数据或锁的时间依然存在，还有妨碍其他重要处理的风险。
    A["播放器设为实时优先级"] --> B["无法抢在 DPC/ISR 之前"]
    B --> C["数据和锁的等待仍在"]
    C --> D["有妨碍其他处理的风险"]

图15：即使提高优先级，拖慢音频补充的等待仍然存在。

相关文章

• Windows 的“处理器计划”与后台服务设置
• 安全地排查 Windows 磁盘 100% 的原因
• 网络很快，RDP 为什么还是很卡？

参考资料

• Microsoft Learn, Rendering a Stream。向播放缓冲区供应数据、剩余量、实际的缓冲区大小，以及 PCM 帧的定义。
• Microsoft Learn, Exclusive-Mode Streams。缓冲区供应的时刻与音频毛刺（glitch）、与延迟之间的权衡、事件驱动的供应。并非一概推荐独占模式本身。
• Microsoft Learn, Low Latency Audio。Windows 的音频路径，缓冲区、设备、效果处理与延迟，以及低延迟的权衡。
• Microsoft Learn, CPU Analysis。逻辑 CPU、线程的 Ready/Waiting、DPC/ISR 与线程执行的关系，以及 WPA 的 CPU 分析。
• Microsoft Learn, Introduction to DPCs。缩短中断处理、把剩余工作交给 DPC 的机制。
• Microsoft Learn, Results for the Streaming Media Performance Assessment。较长或频繁的 DPC/ISR、数据供应不足与音频毛刺。不把评估的警告值推广为所有设备的安全标准。
• Microsoft Support, Fix distorted or crackling audio in Windows。音频增强、格式、驱动程序等的检查。
• Microsoft Learn, Windows Performance Recorder。ETW 记录与使用 WPA 的分析，以及 Windows Performance Toolkit 的使用。
• Microsoft Learn, Built-in Recording Profiles。WPR 的 More Options，以及 Audio glitches、CPU usage 等内置配置文件。
• Microsoft Learn, WPR How-to Topics。开始记录与用 Save 保存、与现有会话的冲突，以及有关个人信息和事件丢失的注意事项。
• Microsoft Learn, Multimedia Class Scheduler Service。向有时间约束的多媒体处理分配 CPU 资源。
• Microsoft Learn, Scheduling Priorities。进程和线程的优先级，以及有关实时优先级的注意事项。

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

CPU 使用率只有 10% 左右，为什么声音还会中断？

音频有一个截止时间：必须在正在播放的数据用完之前补充下一批数据。即使 CPU 整体使用率很低，如果音频处理在那个瞬间无法执行，或者正在等待所需的数据，也可能赶不上。并非所有断音都出于这个原因，还需要通过更换输出设备或应用来进行比较。

把音频缓冲区调大，断音就能解决吗？

如果补充只是暂时延迟，较大的缓冲区有时可以把它吸收掉。不过，播放已存储的声音之前的等待时间也会增加。这项设置并不能解决处理能力的持续不足，也解决不了设备断开连接。对于允许修改该设置的应用或驱动程序，请先记下原来的值，再逐级调整并比较。

48kHz 下的 480 帧相当于多少毫秒的声音？

480÷48000 秒，也就是 10 毫秒。PCM 的 1 帧，是把同一时间点所有声道的采样合在一起的单位。这个值是该帧数所代表的声音长度，并不是包含设备和应用在内的总延迟。

DPC 或 ISR 执行时间长的驱动程序就是断音的元凶吗？

它可以列为候选，但仅凭执行时间的排名无法确定。要把发生断音的时间段、音频线程的等待，以及同一 CPU 上 DPC/ISR 的执行对照起来看。不要仅凭模块名称就断定是某个设备或驱动程序的缺陷，还要确认改变复现条件后的结果。

把播放器设为实时优先级会有改善吗？

不建议一概这样做。即使提高普通线程的优先级，也无法抢在同一 CPU 上的普通 DPC 或 ISR 之前执行，等待数据或锁的时间也不会消失。开发者应使用 MMCSS 等机制，以及不引入等待的设计；用户则应先比较复现条件和输出路径。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长保留有既有资产的项目，以及原因难以看清的故障调查。