简介面向初学者的C#语音合成测试例程定位在演示如何借助Visual Studio 2010与系统自带System.Speech组件通过少量代码实现文本到语音TTS播报。例程覆盖Windows语音开发的核心链路引用System.Speech库、创建SpeechSynthesizer对象、调节发音速度与音调并调用Speak方法完成语音输出适合刚开始接触人机交互或语音合成的开发人员快速建立整体认知。压缩包共24个文件包含6个C#源文件承载完整逻辑、3个exe可执行程序便于即时听效果、txt说明文档梳理了操作步骤另有项目配置与资源文件辅助复现环境整体仅39KB、轻量易下载。已有331人学习下载。通过学习初学者既能巩固C#基础语法又能理解TTS技术从文本输入到语音播报的完整流程为后续开发有声读物、语音导航、无障碍辅助工具等场景提供直接参考整体结构清晰适合用作课程设计或入门练习的起点。1. 语音测试例程到底在测什么先拆测试项再动手写代码上周产线反馈回来一批语音提示板提示音明显发闷。我远程连接过去把固件里内置的语音测试例程跑了一遍1kHz正弦波回采幅度比参考值低了6dB顺藤摸瓜定位到采样率配置在一次固件合并时被悄悄改错。事后复盘如果没有这套语音测试例程光靠耳朵听、拿示波器戳这种问题最快也得折腾半天。语音测试例程说白了就是一段专门用来验证语音信号链路的代码主控发起已知信号经过音频Codec、功放、麦克风通路再回到主控用量化数据判断这条通路是否健康。它解决的典型问题有三个驱动写完了不知道配得对不对、整机联调时说不清是谁的锅、产线上没法靠听感做批量判定。适合刚接触音频开发的嵌入式工程师也适合要给产线做测试工具的兄弟参考。1.1 哪些东西需要这套例程我这些年接触过的语音项目被测对象大致分三类。第一类是音频Codec周边比如WM8960、ES8388、TLV320AIC3204这类芯片集成了ADC和DAC需要验证录音、放音、回环是否正常。第二类是离线语音识别模块或语音提示芯片主控通过串口或SPI控制它播放指定词条但真正出声的音量、音质、通道是否正常主控并不知道需要例程去核验。第三类是独立功放和麦克风阵列功放虚焊、麦克风贴偏这类生产问题通过电信号测试比人工听更靠谱。不管对象是哪类语音测试例程的核心思路是共通的构造一个已知信号送入被测通路在另一端采集并比对。1.2 测试项清单一张表看懂该测什么我第一次写语音测试例程时恨不得把所有指标都塞进去结果代码臃肿、调试困难。后来收敛成这几项覆盖率已经足够应对绝大多数失效场景。测试项测法判定指标基本通路主控经DAC输出1kHz正弦波耳机听音或ADC回采幅度在参考值±3dB内回环测试ADC采集外部输入经DAC播放比对输入输出波形波形一致无明显断裂频响输出100Hz~8kHz扫频正弦波逐点回采各频点幅度在容差范围内失真THD输出1kHz正弦波频域分析谐波分量THD小于1%底噪SNR不送信号采集ADC静音数据底噪低于-60dBFS声道分离度左、右声道分别送信号测对端串扰分离度大于40dB产线测试不需要每个项目都全跑但哪怕只做前三项也能挡住九成以上的硬件失效。2. 音频通路搭建I2S、Codec与DMA的配合是关键例程代码量不大但音频通路这一段配置是整个例程的地基这里配错后面所有判定都是白搭。2.1 典型硬件拓扑与主控差异绝大多数语音例程的硬件拓扑是主控的数字音频接口I2S/PCM连到CodecCodec模拟端接麦克风、Line In、功放和喇叭。主控负责送数字音频数据、配置Codec寄存器、接收采集数据。不同主控的差异主要在数字音频接口的底层实现。以我常用的几款为例STM32F407VET6用I2S外设时钟来自PLLI2S需要手工算分频参数TMS320F28388D这类C2000系列在音频上相对冷门但它有独立I2S模块而且是双核架构语音例程放CPU1还是CPU2、共享外设怎么加保护都得提前规划GD32的I2S寄存器大体兼容STM32但时钟树细节不同直接把STM32初始化代码搬过去容易翻车。所以拿到一个新平台我习惯先不看别人的例程而是去读参考手册里音频时钟那一章把采样率对应的分频关系算清楚再动手。2.2 Codec配置里的三块关键寄存器Codec寄存器少则几十个、多则上百个但语音测试例程真正关心的只有三块。第一块是时钟树。Codec需要MCLK、BCLK、LRCK三者频率严格对应。比如MCLK12.288MHz对应48kHz采样率MCLK11.2896MHz对应44.1kHz这个对应关系错了回放声音就会变调。第二块是数据格式I2S标准、左对齐、右对齐16位还是24或32位主控和Codec必须完全一致否则数据错位表现出来就是明显爆音或噪声。第三块是模拟路径DAC和ADC分别使能、输入通道选对、增益合适尤其要把自动增益控制ALC/AGC关掉——测试信号会被ALC“自动补偿”掉幅度判定彻底失真。上电时序也是个高频坑。多数Codec要求主控上电后先复位、等稳压稳定再写寄存器最后才使能DAC/ADC输出。顺序反了轻则配置失败重则寄存器读写都异常。2.3 DMA双缓冲别省音频是持续流式数据如果用中断逐字节搬主控基本不用干别的了。正确做法是DMA加双缓冲也就是常说的Ping-Pong。播放方向DMA从内存读数据送到I2S半传输中断时填前一半缓冲传输完成中断时填后一半采集方向反过来。这样做的关键收益是即使主控偶尔被别的任务卡一下只要在半个Buffer的时间内赶回来音频流就不会断。Buffer大小一般按20ms左右算48kHz、16位双声道的话一个Buffer大约1920字节两个共3840字节MCU内部RAM完全放得下。下面是一段STM32F407上I2S加DMA的初始化骨架重点看双缓冲触发逻辑// 伪代码骨架实际需按HAL库或标准库补全GPIO/时钟配置 void AudioInit(I2S_HandleTypeDef *hi2s) { // I2S主机模式I2S标准48kHz16bit hi2s-Init.Mode I2S_MODE_MASTER_TX; // 回环测试时用 TX/RX 双工 hi2s-Init.Standard I2S_STANDARD_PHILIPS; hi2s-Init.DataFormat I2S_DATAFORMAT_16B; hi2s-Init.AudioFreq I2S_AUDIOFREQ_48K; // DMA循环模式 半传输/传输完成中断 hdma_tx-Init.Mode DMA_CIRCULAR; __HAL_DMA_ENABLE_IT(hdma_tx, DMA_IT_HT | DMA_IT_TC); // 中断服务函数里根据半传输/全传输切换填充哪一段Buffer }C2000、GD32上的实现大同小异核心就一句话数据搬运交给DMA中断只做Buffer切换标志不要在中断里干重活。3. 例程框架用状态机把“测”和“判”拆开很多人的测试代码是顺序执行的一条长龙初始化、放音、延时、录音、算结果、打印。简单项目这么写没问题测试项一多就得改成状态机不然改起来想死。3.1 上下位机交互与命令协议产线场景下例程通常不是独立跑的而是由上位机触发。我用过串口和以太网TCP两种方式后者对应的就是LabVIEW那套TCP通信例程的思路。无论哪种命令协议最好固定成帧格式帧头(0xAA 0x55) | 命令字(1字节) | 数据长度(2字节) | 数据 | CRC校验(2字节)命令字定义清楚就行0x01启动通路测试、0x02启动频响扫描、0x03读取测试结果、0x04进入休眠。测试结果也按同样帧结构回传。这样上位机只管收发不用关心MCU内部细节。用TCP时一定要处理粘包和拆包。LabVIEW的TCP Read如果一次读到的字节数不等于期望值要么循环读要么按帧头帧尾重新组包否则下一帧就对不齐了。3.2 核心流程信号发生与回采判定例程内部的流程分四步生成已知信号、送入通路、采集回读、计算指标并判定。信号发生推荐查表法加DDS思路不要现场调sin函数算太占CPU。提前生成一个周期的正弦表比如1024点存成const数组播放时按频率换算步进即可改频率只需要改步进不用重新算表。回采后的判定分两档。第一档是时域指标直接算RMS值跟参考值比对适合判断幅度和底噪。第二档是频域指标用FFT或者Goertzel算法提取特定频点幅度适合算THD和频响。MCU资源紧张时优先用Goertzel它不需要整个FFT缓冲一个频点接一个频点算RAM占用小得多。3.3 判定阈值怎么定最有讲究这是我最想强调的部分。阈值定死了换一批物料可能误杀稳定良品阈值定宽了真正坏的板子漏过去。我的做法是先找三块“黄金样机”也就是硬件验证完全通过、各项指标都很健康的板子把例程跑出来的数据作为基线。然后在基线基础上放容差幅度类指标通常放±3dBTHD放1%以下底噪按环境修正。产线环境如果有空调、风扇背景噪声比实验室高一截阈值要按产线实测环境重新标定不能拿实验室数据硬套。另一点测试时如果板子带喇叭建议放进同规格的消音箱或固定工装里麦克风到喇叭的距离要固定。距离变了回采幅度变化远大于硬件本身的误差会严重干扰判定。4. 实测踩坑例程写好了却在板子上“说不出话”这套例程我在STM32F407VET6、TMS320F28388D、GD32等平台都跑过踩的坑有共性也有个性挑几个典型的讲。4.1 I2S完全没有输出SCK/WS是死的现象是初始化完了示波器戳SCK引脚一点波形都没有。排查顺序很重要先查MCLK有没有出来很多Codec没有主时钟直接罢工再查I2S外设是否进入工作状态主机模式下SCK和WS在使能后就该有输出最后查Codec的上电和复位时序通过寄存器回读确认配置是否写进去。我遇到最隐蔽的一次是Codec的RESET引脚被固件误配置成了普通IO上电后一直拉低Codec处于复位态I2S当然没输出。这种问题光看代码逻辑很难发现最后是拿逻辑分析仪抓RESET引脚电平变化才定位到的。4.2 录音底噪大回环失真严重回环测试不过先别怀疑代码把模拟链路过一遍。常见原因有三个麦克风偏置MICBIAS没配置电容麦克风没有工作点模拟输入增益打得太高把底噪一起放大地线布局有问题喇叭地和模拟地串在一起形成地环路。另外前面强调过测试时要关ALC/AGC很多人漏了这一步。ALC开启时测试正弦波会被当成环境音量自动压低回采幅度忽大忽小怎么判定都不对。建议初始化后立即写寄存器关闭ALC并回读确认。4.3 音调不对采样率配置的蝴蝶效应“发闷”或“发尖”通常是实际采样率比预期低或高。比如STM32F407上PLLI2S分频参数算错实际采样率偏了5%耳朵不一定马上听出来但频率分析一算就露馅。语音测试例程的优势就在这里输出一个1kHz正弦波回采后看峰值落在哪个频点差多少一目了然。4.4 不同主控上的特殊坑TMS320F28388D这类双核芯片语音例程建议固定在某一个核上跑另一个核干控制逻辑两边共享外设要加访问保护不然音频中断被另一核的长任务拖住音频流就断了。GD32的I2S时钟树和STM32不是完全一样直接用STM32例程的PLL参数会出错必须对着数据手册重新算。再补两个思路相通的例子IIS3DWBTR这类传感器例程本质也是“激励—采集—比对”的回环验证和语音回环测试完全同构HUSB238这类走IIC通信的器件调试时最大的教训是不要在音频DMA中断里做IIC长阻塞操作IIC时序会被音频中断打断。这些例程的共同点都是要有清晰的激励构造和明确的判定标准。5. 把例程推向产线自动化判定与数据上报实验室能跑的例程和产线能用的工具差着很多东西。产线要求简单、快、可重复。5.1 一键测试与工装设计我把状态机里的测试项按固定顺序编排成“一键测试”流程上位机下发启动命令例程自动跑完通路、回环、频响三项结果通过LED和串口双重提示。操作员不需要懂技术只看PASS/FAIL就行。工装设计上要注意声学隔离测试环境的背景噪声至少要低于被测指标10dB否则底噪项永远测不过。产线高速运转时的背景噪声比想象中大这块提前规划能省不少返工。5.2 结果数据结构化测试结果建议统一成可解析的ASCII帧或JSON格式里带上板号、固件版本、测试时间、各指标数值、判定结论。这样后续做批次统计、客诉追溯都很方便。我习惯在固件里直接留一个最近一次测试结果的全局结构体上位机随时可以拉取。5.3 LabVIEW TCP上位机联调的经验LabVIEW做产线测试上位机很常见它的TCP通信例程通常比较简洁但实际联调有几个点容易踩。一是读操作要加超时控制MCU如果没来得及回数据LabVIEW默认会一直等下去二是前面提过的粘包/拆包必须按帧结构解析不能按固定字节数硬读三是多工位同时测试时每台MCU要用不同的TCP端口不然就串了。还有一点要提醒产线网络环境往往不稳定测试指令下发后MCU侧要做命令重复和CRC校验上位机侧要做失败重试两边都别想当然认为每条指令都能一次送达。最后说点个人体会。语音测试例程写代码的工作量其实不大真正花钱花时间的是定阈值、做工装、和产线反复磨合。我最早一版例程只用了两天就写完但阈值标定和误报处理断断续续调了两周。别想着一步到位先让例程能跑、能打印关键数据再慢慢把判定逻辑和自动化工序加进去。这条路走下来最稳后续换平台、加测试项也都只是在现有框架上做增量不用推倒重来。本文还有配套的精品资源点击获取