嵌入式语音处理实战：从G.726/G.729编解码到V.22bis调制解调器系统集成-编程实验室

1. 项目概述与核心价值

如果你正在寻找一份关于如何在真实的嵌入式硬件上，从零开始搭建一个完整的语音处理系统的实战指南，那么你来对地方了。这篇文章将带你深入Motorola（现NXP）DSP5685x平台，亲手实践G.726、G.729等经典语音编解码算法，并完成V.22bis调制解调器的互操作性测试。这不仅仅是阅读一份古董芯片的文档，而是一次穿越到21世纪初嵌入式语音通信开发一线的沉浸式体验。DSP5685x系列虽然已是上一代的产品，但其架构清晰、外设典型，所涉及的语音编解码、调制解调原理以及嵌入式系统集成方法，至今仍是许多现代音频处理芯片和通信模块的基础。通过这个项目，你不仅能理解算法如何在硬件上跑起来，更能掌握一套从硬件连接到软件调试、从算法验证到系统集成的完整方法论，这对于从事任何嵌入式音频、语音或通信相关开发都极具价值。

整个实践的核心在于“打通”：打通PC与DSP评估板的物理连接，打通开发环境与目标板的调试通道，最终让算法在真实的音频流中运行起来，听到实实在在的效果。我们将使用经典的CodeWarrior IDE、并行口和串口调试器，这些工具在今天看来或许有些古老，但正是这种“原始”的环境，能让你抛开现代集成开发环境的便利性，更深刻地理解底层硬件是如何被驱动、数据是如何流动的。项目涉及的关键技术点包括自适应差分脉冲编码调制（ADPCM）、共轭结构代数码激励线性预测（CS-ACELP，即G.729的核心）、以及用于低速数据通信的V.22bis调制解调标准。接下来，我将为你拆解每一个环节，补全官方文档中省略的“为什么”和“怎么办”，分享我当年调试这些板卡时积累的一手经验和避坑指南。

2. 开发环境搭建与硬件连接详解

在开始敲代码之前，把硬件和软件环境搭建妥当是成功的一半。这一步的琐碎程度往往超乎想象，一个跳线设置错误或驱动问题就可能导致整个下午的调试徒劳无功。

2.1 硬件平台深度解析：DSP56858 EVM

我们使用的核心硬件是DSP56858评估模块（EVM）。这块板子可以看作是一个微型的语音处理系统原型。它的核心是一颗DSP56858芯片，这是一款16位定点数字信号处理器，主频在当时看来相当不错，足以实时处理多个语音通道的编解码。板上集成了模拟编解码器（Codec）、同步串行接口（ESSI）、异步串行接口（SCI）、并行主机接口（HI）以及丰富的GPIO和定时器。

几个关键硬件模块的实战意义：

并行接口（Parallel Port）：这是连接PC与EVM进行调试和程序下载的生命线。在USB-JTAG调试器普及之前，并口是主要的调试接口。你需要一根DB25针的并口线，确保PC主板上有并口（很多现代主板已取消，可能需要PCIe转并口卡）。
串行接口（Serial Port / COM Port）：用于数据通信测试，例如在V.22bis调制解调器Demo中，它连接PC的超级终端（HyperTerminal），模拟数据终端设备（DTE）。同样，你需要一根DB9针的串口线或USB转串口线。
音频接口（Line In/Line Out, Mic In）：这是语音信号的物理入口和出口。板载的Codec负责将麦克风或线路输入的模拟信号转换为DSP可以处理的数字信号（ADC），以及将DSP处理后的数字信号还原为模拟信号输出到耳机或扬声器（DAC）。
采样率拨码开关（S5）：这是一个非常关键的硬件配置点。文档要求将S5的三个开关全部拨到“Off”位置，以设置编解码器产生8000Hz的采样率。这里有个细节：8000Hz是电话语音的标准采样率（Nyquist频率为4kHz，覆盖300-3400Hz的电话语音带宽）。如果这个开关设置错误，会导致采样率不匹配，播放出来的声音要么失真严重，要么直接是噪音。

