前阵子有个朋友找到我，他想做一个音频设备管理工具，需要在C#程序里把当前系统的扬声器、麦克风设备列出来，能显示设备名称、状态，还能判断哪个是默认设备。一开始他想用老一套的API去查，结果不是拿不到完整信息，就是设备名显示成“扬声器 (Realtek(R) Audio)”这种半残格式，插拔设备之后数据还不刷新。我建议他直接换到Core Audio APIs这套方案，问题一下子清爽了。
这篇内容就围绕“C# 使用 Core Audio APIs 获取音频设备信息”这条线展开。想用C#读取Windows音频设备信息的开发者，或者正在做播放器、录音软件、在线会议工具、系统检测工具这一类应用的人，都会用到这套技术。文章会拆解Core Audio的核心架构、COM接口定义、设备状态判断、属性读取方式，并给出可直接复制的代码示例和避坑经验。如果你以为这只是查一个设备列表那么简单，那看完之后你会改变想法——这套API能做的事情，比大多数人想象的要多得多。
1. 为什么放弃老旧方案，转投Core Audio APIs
1.1 传统音频API的局限
在Core Audio（核心音频）这套API出现之前，Windows上拿音频设备信息主要靠两路子。
一条是WinMM（Windows Multimedia API），也就是用waveInGetNumDevs、waveOutGetNumDevs这类函数去枚举设备。这条路子的问题很明显：它能拿到的设备信息非常有限，通常只有一个设备名和一个ID，没有设备状态、没有默认设备标记、没有数据流向（输入还是输出）的概念。更麻烦的是，它枚举出来的设备跟你在系统声音设置面板里看到的设备经常对不上号，年代久远的虚拟声卡驱动更是会把它搞晕。
另一条路是DirectSound，它最早的定位是游戏音频的低延迟播放，枚举设备的API（DirectSoundEnumerate）虽然比WinMM强一点，但它本质上是一个面向播放场景的API，对采集设备（麦克风、录音接口）的覆盖很弱，而且它枚举出来的设备顺序和逻辑跟系统真实的音频端点并不一致。你在DirectSound里看到的第一个设备，未必就是系统的默认播放设备。
这两个方案还有个通病：它们拿到的设备名称是驱动层提供的“底层名字”，而用户在看系统“声音”设置面板时看到的，是经过端点（Endpoint）层处理的“上层名称”，这两者经常不一样。做音频相关工具的人应该都有体会——用户说“我的耳机坏了，程序里根本找不到”，实际上程序能找到设备，但显示出来的名字是个谁都看不懂的驱动型号，用户没法把设备跟硬件对上号。
1.2 Core Audio到底改了什么
Core Audio架构是随Windows Vista引入的一套底层音频体系，后来的Windows 7到Windows 11都一直沿用，没有大改。它的核心思路是引入音频端点（Audio Endpoint）这个概念。
音频端点是什么概念呢？你可以把它理解成“系统声音面板里看到的那个设备项”。物理上一个声卡可能同时具备多个功能，比如一组3.5mm接口既能输出音箱、又能接入麦克风，但在Core Audio的视角里，这是两个完全独立的端点：一个负责渲染（Render，即播放），一个负责采集（Capture，即录音）。每个端点有一个全局唯一ID（Endpoint ID），有一组可读写的属性（友好名称、设备描述、状态、图标等），还能区分是否默认设备。
这套端点模型正是开发音频工具时最需要的抽象层——你看到的就是用户看到的，不用自己再做一层设备名称映射。
用Core Audio APIs去枚举设备，拿到的数据跟系统设置面板保持一致，设备的热插拔状态也会实时反映出来。这就是我推荐那哥们用这套API的最根本原因。
1.3 新旧方案对比
| 对比项 | WinMM | DirectSound | Core Audio APIs |
|---|---|---|---|
| 设备名称准确性 | 底噪驱动名，常对不上 | 同上 | 与系统声音面板完全一致 |
| 默认设备判断 | 不支持 | 无标准方案 | 原生支持 |
| 设备插拔状态 | 只能重新枚举 | 只能重新枚举 | 实时通知机制 |
| 输入设备支持 | 有但很弱 | 弱 | 原生支持 |
| 属性扩展（图标等） | 无 | 无 | MMDevice属性存储 |
| 使用时序 | 兼容层 | 兼容层 | Windows核心音频路径 |
所以现在只要不是维护十几年前的老项目，获取Windows音频设备信息，Core Audio就是正解，没有之一。
2. 开工前的技术底料：核心概念与COM接入准备
2.1 Core Audio不是DLL函数，是COM组件
很多第一次摸Core Audio的人会习惯性想找“一个DLL，查一下导出函数”。这是初学时最容易踩的思维坑。Core Audio APIs不是传统的导出函数，而是一整套COM接口。
COM这个事听起来老气，但理解起来不难。你就把它当成：系统提供一个对象管理器，你通过它拿一个“枚举器”，再拿“设备集合”，再操作集合里的“单个设备”，每一步都通过接口去调方法。C#里做这事，要么用官方封装，要么自己定义一套等价接口，然后通过类型转换去调用。
对C#开发者来说，接入方式有两条路。
第一条是使用第三方封装库，比如“某开源音频库”里已经把设备枚举这块包得非常好，拿到一个设备列表只需要两三行代码。适合那些不想深入底层、只想快速把功能跑起来的项目。
第二条是自己定义COM接口，通过P/Invoke或COM Interop方式调用。这种方式写起来麻烦一些，要写一堆接口定义、GUID、方法签名，但换来的是最底层、最完整的控制力，还能摆脱对第三方库的依赖。
我给朋友建议的是第二条路。因为他的项目后续还要做音量控制、设备状态监听、音频会话管理，这些只有自己在底层控制了才能做得顺手。官方封装库在设备枚举上虽然好用，但一碰到特殊需求就会暴露短板，到时候再切换到原生COM代价更大。
2.2 核心COM接口速览
要操作Core Audio，绕不开这几个COM接口。我把它们逐一说清楚，因为后面写代码时，这些接口就是你的主力工具。
| COM接口 | 职责说明 |
|---|---|
| IMMDeviceEnumerator | 设备枚举器的入口，负责列举设备、获取默认设备、注册状态回调。所有操作的源头 |
| IMMDeviceCollection | 设备集合，持有N个IMMDevice，可获取数量、按索引取出设备 |
| IMMDevice | 单个音频端点设备，可以获取设备ID、激活接口（如音量控制）、打开属性存储 |
| IPropertyStore | 设备属性存储，用PKEY键值对读取设备的友好名称、描述、图标等信息 |
| IAudioEndpointVolume | 控制端点音量和静音状态（后续扩展用） |
这套接口之间存在清晰的调用顺序：先从MMDeviceEnumerator拿到枚举器对象，再调EnumAudioEndpoints方法拿到设备集合，然后从集合里取出单个设备，再打开设备的属性存储读取各类信息，或者进一步激活其他功能接口。
顺序一旦搞反，代码就会报类型转换异常，这是初期最容易出现的低级错误。但只要你记住这个链路，后面很多问题都能靠这个关系去推理。
2.3 线程模型和初始化细节
COM这套接口还有个隐藏要求：必须在正确的线程模型下初始化。具体来说，IMMDeviceEnumerator要求线程是STA（Single-Threaded Apartment）模式，这在Windows Forms、WPF的主线程里默认就是，控制台程序就得靠手动做CoInitialize。
控制台程序里，第一步要做的是调用CoInitializeEx并传入COINIT_APARTMENTTHREADED，让当前线程进入STA模式。在纯C#里，很多人直接忽略这一步，结果发现设备枚举偶尔正常、偶尔崩溃，代码飘忽不定。正确的做法是在Main函数入口把线程模型处理掉，有两种方案，一种是用[STAThread]标记入口方法，让CLR自动处理；另一种是在代码里显式调用CoInitializeEx。
如果用Windows Forms的控件事件里去调用，那基本不用担心线程模型，UI线程本身就是STA。但如果开了后台线程去做设备扫描，那就必须在新线程里重新做CoInitialize，否则拿到的COM对象可能在跨线程封送时出问题。
把这些底子打牢之后，我们再正式进入代码部分。
3. 实战：两步走拿到设备列表与默认设备
这部分我直接给出完整可跑的C#代码。整个流程拆成两段：一段是使用第三方封装库的方案，适合快速演示；一段是原生COM定义方案，适合深入掌握。如果你想在生产项目里长时间使用，建议直接用第二种。
3.1 第一版：用封装库快速实现
如果你用的是“某开源音频库”之类的库，代码短得非常感人。下面这段就是枚举系统中所有播放端点和采集端点的逻辑，用NuGet装好包之后可以直接跑。
using AudioLibrary; var enumerator = new MMDeviceEnumerator(); var devices = enumerator.EnumerateAudioEndPoints(DataFlow.Render, DeviceState.Active | DeviceState.Disabled); foreach (var device in devices) { Console.WriteLine($"ID: {device.ID}"); Console.WriteLine($"Name: {device.FriendlyName}"); Console.WriteLine($"State: {device.State}"); Console.WriteLine($"Default: {device == enumerator.GetDefaultAudioEndpoint(DataFlow.Render, Role.Console)}"); Console.WriteLine(); }这段代码里，DataFlow.Render代表输出端点，DataFlow.Capture代表输入端点。DeviceState枚举组合可以一次性列出“活动”“已禁用”“未插拔”等状态的设备。默认设备的判断是用GetDefaultAudioEndpoint去拿系统当前默认端点，再跟列表里的设备逐一比对。
这套方案的优点很直接：代码量极小，几乎不用理解COM内部细节，名字、状态、默认值全都封装好了。但它也有明显的天花板——第三方库不一定支持你需要的所有功能，特别是你要操作音频会话级别的信息时，库往往只暴露了很少的入口，剩下的还得自己往下挖。
所以我建议：如果你想快速验证，用上面的代码就够了；如果你想做严肃的音频工具，请往下看原生方案。
3.2 第二版：原生COM定义与完整实现
原生COM方案的第一步是定义一套C#可以调用的接口。这里的代码量虽然多，但是每一行都好解释，并且可以复用在一个通用音频工具类里。
先需要引入程序集身份信息，每个COM接口都要绑定一个全局唯一标识GUID，这些GUID可以从官方头文件里查到，也必须一致，一个都不能抄错。下面是核心部分的接口定义。
using System; using System.Runtime.InteropServices; [ComImport] [Guid("BCDE0395-E52F-467C-8E3D-C4579291692E")] internal class MMDeviceEnumeratorComObject { } [ComImport] [Guid("A95664D2-9614-4F35-A746-DE8DB63617E6")] internal interface IMMDeviceEnumerator { int EnumAudioEndpoints(EDataFlow dataFlow, uint stateMask, out IMMDeviceCollection devices); int GetDefaultAudioEndpoint(EDataFlow dataFlow, ERole role, out IMMDevice device); int GetDevice(string id, out IMMDevice device); int RegisterEndpointNotificationCallback(object callback); int UnregisterEndpointNotificationCallback(object callback); } [ComImport] [Guid("0BD7A1BE-7A1A-44DB-8397-531D75A13C7E")] internal interface IMMDeviceCollection { int GetCount(out uint count); int Item(uint index, out IMMDevice device); } [ComImport] [Guid("D666063F-1587-4E43-81F1-B948E807363F")] internal interface IMMDevice { int Activate(ref Guid iid, int dwClsCtx, IntPtr pActivationParams, out object ppInterface); int OpenPropertyStore(int stgmAccess, out IPropertyStore properties); int GetId(out string id); int GetState(out uint state); }这里说明几个关键点。
EDataFlow是一个枚举，Render代表播放，Capture代表采集，All代表全部。这个枚举值在调用EnumAudioEndpoints时作为第一个参数传入。stateMask是一个位掩码，用来过滤设备状态，我们常见的范围是“活动+已禁用+未插拔”这些都要，直接用三个常量做位或运算。
ERole是音频角色的枚举，表示音频端点承担的角色，一般是Console（通信）、Multimedia（多媒体）这几种，通常判断默认设备时传Multimedia。
为了读设备属性，还要定义IPropertyStore接口和相关的PKEY结构。IPropertyStore是COM的属性存储接口，配合PROPERTYKEY结构体，用GetValue方法就能按Key取出属性。
[ComImport] [Guid("886D8EEB-8CF2-4446-8D02-CDBA1DBDCF99")] internal interface IPropertyStore { int GetCount(out uint count); int GetAt(uint index, out PROPERTYKEY key); int GetValue(ref PROPERTYKEY key, out PROPVARIANT value); int SetValue(ref PROPERTYKEY key, ref PROPVARIANT value); int Commit(); }PROPERTYKEY和PROPVARIANT的定义要按C++侧的内存布局来。PROPERTYKEY是“一个GUID + 一个long型ID”的组合，PROPVARIANT则是联合体，在C#里最省事的做法是把所有字段用显式布局定义出来。读取字符串时，我们只需要关心vt字段等于VT_LPWSTR（值为31）的情况。
[StructLayout(LayoutKind.Sequential)] internal struct PROPERTYKEY { public Guid fmtid; public int pid; } [StructLayout(LayoutKind.Explicit)] internal struct PROPVARIANT { [FieldOffset(0)] public ushort vt; [FieldOffset(8)] public IntPtr pointerValue; }需要注意的是PROPVARIANT的指针偏移位置，字符串值类型存储在相对偏移8的位置。这个细节不准确的话，读出来就是乱码。
定义好接口，接下来就是枚举设备。完整逻辑如下：
public List<AudioDeviceInfo> GetAllDevices() { var devices = new List<AudioDeviceInfo>(); var enumerator = new MMDeviceEnumeratorComObject() as IMMDeviceEnumerator; // 枚举所有播放端点，状态过滤：活动 + 禁用 + 未插拔 Marshal.ThrowExceptionForHR( enumerator.EnumAudioEndpoints(EDataFlow.Render, (uint)(DeviceState.Active | DeviceState.Disabled | DeviceState.NotPresent), out var collection)); Marshal.ThrowExceptionForHR(collection.GetCount(out uint count)); for (uint i = 0; i < count; i++) { Marshal.ThrowExceptionForHR(collection.Item(i, out var device)); var info = ReadDeviceInfo(enumerator, device); devices.Add(info); Marshal.ReleaseComObject(device); } Marshal.ReleaseComObject(collection); Marshal.ReleaseComObject(enumerator); return devices; }读取单个设备信息的方法：先拿设备ID，再取状态，然后打开属性存储，用固定的PKEY键去读友好名称和设备描述。
private AudioDeviceInfo ReadDeviceInfo(IMMDeviceEnumerator enumerator, IMMDevice device) { device.GetId(out string id); device.GetState(out uint state); device.OpenPropertyStore(0, out IPropertyStore store); string friendlyName = ReadPropertyString(store, PKEY_Device_FriendlyName); string deviceDesc = ReadPropertyString(store, PKEY_Device_Desc); // 比较是否是当前默认播放设备 bool isDefault = false; IMMDevice defaultDevice; Marshal.ThrowExceptionForHR( enumerator.GetDefaultAudioEndpoint(EDataFlow.Render, ERole.Multimedia, out defaultDevice)); if (defaultDevice != null) { defaultDevice.GetId(out string defaultId); isDefault = string.Equals(id, defaultId, StringComparison.OrdinalIgnoreCase); Marshal.ReleaseComObject(defaultDevice); } Marshal.ReleaseComObject(store); return new AudioDeviceInfo { Id = id, FriendlyName = friendlyName, Description = deviceDesc, IsDefault = isDefault, State = (DeviceState)state }; } private static string ReadPropertyString(IPropertyStore store, PROPERTYKEY key) { store.GetValue(ref key, out PROPVARIANT value); try { if (value.vt == 31 && value.pointerValue != IntPtr.Zero) { return Marshal.PtrToStringUni(value.pointerValue) ?? string.Empty; } return string.Empty; } finally { // 释放PROPVARIANT内部内存，避免每次读取都泄漏 PropVariantClear(ref value); } }这里的PropVariantClear是PropVariantClear系统函数，作用是把COM分配的内存释放掉。如果不用它清理，程序跑久了内存会持续上涨，因为PROPVARIANT里的字符串指针是由COM层分配的，.NET的垃圾回收管不到它。
读取属性用到的两个常量键，是音频设备属性存储里的固定Key片段：
private static readonly PROPERTYKEY PKEY_Device_FriendlyName = new PROPERTYKEY { fmtid = new Guid("A45C254E-DF1C-4EFD-8020-67D146A850E0"), pid = 14 }; private static readonly PROPERTYKEY PKEY_Device_Desc = new PROPERTYKEY { fmtid = new Guid("A45C254E-DF1C-4EFD-8020-67D146A850E0"), pid = 2 };这两个键值是从设备属性定义里拿出来的固定值。FriendlyName是用户看得懂的名字，比如“耳机 (USB Audio Device)”；Desc有时候跟FriendlyName相同，有时是更底层的描述。如果你还要拿设备图标，可以继续读PKEY_DeviceClass_IconPath这类键。属性键的fmtid, pid组合，相当于一个字典条目里的Key，取值方式就跟查字典一样。
至此，原生COM版的设备枚举核心代码已经完整。这两段代码跑起来之后，输出的设备列表应该跟系统声音设置面板里的列表一一对应。
4. 核心细节拆解：设备信息字段的获取与含义
4.1 设备状态（DeviceState）到底有哪些
Core Audio中设备状态定义得很细，实际开发时很多人被状态搞懵。以下是我整理后的对应关系：
| 状态值 | 枚举名 | 含义 |
|---|---|---|
| 1 | Active | 设备正常工作，连接到系统，驱动就绪 |
| 2 | Disabled | 设备已禁用（比如在设备管理器停用） |
| 4 | NotPresent | 设备当前物理上没有连接，但注册信息还在 |
| 8 | Unplugged | 设备曾经存在，目前被拔出或断开连接 |
很多时候你会看到设备出现在列表里，但用户说“没有这个设备”。一查状态，发现是Unplugged或NotPresent。区分Active和Unplugged非常重要，因为你做设备选择界面时，应当把非Active状态的设备置灰，不然用户选中了插着不用的设备，程序怎么调它都不会出声。
4.2 设备命名的那些坑
设备友好名称（FriendlyName）这条路本身有很多细节。属性存储里除了FriendlyName，还有好几个跟名字相关的键，比如DeviceDesc（设备描述）、DeviceInterfaceFriendlyName（接口友好名）、DeviceFriendlyName（设备友好名）。这几个键的值经常互相包含，组合出来的效果五花八门。
比如某个USB声卡，DeviceDesc可能是“USB Audio Device”，DeviceInterfaceFriendlyName可能是“USB Audio Device”，而FriendlyName可能是“耳机 (USB Audio Device)”或“USB Audio Device”。为什么会有差异？因为FriendlyName通常是系统从驱动INF文件和端点属性里拼接出来的，不同厂商驱动差异非常大。
我建议做设备列表时，显示FriendlyName为主，同时把DeviceDesc作为备用显示值。如果FriendlyName读出来为空再降级到Desc，这样至少不会出现空白。
还有一个老坑：同一个物理设备，受驱动影响，可能在系统中注册出多个端点ID，每个端点ID对应不同名称和状态。枚举时必须以端点ID为准做去重，不能简单用名字去重，因为两个不同端点可能显示一样的名字。
4.3 默认设备的判定标准
默认设备判断有个容易忽视的点：“默认设备”并非一个固定值。系统里没有“全局唯一默认设备”，而是按数据流向和角色组合出多个“默认值”。
- 播放设备默认值：Render方向下，Console角色和Multimedia角色可能不一样。
- 录音设备默认值：Capture方向下，通信类角色和多媒体类角色的默认设备可能不同。
所以拿默认播放设备时，必须明确你问的是哪个角色的默认。做一个音乐播放器，你要的是Multimedia角色；做一个VOIP通话工具，你要的是Console角色。不少开发者在这里传错角色，结果拿到的设备跟系统声音面板第一项对不上，查半天发现是这个原因。
代码层面，判断默认设备最稳的方案是：先获取默认设备ID，再遍历列表比对ID。不要在获取设备集合时企图“排序”出默认设备，这种排序并不可靠。你捕获的ID比对方式正确了，结果就一定正确。
4.4 为什么我选择结构体而非动态查询
有些封装方案提供的是匿名对象或DataTable风格的数据，一行代码能拿到设备列表。但在我看来，做一个明确的AudioDeviceInfo类，包含Id, FriendlyName, Description, State, IsDefault这些强类型字段，更符合C#开发者的使用习惯。后面不管是绑定到列表控件还是写JSON序列化，都顺手得多。
封装库的快速方案固然省事，但当你窥见原生COM的整个链路之后，你会理解每条信息从哪里来、怎么格式化、为什么有的字段可能为空。这种认知才是处理各种设备兼容性问题的底气。
5. 避坑实录：我调试这些接口时踩过的坑
这一节直接把我这几年用Core Audio APIs时踩过的坑都列出来，每一个都是从线上真实环境里带出来的教训。按照遇到的概率排个序。
5.1 线程模型是万恶之源
控制台程序里一口气写完代码，运行时偶尔报COMException，缩放窗口后又正常。这个问题的根因就是没有CoInitialize，或线程模型不匹配。
解决方法很简单：入口方法加[STAThread]特性。如果你还不放心，手动调用CoInitializeEx并检查返回值：
提示：所有COM调用必须在STA线程中完成。WPF/WinForms主线程默认就是STA，控制台程序务必在Main上标记[STAThread]。
这个坑排第一，是因为它影响所有后续COM调用，而且报错信息还特别有迷惑性，有时是“未初始化”，有时是“无效指针”，排查半天都不一定想到线程模型。
5.2 COM对象的释放与内存泄漏
PROPVARIANT里的字符串指针、IMMDevice对象、IMMDeviceCollection对象，这些都需要手动释放。这几天实测下来，如果每个设备读取都忘记释放PROPVARIANT字符串，两三百万次调用下来会吃掉几百MB内存。
IMMDevice对象在实现上属于进程内COM组件，其内部可能缓存了驱动信息。循环枚举设备时如果每轮new一个对象且不释放，内存曲线就会一直往上走。建议的做法是：用完即调Marshal.ReleaseComObject，同时配合try-finally保证异常时也能释放。
另外一个不太为人知的细节：某些情况下ReleaseComObject可能抛出异常，因为对象已被释放或跨线程使用。所以我的习惯是包里放一个工具方法SafeRelease，捕获异常并置空引用，免得主流程被释放逻辑打断。
5.3 设备拔插与列表缓存失效
很多开发者把设备列表拉出来之后，长期不刷新。结果是：用户拔掉USB耳机，程序里还在显示它；用户插上新的耳机，程序完全不认识。
Core Audio本身提供了IMMNotificationClient回调接口，可以监听设备状态变化（添加、移除、属性变更、默认设备变更）。生产级工具一定要去订阅这个通知，不要用Timer轮询。
实现这个回调接口需要另外定义一组COM接口，核心是OnDeviceStateChanged和OnDefaultDeviceChanged两个方法，前者响应设备状态变化，后者响应默认设备切换。收到回调后重新调用枚举流程刷新列表，界面就能做到秒级同步。
5.4 64位与32位程序的差异
Core Audio的COM定义在32位和64位程序里，PROPVARIANT的内存布局是一致的。但实际测试中，32位进程读取某些设备属性时，指针值偶发异常，尤其是字符串指针从设备属性存储返回时，会发生封送错误。
如果你在用32位模式编译，建议对读取到的字符串加一层空引用校验，同时使用IntPtr类型而不是int来承载指针值，避免截断问题。如果你没有特殊的兼容性需求，新项目直接用AnyCPU或64位编译就能省掉大部分麻烦。
5.5 系统版本差异的隐性行为
Windows 7到Windows 11，Core Audio接口本身没变，但部分设备属性键（比如新增的空间音频相关属性）在旧系统上不存在。读取这类键时，COM会返回错误码，你要做的是忽略错误并给默认值。
还有一个Windows版本差异：Windows 10及以上版本中，“禁用”状态的设备可能不会出现在默认枚举状态掩码中，除非你把DeviceState.Disabled也加进去。这就是为什么我在前面的代码里使用了Active | Disabled | NotPresent的组合掩码。
5.6 特殊设备：虚拟声卡和蓝牙耳机
虚拟声卡（播放器虚拟设备、会议软件虚拟麦克风）在Core Audio里也是一个普通端点，跟物理设备享受同等待遇。这类设备有些属性的FriendlyName为空，需要你回退到DeviceDesc。
蓝牙耳机的情况更复杂：它连上时会有“已连接”和“未连接”两个状态，Core Audio中表现为两个端点（一个Handsfree模式、一个A2DP模式）。很多用户看到列表里出现两条同名设备觉得程序有问题，其实这就是系统真实状态。这个场景下，务必把设备ID完整展示在调试界面中，帮助用户区分两条不同的蓝牙配置。
5.7 默认设备变化的悄无声息
用户插上USB音箱后，系统可能自动把默认设备切换过去。你的程序如果缓存了默认设备的ID，且后续一直拿这个缓存值去驱动音频播放，就永远不会切到新设备上。
正确的做法：使用IMMNotificationClient的OnDefaultDeviceChanged回调，实时刷新当前默认设备ID。这就是为什么我建议工具类内部维护一个设备缓存+回调事件，而不是每调用一次就裸查一次。
6. 扩展思路：从“获取信息”到“掌控设备”
6.1 音量精细控制与静音指示
拿到IMMDevice之后，调用Activate方法可以激活很多子接口，其中最常用的是IAudioEndpointVolume。用它就能做音量条、静音按钮，甚至模拟系统音量弹窗的实时状态。
激活写法是在IMMDevice.Activate里传入IAudioEndpointVolume的GUID，拿到对象后调用GetMasterVolumeLevelScalar和SetMasterVolumeLevelScalar，实现0.0到1.0的线性音量控制。很多播放器自带的音量混合器功能就是这么做的。再进一步，还可以注册回调监听音量变化，实现界面同步。
6.2 音频会话识别与进程绑定
每个正在发声的应用程序，在Core Audio体系里就是一个Audio Session（音频会话）。通过IAudioSessionManager接口，可以枚举当前所有会话，拿到每个会话对应的进程ID、音量、静音状态，还能把某个应用单独静音或调音量。
这是做“进程级音量控制”工具的核心路径。Windows自带的音量合成器其实就是用这套接口实现的。如果你想自己写一个增强版，完全可以做得比系统默认的还好用。
6.3 全方位设备属性读取
设备属性存储里远不止名字和描述。你可以读这些Key，得到设备驱动版本、接口路径、图标路径、设备所在总线类型（USB/PCI/蓝牙）等。这些信息对做系统诊断工具特别有价值。比如用户反馈“设备无法识别”，通过读取总线类型和驱动版本，往往能直接定位问题方向。
6.4 与多媒体框架衔接
我们通过Core Audio拿到的设备ID和Device对象，后续可以在播放器、音频采集、语音通信等场景中直接衔接使用。音频框架的初始化接口可以接受端点ID，直接用我们没有再做的用户选择结果，跳过系统默认设备这一步。
这就把两条线打通了：一条是设备选择与状态监控（Core Audio），一条是音频数据的播放与采集（其他音频框架）。它们之间的衔接点就是设备ID。当你需要主导一切时，这种搭配可以做到非常灵活。
在实际项目（模拟音频设备管理工具X）里，我就是按这个思路把设备枚举、默认切换监听、音量控制、会话管理逐步加进去的。一开始只是为了让用户看到设备列表，到后来慢慢做成了一个小型音频控制中心。Core Audio APIs的整体路线非常清晰，只要把最初的COM调用理顺了，后面的扩展就是一个接口接一个接口的事。
最后再分享一个个人心得：做音频设备这块，遇到最多的问题不是代码不会写，而是对设备状态和命名规则的认知不到位。用户报障“设备不见了”的时候，先去查是不是Unplugged，再查是不是Disabled，然后再去核对FriendlyName是否被驱动改过，这三个排查顺序如果倒过来，你会被各种假象带偏。这也是为什么这篇文章花了大量篇幅讲状态和命名——设备枚举这种事，看起来简单，做深了全是细节。希望这些经验能让你少折腾几个通宵。
