前言
- 对使用RT-Thread Audio框架的音频功能开发：播放与录音做个总结，为后期的进一步开发做个准备
- 音频属于多媒体范畴，涉及的范围广，且部分知识点比较专业，包括音频管理、音频设备的配置、音频的编解码，Codec驱动的配置等
- 本文主要谈一下在嵌入式STM32平台上搭建音频的播放与录音的开发环境，分析音频功能开发过程遇到的问题，总结调试经验与问题解决方法
难点剖析
- 音频是怎么实现播放与录音的？
- 首先开发板需要具备文件系统功能，也就是可以把wav或mp3等格式的文件传入开发板的存储设备，最好使用SD卡这样的大容量的存储设备
- 一般的音频文件占用的空间比较的大，如普通的mp3文件，都是MB级别的大小，直接把整个文件放进一个内存buffer中，发给codec，MCU的RAM资源不够，所以需要拆包，如拆成1K、2K、4K等大小，持续的分包发给codec（音频编解码芯片）进行播放
- 像STM32的大部分系列MCU，本身不具备mp3硬件解码，需要软件解码mp3，才能正常的播放
- 目前STM32L4、STM32H7系列，都有SAI接口，这个SAI接口配置与Codec的配置如何协调，这个可以参考STM32官方的BSP，有些开发板有类似的功能，可以参考，从而提高开发效率，降低开发的难度
开发流程
- 根据原理图，配置音频相关的引脚，STM32L4、STM32H7系列的MCU，主要是：SAI 引脚与 Codec（通信控制）引脚，如I2C，这部分可以使用STM32CubeMX 生成
- Codec（音频编解码）芯片的资料一定要多看，熟悉起来，了解每个寄存器的配置，就像是了解一个难度低的MCU芯片一样，电源配置、声音配置、采样波特率、采样位数、主模式（录音）、从机模式（默认，音频播放）
- STM32 SAI驱动，要认真的看，在播放音频时，SAI是主机模式，Codec 是从机模式，注意SAI的时钟配置，音频音频采样率会来自 SAI时钟，而SAI时钟源，可能是STM32系统时钟的某个PLL，如PLL2P，这样播放不同采样率的【音频文件】时，会先解析得到【采样波特率】，可能会更改【STM32系统时钟PLL配置】，造成挂在STM32的这个时钟源上的其他外设工作异常，此处【硬件设计】时，需要考虑【音频时钟源】问题，时钟配置问题后面抽时间详细整理。
- 最小音频的验证工程，前期我在这上面浪费的大量的时间，基于一个较复杂、难调试的大工程，会降低效率，问题排查比较的耗时，后来才硬着头皮搭建了最小的RT-Thread系统，使用ART-Pi开发，把SD卡、SAI、I2C、Codec驱动、wav 播放、wav 录音等慢慢加上去，发现音频问题的排查变得高效起来
- 【参照例程】，需要查找相关的资料，如SAI配置、SAI DMA的配置、所选Codec 的驱动等。如开始我参考ART-Pi SDK 工程里的
sdk-bsp-stm32h750-realthread-artpi\projects\art_pi_net_player，这在【音频播放】上，提供了较大的参考，但是这个功能没有包含【录音】功能，在开发【录音功能】时，一直卡壳，徘徊了很久，最后通过不断加深对Audio框架、SAI与Codec驱动的认识，最后不断的通过加法、减法的方式，把【录音】功能跑通 - 【造轮子】，造了轮子后，我发现，RT-Thread SAI驱动配置、DMA配置、sound（音频播放设备）、mic（音频录音设备）等，都有【现成】的参考，这套功能，在 Pandora STM32L475开发板上，是存在的。所以【绕了一圈】再回来，使用【现有轮子】开发，就是简单的配置与调试了，改改配置与Codec驱动，就等于初步把音频调通了
- 构建调试环境：硬件配合软件，构建一个音频的调试环境，先把：wav 的播放调通，在把wav 录音调通，可以使用 RT-Thread shell 命令，我调试录音时花费了不少的时间，走了很多的弯路，如录音与播放，需要切换Codec的模式，更改Codec的配置，这部分需要反复的对比【codec 芯片手册】，录音完了，存成文件，然后命令播放，有时录音后播放全是杂音，而把录音文件放到电脑上，发现录音质量差点，但又声音，所以播放与录音模式切换需要注意一下。
- 开发应用管理，如播放与录音管理，先实现【默认配置】，如默认的【采样波特率】、【采样位数】、【采样通道数】，使用【状态机】管理如开启、停止等音频状态管理
卡壳记录
- 由于前期对Audio框架没有深入的认识，也没有参考RT-Thread Audio的文档，总以为播放与录音功能是做在一起的，一个是发送，一个是接收，在注册与打开播放设备【sound】时，没有按要求使用标志位，造成播放与录音时，控制指令无法下发到底层设备，软件调试，发现需要两个设备，并且每个设备，有不同的标志位（模式）
#define RT_DEVICE_OFLAG_WRONLY 0x002 /* 标准设备的只写模式，对应 Audio 播放设备 */
#define RT_DEVICE_FLAG_RDONLY 0x001 /* 标准设备的只读模式，对应 Audio 录音设备 */
卡壳记录二
- 这个问题是【录音】的数据，全部为0，也就是DMA 可以接收到数据，但是接收到的数据全部为0
- 分析手段是，【搭建最小系统】排查，发现Codec驱动在没有录音的情况下，也是【一直吐数据】的，可能是因为Codec的时钟一直存在的问题，我加入了判断，只有启动录音时，才接收DMA，发现录音后的数据，依旧是0
- 问题的排查：通过查看Codec的手册，我发现一个忽略的问题：录音模式触发问题，也就是前面尝试调试音频驱动时，我发现录音启动时，需要与播放挂钩，如配置SAI_TX DMA的发送，发送两个字节 【0x00， 0x00】到Codec，在启动 SAI_RX DMA 接收，我把这个发送两个字节的注释掉了，最后发现就是这个问题！
- 【分析结论】，通过查看Codec芯片的手册，我找到了问题点：
- 原来，I2S、DSP等模式，需要 2个额外的 数据来触发，如录音时，需要把 Codec 切换到 master 主模式，此时 STM32作为从模式，录音的时钟来自Codec。启动录音时，发送两个额外的字节是有用的，否则，录音的数据全部是0。
卡壳记录三
- 【录音】全部是杂音问题，无论是开发板播放还是把录音文件，拷贝到电脑上，播放时杂音，后来我改了【音频Codec】的音量、发现问题没有解决，后来开启录音【回放】功能，感觉有声音，由于调试使用的是【手机的耳机MIC】，所以声音本身也比较的杂乱
- 最终定定位：不断的调整Codec的配置，一个个寄存器的配置修改，甚至【录音】时关闭【播放】，发现的全部是杂音，最后终于定位到了，经过反复【断电】【重启】确认，解决了【全部是杂音问题】，原来是【音频路径】配置的问题
- MIC 在硬件上，接的是：LINPUT2 与 RINPUT2，并且两根线连接在一起，我开始认为是【差分输入】，所以我【特意】配置为【L-R Differential】差分输入模式，后来我尝试更改为：LINPUT2 与 RINPUT2 模式，发现录音的声音好转了。。。
- Codec 正确的配置如下：
卡壳记录四
- 最小系统验证音频，发现播放与录音功能正常，但是把音频的功能放到主工程后，发现死机，主要问题来自：【SAI 系统时钟源配置】，为了实现 SAI 的播放与录音，SAI 时钟源不是随意的，需要根据【采样波特率】进行调整，而SAI 的时钟源跟系统的其他的外设使用同一个时钟源，造成播放或录音时，需要更改系统的时钟，引起其他外设工作不正常
- 解决方法：暂时没有完美的解决方法，不过发现使用寄存器配置的方式，系统不死机，使用HAL库配置方式，在RT-Thread 下，引起死机。这个问题后面详细分析，暂时使用【寄存器配置时钟】方法
- 【建议】在STM32使用音频播放与录音时，需要注意各个外设【系统时钟源】分配问题
小结
- 嵌入式音频开发涉及的范围比较的宽，并且部分知识点比较的专业，需要深入了解【音频编解码Codec】的工作原理，了解 ADC（模数转换）在MIC 录音的配置，DAC（数模转换）在Sound（播放）时的配置，了解声音的资源格式，后期了解音频的各种压缩 格式，如常见的 mp3格式
- 对于STM32，需要熟悉SAI、I2S，了解DMA数据流发送与接收的配置
- 需要了解数据流的写【通过device框架】、数据流的读【通过pipe】、音频设备的配置方式，音频的控制逻辑