实操心得：硬件连接检查清单在通电前，务必按照以下顺序检查，可以节省大量排查时间：
电源：确认EVM的电源适配器规格正确（通常是+5V），极性无误，测量供电电压是否稳定。
跳线：对照《DSP56858 Evaluation Module User’s Manual》中的默认设置图，逐一核对所有跳线帽（Jumper）的位置。特别是为编解码器、时钟和IO口供电的跳线。
采样率开关：确认S5的三个开关全部处于“OFF”状态。我遇到过因为开关接触不良导致采样率飘忽不定的情况，可以用万用表通断档确认一下。
连接线：并口线、串口线是否完好？音频线是否分清了左右声道和地线？对于Modem Mate这类转换设备，确保其工作模式开关（如Voice/Data）拨到了正确位置。

2.2 软件开发环境：CodeWarrior与SDK配置

软件开发基于Metrowerks CodeWarrior for DSP56800E系列。这是一个经典的集成开发环境，包含编译器、汇编器、链接器和调试器。

环境搭建步骤与深层逻辑：

安装与注册：先安装CodeWarrior，然后务必完成注册（输入License Key）。未注册版本通常有代码大小限制，可能无法编译完整的演示工程。
安装嵌入式SDK：Motorola/NXP为DSP5685x提供了专用的软件开发套件（SDK）。这个SDK是宝藏，里面不仅有所需的库文件（如G.726.lib, G.729.lib, V22bis.lib），还有所有演示项目的源代码和底层驱动程序（BSP）。安装时，建议选择默认路径，避免后续工程中复杂的路径设置问题。
工程导入与路径设置：以G.726演示为例，打开工程文件...\nos\applications\telephony\g726\demo_g726.mcp。首次打开时，IDE可能会提示找不到某些头文件或库。这时需要检查：
- “Access Paths”：在工程设置中，确保包含了SDK安装目录下的include文件夹路径。
- “Library Paths”：确保链接器能搜索到SDK的lib文件夹。
- “Target Settings”：确认目标处理器（Target）正确设置为DSP56858，调试接口选择“Parallel Port”或对应的HDI接口。

一个关键技巧：理解“Build”与“Download”在CodeWarrior中，点击“Build”只是将你的C/汇编代码编译链接成可在DSP上运行的机器码文件（通常是.abs或.elf格式）。而“Download”才是通过并口调试器将这个文件烧写到EVM板的内存中。DSP56858没有内置Flash，所以程序是下载到外部SRAM中运行的，断电即丢失。这意味着每次板卡重启，都需要重新下载程序。调试时，程序会在main()函数入口处自动设置断点并暂停，此时你需要点击“Run”或“Go”来让程序真正开始执行。这个“Build -> Download -> Run”的流程是嵌入式调试的日常。

3. 核心语音编解码算法实践

硬件和软件环境就绪后，我们进入核心环节：让不同的语音编解码算法在DSP上跑起来，并亲耳听到效果对比。

3.1 G.726 ADPCM编解码演示

G.726是ITU-T定义的ADPCM语音编码标准，速率可在16、24、32、40 kbit/s之间选择。它的核心思想是利用语音信号样本间的相关性，只对预测误差进行自适应量化编码，从而用较低的比特率获得接近PCM（64 kbit/s）的语音质量。

3.1.1 硬件连接与设置深析

演示设置要求将PC的音频输出（Audio Out）连接到EVM板的线路输入（Line In），再将EVM的线路输出（Line Out）连接到有源音箱的输入（Speaker In）。这构成了一个简单的“PC播放 -> DSP处理 -> 音箱播放”的实时环路。

