简介：STM32 USB AUDIO 系列进阶资源，面向嵌入式音频开发者，在 0 进 2 出基础上扩展为 2 进 2 出，支持 48k 采样率与 16bit 精度，新增两路麦克风输入，实现 USB OUT 至 USB IN 的音频回环测试。工程采用 2 字节模式，未集成 I2S 接口，精简数据通路，适合学习 STM32 USB 设备协议栈与音频数据传输流程。压缩包共 247 个文件，以 C 源文件、头文件、编译生成的 .o/.crf 中间文件为主，辅以 HAL 库外设驱动、I2S 相关代码、Keil 工程文件及调试配置，整体约 10.81MB，目录结构清晰。已有 230 人浏览学习。资源提供可直接编译运行的测试工程，包含完整的 HAL 初始化、USB 音频描述符配置与回调处理逻辑，可帮助开发者快速验证 48k/16bit 双通道回环性能，也可作为后续加入 I2S 输入或实现录音/播放并存功能的基础框架。 一套2进2出的USB声卡方案做完，顺便把坑也填了：这篇是STM32 USB AUDIO系列的第二篇，核心参数是48k采样率、2进2出、16bit。我会从需求拆解、硬件设计、固件实现到实际调试，完整过一遍这个项目的思路和踩坑记录，内容偏实战，想拿STM32做USB声卡、USB音频采集卡，或者只是想搞明白USB AUDIO设备枚举和数据流的，都值得看一下。
1. 需求分析与方案选型
1.1 “48k / 2进2出 / 16bit”这三个参数到底代表什么
先说结论：这套参数做出来的就是一个标准USB Audio Class设备，插到电脑、手机或者平板上，系统会直接识别成“USB声卡”，不需要额外装驱动（Class 1.0免驱，Class 2.0在Windows下需要第三方驱动或者UAC2驱动）。
48k采样率是音频领域非常通用的一个档位，很多专业声卡默认工程采样率就是48kHz，因为视频制作标准是48kHz，电影、短视频的音频制作基本都是这个采样率。2进2出意味着设备有一个立体声输入（麦克风/线路输入）和一个立体声输出（耳机/线路输出），也就是可以做USB声卡的同时，还能把外部信号采集进电脑。16bit是位深度，每个采样点占用2字节，立体声双通道一个采样帧就是4字节，按照48kHz来算，单方向的数据速率是48k × 2通道 × 2字节 = 192KB/s。
这个速率对USB Full Speed（12Mbps）来说完全是小意思，理论带宽约1.5MB/s，一个方向192KB/s，两个方向加起来也不算高，USB Audio Class 1.0在Full Speed下用同步传输完全跑得动。这也是为什么STM32这种主频不高的MCU也能做USB音频设备的原因：数据量不大，瓶颈不在总线速度，而在数据搬运方式和时钟同步策略。
1.2 选型思路：为什么用USB Audio Class而不是自定义协议
做USB音频有一个路线问题：是用USB Audio Class标准，还是用HID/CDC之类的自定义通道自己传PCM数据？
我的建议是：只要目标是做“能被系统直接识别的声卡”，就老老实实走标准Audio Class。原因很简单，自己做协议意味着上位机驱动也得自己写，还得考虑不同系统的兼容性。USB Audio Class是免驱方案，Windows、macOS、Linux、Android、iOS全都原生支持，插上就能用，这对产品化和日常调试的效率提升太大了。
标准协议带来一个必然的挑战：必须要严格遵守描述符结构。USB音频的描述符比HID复杂得多，一个2进2出的设备，需要音频控制接口（AC）、音频输出接口（AS out）、音频输入接口（AS in），还有对应的端点描述符和时钟实体。任何一个描述符的长度字段写错、接口关联不对，设备要么枚举失败，要么被系统识别出来但没有声音。
1.3 芯片选型与时钟方案
系列第一篇应该已经讲了不少基础，这里直接从芯片选择说起。我这次用的是STM32F407，原因很简单：内置USB OTG FS/HS，有专用的48MHz时钟来源，而且音频相关的PLL配置比较灵活。如果你用F103，也可以做USB Audio，但要注意F103的USB时钟必须由PLL精确输出48MHz，不能有偏差，否则枚举会不稳定。F103做单声道、2进2出这种简单音频还好，问题主要出在中断负载上。
时钟是USB音频设备最伤脑筋的地方。USB同步传输没有独立的时钟线，主机是根据USB帧首SOF来同步数据的，设备端需要保证自己的采样时钟与USB帧率一致。最稳的方案是用芯片内部的PLL把USB时钟锁定在48MHz，再从这个48MHz派生出音频主时钟，保证一个USB帧（1ms）里正好传输48个采样帧（48kHz）。F407的USB OTG FS内置了时钟恢复功能，可以基于SOF信号实时微调，实测比F103裸PLL要稳得多。
2. 硬件设计：管脚分配、供电和ESD
2.1 最小硬件框架
这套2进2出音频设备，硬件上其实不复杂，核心就是MCU加一个I2S音频编解码芯片，我选的是CS4272，它本身支持2进2出，I2S接口可以直接对接STM32，同时支持主从模式配置。耳机或者线路输出通过CS4272的DAC输出，麦克风或者线路输入通过ADC采集进来，MCU负责把USB收到的PCM数据通过I2S发给CS4272回放，同时把CS4272采集到的数据打包通过USB IN端点发给主机。
管脚分配上，I2S用的是SPI3的引脚：I2S3_CK（PC7）、I2S3_SD（PC12）、I2S3_WS（PA4），加上外部时钟输入或者MCU提供的MCLK。这里有个细节：CS4272需要MCLK主时钟，频率是采样率的256倍，也就是48k×256 = 12.288MHz。这个频率可以从F407的PLL输出配置得到，也可以用外部有源晶振直接给。我之前图省事直接用外部有源晶振给MCLK，稳定性和音质都比MCU内部生成来得可靠，如果你对底噪敏感，建议优先外置晶振方案。
2.2 USB接口部分的注意事项
USB D+/D-的走线要尽量短，等长，差分阻抗90欧。很多新手在这里翻车：USB线用杜邦线飞线，导致枚举失败或者掉线。另外D+上要有1.5k上拉电阻，USB Audio Class 1.0设备通过D+上拉告诉主机自己是Full Speed设备。F407的OTG FS接口已经内置了上拉电阻，可以通过软件控制，但如果你用的是F103的USB外设，外部上拉电阻一定要焊上。
电源部分建议做USB总线供电和外部供电隔离，至少加一个LC滤波或者磁珠，避免USB 5V纹波串进模拟音频电路。CS4272的模拟电源和数字电源要分开，模拟地尽量单点接地，不然会有比较明显的地环路噪声，电脑USB供电环境本身就不算干净，不加隔离会出现滋滋声。
2.3 信号链与音量配置
2进2出的模拟信号链路要考虑输入输出电平匹配。CS4272的ADC输入满量程大约在2Vrms级别，线路输出也是2Vrms级别。如果直接接麦克风，需要前置放大；如果直接接耳机，则需要加耳机放大电路，因为CS4272的输出驱动能力不够推低阻耳机。
我当时做调试板为了省事，输入先用驻极体麦克风加MAX9814放大，输出直接接有源音箱，这样省了耳放电路，测试时只需要关注数域的数据正确性和协议是否符合规范，模拟部分的问题后面再做板子时统一优化。调试阶段能少一个变量就少一个变量，这是嵌入式开发里很重要的思路。
3. 固件实现：USB描述符与PCM数据流
3.1 描述符结构的核心设计
USB音频的描述符是这套方案里最容易出错的部分，我把我的配置展开讲一下。
设备描述符：bcdUSB设为0x0200（USB 2.0），bDeviceClass设为0x00，bDeviceSubClass也是0x00，设备类在接口描述符中声明。这里有一个细节：配置描述符中audio class设备会有多个接口关联，标准配置描述符的bNumInterfaces设为3：音频控制接口（接口0）、音频流输出接口（接口1）、音频流输入接口（接口2）。
配置描述符里，接口0是AudioControl接口，包含一个时钟实体（Clock Source）、一个输入终端（IT，对应USB端点输入）、两个输出终端（OT，分别对应Speaker和Microphone），还有特征单元（Feature Unit）用来控制音量。接口1是AudioStreaming输出，有一个同步端点描述符，方向OUT，用于接收主机发来的PCM数据。接口2是AudioStreaming输入，同步端点方向IN，用于发送PCM给主机。
2进2出在这里体现在：音频流接口的类型描述符中，每个通道的物理定位（Physical Location）需要区分，比如输入终端对应的通道0是Left Front、通道1是Right Front，这样Windows的音频设备属性里才能正确识别为立体声。
这是我整理的描述符参考表：
| 描述符结构 | 用途 | 关键参数 |
|---|---|---|
| USB标准设备描述符 | 设备基本信息 | VID=0x1234，PID=0x5678 |
| USB标准配置描述符 | 接口数量与总长度 | bNumInterfaces=3，bMaxPower=50mA |
| AudioControl接口描述符 | 音频时钟/终端/特征单元 | CS=0x24，时钟源ID=1 |
| AudioStreaming接口描述符 | 格式类型与通道数 | bNrChannels=2，bSubslotSize=2，bBitResolution=16 |
| 同步端点描述符 | 等时传输端点属性 | wMaxPacketSize=192字节（OUT/IN） |
wMaxPacketSize要根据48k/16bit/双通道计算：48kHz一个USB帧1ms，一个帧最多传48个采样帧，每个采样帧4字节，所以wMaxPacketSize=192字节。如果是96kHz，就要384字节，但那已经接近Full Speed的限制了，这也是很多人说Class 1.0顶多到96kHz的原因。
3.2 数据流：中断、DMA与缓冲区策略
数据流是整个固件里最需要小心的地方。USB OUT端点收到主机发来的PCM帧后，不能直接丢进I2S发送缓冲就完事，还要处理USB帧与I2S帧的同步问题。如果主机发的数据和I2S消费的数据速率不一致，哪怕只是百万分之几十的偏差，长时间运行也会出现缓冲上溢或者下溢，表现为爆音或者周期性卡顿。
我的实现方式是这样的：USB同步端点采用双缓冲（double buffering），配合PCD的FIFO机制，每次端点收到一个完整的USB帧，触发回调，将数据拷贝到环形缓冲区（ring buffer），同时I2S的DMA从另一个缓冲区自动搬数据到CS4272。I2S发送采用DMA双缓冲模式，当DMA搬完一块数据，产生中断，然后从环形缓冲区再取一块数据填充。这样USB接收和I2S播放是解耦的，只要环形缓冲区水位保持在合理范围，就能保证连续播放。
采样率锁定方面，我启用了STM32 USB OTG的“内部时钟恢复（HSE-based）”功能，也就是让USB外设根据SOF自动调整收发数据的节奏，去适配主机端的48k时钟。实测下来，长时间跑24小时，缓冲区水位基本保持稳定，没有暴音，这在Class 1.0方案里已经算很实用的效果了。
3.3 关键代码的实现细节
描述符部分，直接定义配置描述符数组，按序排列标准配置描述符、接口描述符、类特殊描述符、端点描述符。这里我贴一段核心的AudioStreaming接口描述符（C代码格式）：
/* Audio Streaming Interface Descriptor (1.0) */ 0x09, /* bLength: 9 */ 0x04, /* bDescriptorType: INTERFACE */ 0x01, /* bInterfaceNumber: 1 */ 0x00, /* bAlternateSetting: 0 */ 0x00, /* bNumEndpoints: 0 */ 0x01, /* bInterfaceClass: AUDIO */ 0x02, /* bInterfaceSubClass: AUDIO_STREAMING */ 0x00, /* bInterfaceProtocol: IP_VERSION_01_00 */ 0x00, /* iInterface: 0 */接口的bAlternateSetting=0表示零带宽，端点数为0，主机在启动播放时会重新选择为bAlternateSetting=1（含端点）的设置，这是USB音频的标准做法，可以让设备在非播放状态不占总线带宽。下面是对应bAlternateSetting=1的端点描述符：
0x09, /* bLength */ 0x05, /* bDescriptorType: ENDPOINT */ 0x01, /* bEndpointAddress: OUT endpoint 1 */ 0x0D, /* bmAttributes: ISOCHRONOUS, ASYNC */ 192, 0, /* wMaxPacketSize: 192 bytes */ 0x01, /* bInterval: 1ms */ 0x00, 0x00, /* bRefresh / bSynchAddress */bmAttributes设置为0x0D，对应同步传输、异步模式。如果把0x0D改成0x05就是自适应模式。Class 1.0设备常用自适应或者异步，我的实现里采用异步模式，配合I2S从机模式，让外部CS4272主导采样时钟，USB端跟随外部时钟来调整数据量，这样对抖动很友好。
实际工程里还有一个注意点：每次打开设备播放时，要重新处理bAlternateSetting的选择，很多问题都是在这里出的——比如主机发起SET_INTERFACE请求切换AltSetting，但固件没正确处理，导致没有使能端点，设备管理器里显示正常但是没有声音。
4. 调试与实测：从枚举失败到稳定运行
4.1 枚举阶段的常见问题
这个项目调试过程中最头疼的就是枚举失败。我遇到最典型的两种情况：一是设备完全没响应，设备管理器里出现未知设备（或者USB Virtual COM Port出现感叹号）；二是设备识别成功，但控制面板里没有声音设备。
如果是完全没响应，先查硬件：上拉电阻有没有焊、D+/D-有没有接反、晶振有没有起振。其次查固件里的USB时钟配置，F407需要确认USB OTG FS使用的是PLL48CK还是HSI48，如果把PLL配置错了，枚举会随机失败或者干脆不识别。代码里可以通过检查USB OTG GINTSTS寄存器来确认USB挂起/复位中断是否触发。
如果识别到未知设备，基本是描述符错误。我知道一个很坑的地方：描述符的bLength或者wTotalLength没更新，主机解析到一半就断了。建议先用Bus Hound或者Wireshark的USBPcap抓一下枚举请求，看看主机在哪一步失败，是GET_DESCRIPTOR(DEVICE)就出错，还是到CONFIGURATION才出错。这一步能省下大量盲改代码的时间。
4.2 播放无声、爆音和回音问题
枚举成功、控制面板也有设备，但没声音，这种问题一般是数据链路断掉了。先说几个检查点：bAlternateSetting是不是切换到了1；OUT端点是否已经使能并调用HAL_PCD_EP_Receive开始接收；DMA搬运到I2S的数据格式是不是正确。16bit数据在小端模式下，存在缓冲区内的顺序是低字节在前，如果代码里做了字节翻转或者没用memcpy直接搬运，容易把左右声道的数据搞混或者产生明显噪声。
爆音的排查路径我总结了一个表格：
| 故障现象 | 可能原因 | 处理思路 |
|---|---|---|
| 播放开始一瞬间爆音 | USB端点未预填充数据，I2S空跑 | 开启播放前先向环形缓冲区填充静音帧，再启动DMA与端点接收 |
| 每隔一段时间周期性“咔”声 | 缓冲区上溢/下溢，同步失效 | 检查SOF中断是否处理，确认是否启用时钟恢复，观察环形缓冲区水位 |
| 持续尖锐噪声 | I2S位时钟/帧时钟配置错误或者MCLK未提供 | 示波器看I2S3_CK和I2S3_WS信号，确认MCLK频率是否为12.288MHz |
| 输入信号有明显回声 | ADC采集与回放同时启用，系统把输出混入输入 | 检查混音器寄存器，关闭数字回环或者调低回放音量 |
回音问题在2进2出设备上特别容易遇到，如果系统自带“立体声混音”默认开启了，录进来的就包含了播放的声音，这个不算固件bug，但要在开发文档里提醒测试人员注意。
4.3 48k指标的数据验证
设备能不能真正跑到48kHz，很多人的验证方式只是看控制面板里显示“48kHz”就觉得没跑了。我建议更严谨一点：用音频软件生成一段1kHz正弦波，从播放端放出，再从录音端录回来，做频谱分析，看1kHz处的能量是否干净，同时看底噪电平。另外可以直接对比录回来的波形过零率，侧面验证采样率是否准确。
我实际测得的情况：录回来的1kHz信号频偏小于1Hz，THD+N大概在0.05%左右（CS4272的数据手册标称会更好，这里受限于供电和PCB布局），底噪在-80dBFS级别。对于学习验证来说，这个指标已经相当不错了，证明USB传输链路没有丢包、没有时钟漂移导致的失真。
5. 工程化落地：从开发板到可复现模板
5.1 工程目录与代码组织
调试稳定之后，我把工程重构成一个可复用的模板。代码按模块拆分：
- usbd_desc.c：设备描述符、字符串描述符
- usbd_audio.c：Audio Class初始化、SET_INTERFACE、音量控制、静音控制处理
- usbd_audio_if.c：数据接收/发送回调，负责与音频DSP逻辑层交互
- audio_core.c：环形缓冲区管理、水位控制、PCM格式转换
- cs4272_driver.c：CS4272初始化、I2S配置、音量/静音设置
这样分层的意义在于，后续如果换音频编解码芯片，只需要替换cs4272_driver.c，USB和音频核心逻辑可以复用。如果以后想升级到96kHz或者24bit，也不用动USB协议栈，只需要改描述符里的子帧字节数和格式类型，加上把采样率相关的PLL配置改一下。
5.2 上位机音频测试路径
开发阶段我用到的测试工具有几类：Windows自带的“声音”控制面板用来做设备识别和默认设备设置；Audacity做录音和回放测试，测波形、频谱；FFmpeg也可以用来播放和录制，但没Audacity直观；Bus Hound做USB协议抓包，排查描述符问题；如果遇到设备感叹号，先用设备管理器禁用再启用一次，不行再查驱动签名问题。
有一个很实用的小工具建议常备：USB Device Tree Viewer，可以非常清楚地看到设备枚举后的接口、端点、类描述符，比设备管理器里的信息全得多，排查描述符问题时一秒定位到是哪个接口的AltSetting有问题。
5.3 结构化复用清单
最后给一个可复制的落地清单，照着这个顺序做，可以少走很多弯路：
- 确认USB时钟源与PLL配置，让USB取得精确48MHz，再配置I2S的MCLK到12.288MHz。
- 搭建描述符数组时，先按接口顺序逐一核对，尤其注意配置描述符总长度随接口数量增加需要更新。
- 初始化时先使能USB设备，再初始化I2S和CODEC，避免开启播放时没有音频数据导致DMA空转。
- 播放前用静音帧预填充环形缓冲区，避免起始爆音。
- 录音启动时，先清空USB IN端点的发送FIFO，并将端点就绪置位，保证主机请求数据时能立刻拿到完整帧。
- 稳定跑通后再处理音量控制、静音控制等特征单元功能，不要一开始就把所有功能堆上去，否则排查问题时头大。
6. 最后补充一点调试心得
这次项目从裸机配置到跑通48k 2进2出16bit，实际上花时间最多的不是写代码，而是排查枚举和时钟同步。USB音频的调试信息很少，出了问题屏幕也不会告诉你具体原因，只能靠抓包和示波器慢慢抠。如果遇到设备管理器里各种“XX设备”出现感叹号，或者枚举成功后没声音，先稳住心态，按“时钟→描述符→端点→缓冲区”的顺序去查，大多数问题都跑不出这几个环节。
另外一个体会是：USB音频这种外设，坚持用标准协议栈真的会让开发省心很多，不管是裸机的USB库（比如STM32 USB Device Library）还是CubeMX生成代码，都可以走Class 1.0免驱方案，关键是理解清楚每个描述符的含义，而不是盲目复制粘贴。代码能跑跟代码跑得稳是两码事，尤其是同步性和缓冲管理，这部分深入下去，后面做96kHz、24bit甚至UAC2设备都会顺手很多。下一期如果有机会，我再展开讲讲音量控制和UAC2的切换思路。
本文还有配套的精品资源，点击获取
