第三章：语音唤醒机制
语音唤醒，说白了就是让车机一直竖着耳朵听你叫它。你喊一声“你好，小驰”，它就得醒过来。这个功能看着简单，但要做好，坑不少。
我个人习惯把唤醒机制拆成三块来讲：关键词检测的原理、低功耗怎么实现、以及怎么集成自定义唤醒词。咱们一个一个来。
3.1 关键词检测原理
关键词检测，英文叫Keyword Spotting，简称KWS。它跟语音识别不一样。语音识别是把你说的话全转成文字，而KWS只关心那几个特定的词。
为什么这么做？因为省资源。你想想看，车机不可能一直开着完整的语音识别引擎，那功耗和算力都扛不住。KWS只需要一个轻量级的模型，在后台跑着就行。
核心流程：
- 音频采集：麦克风阵列持续采集环境声音。
- 预处理：降噪、回声消除、VAD（语音活动检测）。
- 特征提取：把音频信号转成MFCC（梅尔频率倒谱系数）或Fbank特征。
- 模型推理：用DNN/CNN/RNN模型判断是否包含唤醒词。
- 后处理：置信度打分、阈值判断、防误触发。
我在项目中遇到过一个问题：模型在安静环境下表现很好，但一上路，风噪、胎噪、音乐声全来了，误唤醒率飙升。后来怎么解决的？我们在预处理阶段加了自适应噪声抑制，并且把VAD的灵敏度调低了一些。
3.2 低功耗唤醒实现
低功耗唤醒，这是车载场景的刚需。车停着的时候，你不能让整个系统都跑着，那电瓶受不了。但你又得保证用户一喊就能醒。
嗯，这里要注意，低功耗唤醒通常分两级：
| 级别 | 硬件平台 | 功耗 | 唤醒延迟 |
|---|---|---|---|
| 一级唤醒 | MCU或DSP | < 10mW | < 200ms |
| 二级唤醒 | AP（应用处理器） | 几百mW | < 50ms |
一级唤醒，说白了就是用一个超低功耗的芯片（比如Cortex-M4或者专用的NPU）来跑一个极简的KWS模型。它只做一件事：判断有没有人喊唤醒词。一旦检测到，就发一个中断信号给主芯片，把整个系统叫起来。
二级唤醒，就是主芯片起来之后，再用更精准的模型做二次确认。这样可以防止误唤醒。
我的经验：一级唤醒的模型不要太大，参数控制在100K以内，特征维度用13维MFCC就够了。我曾经试过用40维Fbank，结果功耗直接翻倍，得不偿失。
另外，低功耗唤醒还有一个关键点：音频通路的设计。麦克风的数据要能直接绕过主芯片，送到MCU或者DSP。这需要硬件上支持，比如用I2S或者PDM接口直连。
3.3 自定义唤醒词集成
自定义唤醒词，就是让用户自己定义唤醒词，比如“嘿，小蓝”、“你好，大白”。这个功能在Android Automotive上怎么集成？
我建议分三步走：
- 训练阶段：用户录制几遍唤醒词，上传到云端或者本地训练一个模型。
- 部署阶段：把训练好的模型文件（通常是.tflite或者.pb格式）放到指定目录。
- 加载阶段：KWS引擎动态加载模型，替换默认的唤醒词模型。
代码示例，Android Automotive上怎么动态加载唤醒词模型：
// 自定义唤醒词模型加载
public class CustomWakeWordManager {
private static final String MODEL_PATH = "/data/local/tmp/wakeword_model.tflite";
private Interpreter tfliteInterpreter;
public boolean loadCustomModel(String modelPath) {
try {
File modelFile = new File(modelPath);
if (!modelFile.exists()) {
Log.e("WakeWord", "模型文件不存在: " + modelPath);
return false;
}
MappedByteBuffer modelBuffer = FileUtil.loadModelFile(modelPath);
tfliteInterpreter = new Interpreter(modelBuffer);
Log.i("WakeWord", "自定义唤醒词模型加载成功");
return true;
} catch (Exception e) {
Log.e("WakeWord", "模型加载失败: " + e.getMessage());
return false;
}
}
public float[] runInference(float[] inputFeatures) {
float[][] output = new float[1][1];
tfliteInterpreter.run(inputFeatures, output);
return output[0];
}
}
避坑指南：我曾经遇到过一个问题，用户自定义的唤醒词跟系统默认的唤醒词发音太像，导致两个模型同时触发。后来我加了一个互斥逻辑：如果自定义模型检测到唤醒词，就屏蔽默认模型200ms，反之亦然。
另外，自定义唤醒词的集成还要考虑权限问题。在Android Automotive上，唤醒词模型文件通常放在/data/local/tmp/或者/vendor/etc/目录下。但要注意，有些车机厂商会限制对这些目录的读写权限。我建议在系统服务层封装一个接口，通过Binder通信来管理模型文件。
3.4 唤醒策略与防误触
唤醒机制做完了，还得考虑用户体验。你不能让车机动不动就醒，那用户会疯掉的。
我总结了几条策略：
- 双阈值机制：低阈值用于一级唤醒，高阈值用于二级确认。
- 时间窗口限制：两次唤醒之间至少间隔1秒，防止连续误触发。
- 场景感知：如果检测到用户在打电话或者车机正在播放重要内容，暂时降低唤醒灵敏度。
- 用户反馈：如果用户连续三次误唤醒，自动调高阈值，或者提示用户重新录制唤醒词。
嗯，这里还要提一下，唤醒词的响应速度也很关键。从用户说完唤醒词到车机给出反馈，我建议控制在300ms以内。超过500ms，用户就会觉得卡顿。
总结一下：语音唤醒机制，核心就是三个字——快、准、省。快是指响应快，准是指误唤醒少，省是指功耗低。这三个目标有时候是矛盾的，需要你在实际项目中做权衡。
我记得有一次，为了把功耗从15mW降到8mW，我们把模型从CNN换成了DNN，结果误唤醒率上升了3%。后来通过调整特征提取的参数，才把误唤醒率压下来。这种调优的过程，说白了就是不断试错。
好了，这一章就讲到这里。下一章我们会聊语音识别引擎的集成，包括在线识别和离线识别的切换策略，到时候见。