为什么用PC Audio Out作为音源？因为它提供了稳定、可控且内容已知的测试信号。你可以使用音频编辑软件（如早期的Cool Edit或Audacity）生成特定频率的正弦波、白噪音或录制好的语音片段，用于客观测试算法性能。
跳线S5全部置“Off”的意义：这配置了板载Codec的采样时钟为8 kHz。ADPCM算法本身对采样率有要求，必须与标准电话速率一致，否则内部的自适应预测器步长调整会错乱，导致编码解码完全失败。

3.1.2 操作流程与现象观察

按照文档步骤构建并下载demo_g726.mcp工程后运行。此时，DSP程序处于一个等待状态，实时地对Line In输入的音频进行G.726编码（压缩）和解码（还原），然后从Line Out输出。

关键操作与现象：

从PC播放一段音乐或语音。
你应该能立即从音箱中听到处理后的声音。重点来了：文档提到“随着速率从40降低到16 kbit/s，噪声水平会增加”。你如何验证这一点？
手动测试方法：G.726演示工程通常默认运行在某个速率（比如32 kbit/s）。要切换速率，你需要查阅源代码。在demo_g726.c或相关配置文件中，很可能会找到一个用于设置速率的参数或变量，例如bitRate = RATE_16K或RATE_40K。修改这个参数，重新编译、下载、运行，然后对比听感。
主观听感对比：
- 40 kbit/s：音质非常接近原始线性PCM，几乎听不出损伤，背景干净。
- 32 kbit/s：最常用的速率，音质良好，轻微可闻的量化噪声，类似轻微的“嘶嘶声”，但语音清晰度不受影响。
- 24 kbit/s：噪声变得明显，声音开始有点“空洞感”或“金属感”，这是低比特率下自适应量化步长调整跟不上信号变化导致的。
- 16 kbit/s：噪声显著，语音清晰度下降，可能出现个别音节模糊，但在可懂度要求不高的场景下仍可使用。

注意事项：电平匹配问题这是音频处理实验中最常见的坑。如果从音箱听到的声音非常小、失真严重或者有爆音，问题很可能出在电平上。
PC输出电平：确保PC的音量控制不是静音，且输出电平适中（通常50%-70%）。
EVM板输入电平：Line In接口通常期望的是“线路电平”（约0.5-1Vrms），比麦克风电平高很多。如果输入信号太弱，会被淹没在Codec的底噪中；如果太强，会导致ADC削波（Clipping），产生严重失真。如果PC输出音量已调至中等仍不理想，可以考虑在PC和EVM之间增加一个简单的无源衰减器（例如两个电阻分压）。
音箱输入灵敏度：同样，确保音箱的输入增益旋钮位置合适。

3.2 G.729与G.711语音编解码器对比演示

这个演示比G.726更进了一步，它包含了“录音-编码-存储-解码-回放”的完整流程，并且可以对比三种编码格式：Motorola PCM、G.711（即标准的PCM μ-law/A-law）和G.729AB。

3.2.1 录音回放演示（Recorder Player Demo）原理拆解

这个演示的流程堪称经典，完美展示了嵌入式语音处理系统的数据流：

采集：通过连接到EVM Line In的麦克风采集模拟语音。
数字化：板载Codec以8 kHz采样率、16位（或8位）精度进行ADC。
编码：DSP运行G.729AB或G.711算法，将数字音频流压缩成低速率的比特流。
传输与存储：编码后的数据通过串口（COM Port）发送到PC。PC上运行着一个服务端程序serial_mix.exe，它接收数据并可能存储为文件。这一步模拟了语音数据在信道中传输或网络封包的过程。
回传与解码：PC将存储的编码数据再通过串口发回给DSP。
解码与播放：DSP运行对应的解码算法，将比特流还原为数字音频，通过Codec的DAC转换为模拟信号，从Line Out输出到耳机或音箱。

