语音交互系统。

说实话，我做了这么多年音频系统，语音交互这块是最让我头疼，也最有成就感的。你想想看，用户坐进车里，第一句话可能就是“你好，小X”，如果这个唤醒没反应，或者识别错了，那体验直接归零。我早期参与的一个项目，就因为唤醒词在高速风噪下频频误触发，被用户骂惨了。嗯，从那以后，我对语音交互的每一个环节都格外较真。

今天这一章，我们就把语音交互的四个核心模块拆开揉碎：唤醒词检测、语音识别（ASR）、语音合成（TTS）、音频焦点管理。这四个东西，说白了就是“听到你、听懂你、回答你、不打架”。

核心观点：语音交互不是简单的“录音+播放”，而是一个多模块协同的实时系统。任何一个环节的延迟或冲突，都会让用户觉得“这车是不是傻”。

语音交互系统核心流程唤醒词检测语音识别(ASR)语义理解(NLP)语音合成(TTS)音频焦点管理（仲裁层）扬声器 / 耳机输出图：语音交互系统核心流程与音频焦点管理的关系

12.1 唤醒词检测：第一道门

唤醒词检测，就是让车机一直“竖着耳朵”听，但只在听到特定词时才激活。这玩意儿功耗要求极高，因为麦克风得一直开着。

我在项目中用过两种方案：

• 传统DSP方案： 用低功耗DSP跑一个轻量级神经网络，只检测唤醒词。优点是省电，缺点是模型能力有限，容易误唤醒。
• 高通SNPE方案： 利用Hexagon DSP的HVX（Hexagon Vector eXtensions）加速。我建议你用这个，因为高通平台对SNPE有原生支持，性能好很多。

我的经验： 唤醒词模型不要太大，一般50KB以内就够了。我曾经试过用200KB的模型，结果在8155平台上唤醒延迟增加了300ms，用户反馈“喊了没反应”。后来换成40KB的轻量模型，延迟降到150ms，体验好很多。

代码示例：高通平台唤醒词初始化（伪代码）

// 唤醒词引擎初始化
WakeWordEngine *engine = wake_word_engine_create();
engine->set_model("hotword_40kb.bin");
engine->set_threshold(0.85f);  // 阈值调低容易误触发，调高容易漏唤醒
engine->set_sensitivity(0.7f); // 灵敏度，根据车内噪声动态调整
engine->start_listening();

12.2 语音识别（ASR）：听懂你在说什么

唤醒之后，ASR就开始工作了。ASR的核心是把音频流转换成文字。这里有个关键点：ASR是计算密集型任务，对CPU和内存消耗很大。

我建议你在座舱里采用端云结合的方式：

• 本地ASR： 处理简单指令，比如“打开空调”、“下一首”。延迟低，不依赖网络。
• 云端ASR： 处理复杂语义，比如“帮我找一家附近的川菜馆”。准确率高，但有网络延迟。

对比项	本地ASR	云端ASR
延迟	<200ms	500ms-2s
准确率	85%-90%	95%+
网络依赖	不依赖	必须联网
典型场景	车辆控制	导航、信息查询

注意： 本地ASR的模型要定期OTA更新。我曾经遇到一个项目，出厂时的本地ASR模型对“导航到公司”识别率很高，但一年后用户换了新公司地址，模型没更新，识别率直接掉到60%。所以，模型更新机制一定要设计好。

12.3 语音合成（TTS）：让车机开口说话

TTS就是把文字变成语音。现在座舱里流行的是神经网络TTS，声音自然，不像以前那种机器人腔调。

高通平台上有Qualcomm Neural Processing SDK，可以直接跑TTS模型。我个人习惯用WaveNet的变体，音质好，但计算量大。如果你对延迟敏感，可以考虑Tacotron 2 + LPCNet的组合，延迟能控制在100ms以内。

代码示例：TTS播放流程

// TTS引擎调用
TTS_Engine *tts = tts_engine_create();
tts->set_voice("zh-CN-XiaoxiaoNeural");  // 设置语音角色
tts->set_speed(1.0f);                    // 语速
tts->set_pitch(1.0f);                    // 音调
tts->synthesize_to_file("前方500米右转", "output.wav");
// 然后通过音频焦点管理播放 output.wav

避坑指南： 我曾经在TTS播放时没处理好音频焦点，结果导航语音和音乐同时播放，两个声音混在一起，用户根本听不清。后来我强制TTS播放时音乐音量降到20%，问题才解决。

12.4 音频焦点管理：别让声音打架

音频焦点管理，说白了就是谁有资格出声。座舱里声音来源太多了：导航、音乐、电话、语音助手、警告音……如果没个仲裁机制，那车里就是菜市场。

我建议你参考Android的音频焦点机制，但要做一些定制：

• 焦点请求： 每个音频流在播放前必须申请焦点。
• 焦点类型： 分为“独占焦点”（比如电话）、“短暂焦点”（比如导航提示）、“混合焦点”（比如音乐和导航同时播放，但导航优先）。
• 焦点回调： 当高优先级音频流申请焦点时，低优先级流要自动暂停或降低音量。

举个例子：

// 音频焦点管理示例
AudioFocusManager *manager = audio_focus_manager_create();

// 导航申请短暂焦点
AudioFocusRequest *nav_request = audio_focus_request_create();
nav_request->set_type(FOCUS_TYPE_TRANSIENT);
nav_request->set_callback(on_focus_gain);
manager->request_focus(nav_request);

// 音乐收到焦点丢失回调，自动降低音量
void on_focus_loss(AudioFocusManager *manager, void *user_data) {
    music_player->set_volume(0.2f);  // 降到20%
}

关键设计原则： 音频焦点管理一定要有超时机制。如果某个音频流申请了焦点但一直不释放，系统要能强制回收。我见过一个bug，语音助手播报完忘了释放焦点，结果导航一直不出声，用户开了半小时才发现。

12.5 高通平台实战要点

在高通8155/8295平台上，语音交互系统有几个硬件加速点：

• ADSP（音频DSP）： 专门处理唤醒词和低功耗音频。我建议你把唤醒词模型直接部署在ADSP上，这样主CPU可以休眠，省电。
• HVX（Hexagon Vector eXtensions）： 加速ASR和TTS的神经网络推理。高通SDK里已经封装好了，直接调用就行。
• SLPI（Sensor Low Power Island）： 用于麦克风阵列的预处理，比如波束成形、降噪。

最后说一句：语音交互系统好不好用，不是看功能多不多，而是看稳不稳定、快不快。用户喊一声“导航到公司”，如果3秒后才反应过来，那这车机就是垃圾。所以，从唤醒到TTS播放，整个链路的延迟一定要控制在1.5秒以内，这是底线。

我的习惯： 每次集成完语音交互系统，我都会在车里模拟各种场景测试：高速风噪、开窗、音乐音量最大、多人同时说话……只有这些场景都通过了，我才敢说这个系统“能用”。