VAC驱动组件是WDM/KS 驱动，处于Windows音频子系统的最底层。大多数应用程序不直接连接到它。相反，它们使用系统音频引擎提供的更高级别的WASAPI、 MME、DirectSound和其他接口。引擎将应用程序请求转换为驱动程序。使用此类中间层，应用程序无法完全控制所有音频参数。因此存在一些特殊问题和限制。乍一看，它们可能看起来相当复杂，但在实践中很容易理解。

驱动器引脚分配

WDM/KS音频驱动程序（如DirectShow 过滤器）创建由多个引脚表示的KS 过滤器。如果应用程序或系统需要录制或播放音频，它会创建指定引脚的实例。这样的 pin 实例与数据流关联，实例所有者（应用程序或系统音频引擎）成为驱动程序的 客户端。

在独占模式下 使用WDM/KS或DirectSound/WASAPI 的应用程序请求单独的引脚实例。如果存在可用的 pin 实例，则该请求成功，否则失败。大多数现代音频驱动程序仅支持单个引脚实例。因此，仅当特定设备驱动程序支持多个引脚实例时， 多个KS感知应用程序才能同时录制/播放。

为了允许同时播放/录音的可能性，当在共享模式下通过WASAPI、 MME、DirectSound或其他更高级别的接口访问引脚时，系统音频引擎使用自己的引脚实例。当应用程序以共享模式连接到端点时，此类连接请求将由System Audio Engine隐式提供服务。如果引擎已连接到适当的引脚（拥有专用引脚实例），则该现有实例将在所有应用程序之间共享。否则，引擎会尝试创建一个 pin 实例来共享。如果没有空闲实例，则应用程序的请求失败。

如果应用程序通过系统音频引擎请求独占模式访问，但不 存在相应引脚的共享模式连接（没有为引擎本身分配公共引脚实例），则引擎首先创建其公共引脚实例以允许进一步共享- 模式 连接（但有一个已知的错误）。如果驱动程序是单客户端并且仅支持单个引脚实例，则将没有可用实例来满足独占模式访问请求。在这种情况下，请求会在共享模式下被拒绝或满足，具体取决于参数。

因此，如果没有足够的可用 pin 实例，出于兼容性目的， Windows 更喜欢共享模式访问。但直接KS访问请求不会通过系统音频引擎，因此它们可以分配最后一个（甚至单个）可用的 pin 实例。如果在第一个较高级别请求之前发出此类直接低级别请求，则系统音频引擎将无法创建其公共（共享）实例，并且所有进一步的较高级别请求（无论共享模式还是独占模式）都将失败。

反之亦然，如果系统音频引擎已分配最后一个（或单个）可用引脚实例，则进一步的直接KS访问请求将失败。

系统音频引擎的格式选择

创建一个引脚实例来服务共享模式连接，系统音频引擎需要为其选择一种音频格式。格式选择基于其连接请求中指定的应用程序格式、引脚支持的格式集以及一些其他规则。

在Windows 10x 和 6.x中，引脚格式由为所有共享模式连接指定的默认终结点格式确定。

在Windows 5.x中，使用以下规则：

• MME回放：采样率等于所请求的，每个样本的位数优选为16，通道数优选为2（立体声）。

• DirectSound回放：采样率等于来自驱动器设置的第一匹配，每个样本的比特优选地是16并且通道的数量优选地是2（立体声）。

• MME录音和DirectSound捕获：格式与要求的相同，除了一些不兼容的情况（奇怪的采样率、通道数大于 8 等）。

如果可能的引脚格式参数受到严格限制并且系统音频引擎无法使用 16 位和 2 个通道，则可以使用其他位数和/或通道数。

流和客户端计数

与录音或播放设备的 所有共享模式连接都是通过使用单个公共引脚实例的系统音频引擎建立的。因此，如果您的应用程序使用共享模式访问，您将在VAC 控制面板 中仅看到单个播放和/或单个录制流。这是因为所有这些应用程序都不是 VAC 驱动程序客户端。他们是System Audio Engine的客户。VAC 甚至对它们的存在和流媒体活动一无所知；他们的所有请求均由系统音频引擎处理。

为系统音频引擎 创建的 pin 实例通常是“粘性的”，并且在所有应用程序关闭与虚拟电缆端点的连接后仍会持续几秒钟。您可以在VAC 控制面板中看到这一点。