硬件连接上有一个关键点：除了并口（调试）和串口（数据）外，麦克风需要连接到EVM的Line In。注意，文档提到的是“amplified microphone”，即必须使用有源麦克风或通过话放。因为EVM的Line In接口设计为接收线路电平，麦克风微弱的信号直接接入是无法被有效采集的。

3.2.2 操作流程与交互

启动PC端服务器：先运行serial_mix.exe，并正确选择EVM连接的COM口（如COM1）。这个程序充当了数据记录和回放的中继站。
构建与下载DSP程序：打开recorder_player.mcp，下载并运行。
控制台交互：程序运行后，在CodeWarrior的调试器控制台（Console）或serial_mix.exe的界面上，会出现一个菜单：
```
Motorola DSP5685x G.729ab and G.711 Vocoders demo Options ------- [1] PCM (8bit) *[2] G711 [3] G729AB [6] Quit
```
录音与回放：根据提示，按下EVM板上的IRQA按钮开始录音（对着麦克风说话），按下IRQB按钮开始回放。你会先后听到G.711和G.729AB解码后的声音。
听感对比：
- G.711 (64 kbit/s)：这是传统的对数PCM，音质很好，但数据量最大。听起来饱满、自然。
- G.729AB (8 kbit/s)：这是CS-ACELP算法，压缩率极高（8:1）。仔细听，你会发现在保持高语音清晰度的同时，声音会略带一点“机械感”或“嗡嗡声”，背景噪声的处理方式也与G.711不同。这是低码率编码器为了节省比特，对语音模型进行强假设和参数化所带来的典型音色特征。

3.2.3 循环回放演示（Loopback Demo）的差异

loopback_vocoders演示更直接，它去掉了PC存储环节，形成了一个纯粹的硬件实时环路：麦克风 -> Codec ADC -> DSP编码 -> DSP解码 -> Codec DAC -> 扬声器。你可以通过按IRQA按钮在PCM、G.711、G.726 (16k/40k)、G.729AB等不同编码器间循环切换，实时对比同一段语音在不同编码下的效果。LED灯的闪烁用于指示当前选择的编码器。这个演示对于快速建立对不同算法音质的直观感受非常有效。

4. 调制解调器（Modem）技术实践：V.22bis

如果说语音编解码处理的是“声音”，那么调制解调器处理的就是“数据”。V.22bis是一个经典的2400 bps全双工调制解调器标准，常用于早期的电话线数据通信。在DSP上实现它，意味着用软件算法（软Modem）完成了传统上需要专用芯片（硬Modem）的功能。

4.1 系统架构与硬件连接的特殊性

V.22bis演示的核心目标是实现DSP软Modem与一个物理标准Modem（如Motorola Premier 33.6k modem）之间的互操作性测试。这就引入了复杂的硬件连接。

关键设备：Modem Mate这是一个核心的接口转换设备。因为EVM板只有标准的音频Line In/Out接口（模拟信号），而电话线是两线制、带有直流馈电和铃流的高电压复杂信号环境，不能直接连接。Modem Mate的作用相当于一个“电话线模拟前端”：

功能：它将EVM的音频信号耦合到电话线上，并提供必要的隔离、阻抗匹配和2线到4线的转换（实现全双工）。
连接：
1. EVM的Line Out-> Modem Mate的Play(发送音频到电话线)。
2. EVM的Line In<- Modem Mate的Record(从电话线接收音频)。
3. 电话机的听筒手柄线（Handset Cable）连接到Modem Mate的HANDSET口。这一步至关重要，它让Modem Mate可以模拟摘机/挂机状态，并捕获电话线上的双音多频（DTMF）拨号音等信令。
4. Modem Mate自身的线缆再连接到电话线插座。

系统构成：整个演示需要两套系统。系统A：PC + DSP EVM + Modem Mate + 电话线A。系统B：另一台PC + 标准硬件Modem + 电话线B。两条电话线通过PSTN（公共电话交换网）或直接背靠背连接。