只有独占模式连接才允许应用程序成为 VAC 客户端，创建自己的 pin 实例和关联的数据流。对于每个独占模式 连接，记录/回放流计数器都会对附加流进行计数。

您可以尝试各种应用程序和格式，并在VAC 控制面板中观察客户端/流的数量。

Windows 音频子系统 组件和某些应用程序可能会访问 VAC 驱动程序及其引脚以进行属性请求，从而不创建引脚实例。此类连接计入VAC 控制面板的“驱动程序客户端”字段中。

如何选择电缆格式

对于每条虚拟电缆，VAC 都会维护电缆格式。有线格式是所有有线客户端（数据  流）的通用格式。所有渲染（输出）数据都转换为电缆格式，混合，然后分发到所有捕获（输入）客户端，转换为其特定格式。

当虚拟电缆变为活动状态（获取其第一个客户端 流） 时，VAC 选择电缆格式。如上所述，可能存在隐式的、隐藏的客户端，例如系统音频引擎，它们可能请求与应用程序指定的格式不同的格式的连接。

例如，虚拟电缆 1播放端点的默认格式设置为 48000/16/2。应用程序通过System Audio Engine请求独占模式连接，指定 96000/24/2。在满足此请求之前，系统音频引擎请求一个用于共享模式 访问的 pin 实例，指定默认设备格式 (48000/16/2)，VAC 将其固定为电缆格式。然后，引擎仅为应用程序请求另一个 pin 实例，指定 96000/24/2。但电缆格式 仍然是 48000/16/2，因此 VAC 会将 96000 下采样到 48000，并将 24 位样本削减为 16 位样本。因此，分配给共享模式访问端点的 默认格式可能会影响对同一端点的独占模式访问。

同样，不正确的电缆格式范围可能会导致Windows 5.x 中的质量问题。例如，如果范围设置为 22050-96000/8-32/1-8，系统音频引擎将使用 96000/32/8 创建自己的通用引脚实例，并且电缆格式设置为相同。如果大多数应用程序使用 44100/16/2、48000/16/6 等格式，则会出现许多不必要的格式转换。

为了防止此类问题，请选择尽可能接近您最喜欢的格式集的电缆格式范围。详细信息 请参见格式限制规则。

基于第一流格式选择电缆格式， VAC驱动程序尝试继承流格式的通道分配掩码。但如果流格式和有线格式的通道数不同（例如，如果流格式限制模式设置为“驱动程序范围”），则有线格式的通道掩码设置为统一的。统一通道掩码包含从最低有效位（位 0）开始的适当数量的连续“1”位。例如，八个通道的统一掩码将始终为 0xff。由于这种技术，在具有通道数范围“1..1”和流格式限制模式的电缆上创建立体声流 “驱动程序范围”，将有线通道掩码设置为“1”而不是通常的“4”（FC）。

端点排列问题

在MME接口中，端点通过它们的号码来访问。最初，音频应用程序应枚举所有播放和/或录制端点以获取它们的名称，然后使用适当的数字来访问所需的端点以进行播放和/或录制。

当您连接或断开可移动音频设备、更改默认端点设置，甚至连接/断开硬件输入/输出（麦克风、耳机、线路输入/输出、HDMI 插头等）时，系统音频服务可能会重新排列适当类型的端点（播放和/或录音）。在这种情况下，一些（甚至全部）MME端点号码可能会改变。大多数 MME 应用程序（包括版本 1.60.7 之前的音频中继器）仅在启动时枚举端点，然后仅使用数字来访问它们。如果端点排列改变，则在下一次播放和/或记录尝试时可能会访问错误的端点。

为了避免此类问题，请要求应用程序重新枚举音频端点（如果可能）。否则，关闭应用程序并再次运行。

其他事宜

Windows 6.x + 系统有一个常见错误，如果存在一些活动（已分配）引脚实例（流），该错误会阻止系统音频引擎为共享模式访问 创建其公共捕获（录音）引脚实例。例如，如果您已经使用KS 接口（KS 版本的Audio Repeater、ASIO4ALL或类似的东西）开始录音，然后尝试在共享模式下使用更高级别的接口（MME、DS、WASAPI）开始录音，就会发生这种情况。作为解决方法，首先启动更高级别的界面，然后启动 KS 录制。

从版本 4.70 开始，VAC 驱动程序默认 从音频引擎隐藏活动引脚实例计数，因此该系统错误不会暴露。