4.2 详细操作流程：以应答模式（Answering Modem）2400bps为例

我们以DSP作为被叫方（Answering Modem），标准Modem作为主叫方（Calling Modem）为例，详解流程。

4.2.1 DSP端（应答方）配置

加载工程：打开interopans.mcp工程，编译下载。此时电话（连接EVM）应处于挂机（on-hook）状态。
配置超级终端（HyperTerminal）：
- 新建连接，选择与EVM串口相连的COM口（如COM1）。
- 端口设置：这是最容易出错的地方。必须设置为115200 bps, 8数据位, 1停止位, 无校验, 流控制为“无”。115200是DSP与PC调试终端之间的通信速率，与Modem的2400bps无关。
- ASCII设置：勾选“以换行符作为发送行末尾”、“本地回显键入的字符”、“将换行符附加到传入行末尾”等。这确保了键盘输入的字符能被正确发送和显示。

4.2.2 标准Modem端（主叫方）配置

硬件连接：将标准Modem通过串口线连接到另一台PC。
配置超级终端：新建连接，选择Modem所在的COM口。
- 端口设置：2400 bps, 8数据位, 1停止位, 无校验, 流控制为“硬件”。此处的2400bps是与Modem通信的DTE速率。
配置Modem参数（通过AT命令）：
- 在超级终端中输入AT，应返回OK，确认Modem响应正常。
- 禁用V.42错误纠正协议：输入AT&N0。V.42是更高级的纠错协议，而我们的DSP V.22bis库只实现了V.14（异步同步转换），所以必须禁用V.42，强制使用V.14。
- 启用V.22bis 2400bps模式：
  - 对于Motorola Premier Modem:AT%L3&B3
  - 对于Psion Dacom Modem:AT+MS=2,0,2400,2400,0,0,2400
  - 这些命令设置了调制方式、波特率等参数。

4.2.3 建立连接与数据通信

拨号：在标准Modem的超级终端中，输入ATDT<电话号码>，其中<电话号码>是连接EVM的电话线的号码。
应答：听到连接EVM的电话振铃后，立即摘机（拿起听筒），然后迅速在CodeWarrior中点击“Run”启动DSP上的V.22bis应答程序。时机很重要，摘机和启动程序的动作要连贯。
协商：如果一切正常，你会听到一阵熟悉的Modem握手音（那种“叽叽喳喳”的声音），然后双方超级终端上可能会显示CONNECT 2400之类的消息。
全双工通信：此时，在两个超级终端窗口中键入字符，应该能在对方终端上实时显示出来，实现一个简单的聊天功能。这证明了DSP的软Modem成功与硬件Modem建立了链路层连接，并完成了数据调制解调。

4.3 常见问题与深度排查

这个环节极易失败，以下是几个关键排查点：

握手失败，无CONNECT消息：
- 检查Modem Mate模式：确保Modem Mate的开关拨到了“Voice”模式，而不是“Data”或其他模式。在Voice模式下，它才能正确处理模拟音频信号。
- 检查电话线噪音：文档中提到了一个非常实用的技巧：用胶带轻轻盖住电话听筒的麦克风和受话器。因为当电话摘机后，听筒的麦克风和扬声器是声学开放的，很容易产生啸叫或环境噪音，这些噪音会叠加到Modem信号上，导致误码率（BER）升高甚至握手失败。用胶带覆盖可以物理隔离，显著改善线路质量。
- 确认AT命令：仔细核对输入的标准Modem AT命令，确保没有拼写错误，并且Modem确实用OK响应了每条命令。
- 时序问题：确保在电话摘机后立即启动DSP程序。延迟过长可能导致标准Modem端超时。
连接建立后，字符传输乱码或丢失：
- 流控制：确认DSP端的超级终端流控制为“无”，而标准Modem端为“硬件”。流控制不匹配会导致数据缓冲区溢出。
- 速率匹配：再次确认DSP端超级终端是115200bps（与DSP的UART驱动配置匹配），标准Modem端是2400bps（与V.22bis链路速率匹配）。
- 线路质量：电话线路质量差、有干扰会导致误码。可以尝试在安静的环境下，使用较短的、直接相连的电话线进行测试。
DSP程序无法下载或运行：
- 回归基础检查：并口线是否接好？EVM板供电是否正常？CodeWarrior中的目标板设置是否正确？
- 查看调试器输出：CodeWarrior的调试器控制台是否有错误信息？程序是否真的运行到了main()函数？

通过完成V.22bis的互操作性测试，你不仅验证了一个通信算法，更完成了一次完整的、涉及两端硬件、多层协议（物理层、链路层）和精确时序控制的系统集成实验。这种经验对于理解任何通信系统都至关重要。

5. 高级语音处理功能演示

除了核心编解码，DSP5685x SDK还提供了更高级的语音处理功能库，展示了DSP在实时音频增强方面的能力。

5.1 噪声抑制（Noise Suppression, NS）演示

噪声抑制算法旨在从带噪语音信号中尽可能去除背景噪声，提升语音清晰度和可懂度。这个演示非常直观地展示了算法的效果。

5.1.1 演示设置与操作

硬件连接与G.726演示类似：PC播放带噪的音频文件（SDK的inputs目录下提供了此类文件）到EVM的Line In，EVM处理后再从Line Out输出到音箱。

构建运行：打开demo_ns.mcp，下载运行。
功能控制：程序启动时，噪声抑制功能默认是关闭的。此时你听到的是原始的、带有噪声的音频。
实时切换：按下EVM板上的IRQA按钮，绿色LED会点亮，表示噪声抑制功能开启。你应该能立刻听到背景噪声（如稳定的嘶嘶声、风扇声等）被显著削弱，而语音部分被相对保留。再次按下IRQA，LED熄灭，功能关闭，噪声恢复。

5.1.2 算法原理浅析与效果评估

虽然SDK未公开NS库的具体算法，但基于当时的典型技术，很可能是基于谱减法（Spectral Subtraction）或其变种。

基本原理：假设噪声是平稳或缓慢变化的，算法首先估计出非语音段（静默段）的噪声频谱，然后在语音段，从带噪语音的频谱中减去估计的噪声频谱，得到“干净”语音频谱，再通过逆傅里叶变换恢复时域信号。
主观听感：对于平稳噪声（如白噪声、空调声），抑制效果通常非常明显。但对于非平稳噪声（如突然的键盘声、他人谈话声），效果会打折扣，甚至可能引入“音乐噪声”（一种残留的、类似音乐的颤音失真），这是谱减法类算法的固有缺陷。
实践意义：这个演示让你亲身体验了实时音频处理算法的威力。在车载免提、视频会议等场景中，这类算法是提升用户体验的关键。

5.2 语音活动检测（Voice Activity Detection, VAD）演示

VAD用于区分输入信号中的语音段和静默段（或噪声段）。在语音编码、录音或通信系统中，它用于实现静默抑制，即在静默段停止发送数据或进行低比特率编码，从而节省带宽和功耗。

5.2.1 基于文件I/O的测试模式

这个演示采用了“文件I/O”模式，而非实时音频流。这是一种更利于算法验证和调试的模式。

流程：DSP从PC通过串口接收一个预录好的语音数据文件（speech.in），运行VAD算法进行处理，将检测出的纯语音帧（去掉静默段）拼接起来，形成新的文件（conc_spch.out），再通过串口发回PC。
工具链：需要使用PC上的fileio.exe程序作为文件传输服务器，并配置正确的COM口和波特率（56000 bps）。
结果验证：PC端使用提供的Conv2au.exe工具将原始文件speech.au和处理后的文件conc_spch.au转换为可播放的格式。通过对比播放，你可以清晰地听到，处理后的文件中的静默停顿被移除了，语音片段被紧密地拼接在一起。

5.2.2 VAD的技术要点

VAD算法通常基于一系列声学特征进行决策，如短时能量、过零率、频谱特征等。一个健壮的VAD需要在各种背景噪声下都能准确检测，避免将噪声误判为语音（假阳性）或将弱语音误判为静默（假阴性）。这个演示提供了一个客观评估VAD性能的基础框架。

6. 语音识别（VRLite-1）入门实践

VRLite-1演示将项目推向了一个更智能的层面：让DSP能够识别特定的语音命令。这是一个典型的孤立词、小词汇量、说话人相关的语音识别系统。

6.1 系统工作流程与状态机

演示系统遵循一个清晰的三状态机模型：

训练状态（Training）：用户依次对系统说出预设的词汇（如“Answer”, “Call”, “Home”等），每个词需要清晰地说两遍。DSP会提取语音特征，为每个词生成一个参考模型（模板），并存储在内存中。重要提示：对于“Dial Operator”这类复合词，中间只能有轻微停顿，不能说成两个独立的词。
识别状态（Recognition）：训练完成后，系统进入识别状态。用户说出任意一个已训练的词汇，DSP会计算输入语音的特征与所有存储模型的匹配度，并返回最匹配的那个词。
退出状态（Exit）：当用户说出“Stop Demo”时，系统退出。

6.2 两个演示变体的区别

demo_vrlite1：基础识别演示。识别出词汇后，仅在CodeWarrior控制台上显示该词汇的文本。
demo_dial_vrlite1：集成拨号功能的演示。这是更贴近实际应用的场景。你需要修改源代码dial_vrlite1.c中的两个数组：
- RecWords[][]：将你想要训练的词汇字符串填入。
- TelNumbers[][]：填入与RecWords中词汇一一对应的电话号码。
- 例如：RecWords[0] = "DIAL HOME";对应TelNumbers[0] = "5551234";。当识别出“DIAL HOME”后，DSP会通过Modem Mate和相连的电话机，自动拨打5551234这个号码。

6.3 硬件连接的复杂性

demo_dial_vrlite1的硬件连接是本文所有演示中最复杂的，它集成了语音识别、DTMF拨号和电话线接口。

音频输入通路：麦克风 -> PC Mic In -> PC Audio Out -> 音箱（作为放大器）-> EVM Line In。这里用PC和音箱作为音频放大链，是因为EVM的Line In需要线路电平，而普通麦克风输出信号太弱。
电话控制通路：EVM Line Out -> Modem Mate Play -> 电话线。识别出命令后，DSP会生成对应的DTMF双音多频信号，通过这条通路发送到电话线上，实现自动拨号。
注意事项：文档特别警告，音箱（放大器）的音量要调节到一半左右。音量太小，语音信号太弱，识别率低；音量太大，可能使输入EVM的信号过载失真，同样影响识别，甚至损坏Codec输入电路。

6.4 实践限制与优化思路

内存易失性：DSP56858没有非易失性存储器（如Flash），训练好的模型存储在外部RAM中，断电即丢失。这意味着每次上电都需要重新训练。在实际产品中，需要将模型存储在外置的EEPROM或Flash中。
环境要求：训练和识别时，需要相对安静的环境。背景噪声会严重影响特征提取的准确性。
词汇量限制：演示默认支持约20个词，受限于RAM大小。增加词汇量需要优化模型存储结构或扩展内存。
说话人相关：VRLite-1是说话人相关的系统，即由谁训练，就最好由谁来使用，识别率最高。换一个人使用，识别率可能会下降。

通过这个演示，你能够建立起对嵌入式语音识别系统最基本的构成、工作流程和挑战的直观认识。虽然VRLite-1的性能无法与当今基于深度学习的方案相比，但其核心流程——前端处理、特征提取、模板匹配——仍然是现代语音识别系统的基石。