随着智能座舱娱乐功能的持续进化，车载卡拉OK已经成为中高端车型的标配。不同于手机K歌，车载环境有其独特的声学挑战：空间小、扬声器功率大、麦克风与扬声器距离近。本文以高通HQX（骁龙座舱平台）为参考，梳理Android Automotive OS（AAOS）侧卡拉OK系统的完整实现方案。
📐 整体架构
在AAOS平台上，卡拉OK系统整体分为以下几个处理域：
- Android应用域（AP端）：Karaoke APP、人声消除(VR)、混音、评分系统
- Android Framework域：AudioFocus、AudioPolicy、AAudio、Multi-Zone路由
- Hexagon DSP域（QAF）：回声消除(AEC)、噪声抑制(NS)、语音唤醒(VAD)
- Audio HAL域：音频路由、采样率转换、I2S/TDM接口
处理域划分原则
- 算力密集型AI算法 → AP端：人声消除(VR)、音高修正(Pitch Correction)通常在AP端运行，Hexagon DSP受限于DSP算力和模型大小
- 实时性要求极高 → Hexagon DSP：AEC、NS、VAD需要极低延迟（<20ms），适合在DSP中以硬件/固件方式实现
- 策略/路由 → Audio HAL/Framework：AudioPolicy、Multi-Zone路由必须在Framework层处理
🔬 Hexagon DSP vs Android AP 算力对比
| 处理环节 | 推荐处理位置 | 原因 |
|---|---|---|
| AEC（回声消除） | Hexagon DSP ✅ | 实时性要求极高，延迟敏感，必须在DSP硬实时处理 |
| NS（噪声抑制） | Hexagon DSP ✅ | 同上，实时pipeline |
| VAD（语音活动检测） | Hexagon DSP ✅ | 极低延迟，用于唤醒词检测 |
| VR（人声消除/伴奏提取） | Android AP端 ✅ | 模型大（通常>50MB），算力要求高，Hexagon DSP承载不了 |
| Pitch Correction（音高修正） | Android AP端 ✅ | 实时性要求中等，但算力需求高 |
| Reverb（混响） | AP端或DSP端均可 | 延迟要求低，效果型算法 |
| 混音（Mixing） | Android AP端 ✅ | 需要访问多路音频流，在AP端处理更灵活 |
📊 高通HQX平台卡拉OK数据流
基于高通座舱平台（QCS6490/QCM6490等HQX系列），典型的车载Karaoke音频数据流如下：
- 麦克风输入：蓝牙麦克风（HFP)或USB麦克风 → Audio USB HAL / BT HFP HAL
- DSP前处理：Hexagon DSP → AEC + NS → 输出干净人声
- AP端处理：Android AP → 人声消除(VR) → 伴奏+处理后人声混音
- 输出：AP端混音结果 → Audio HAL → I2S/TDM → 功放 → 扬声器
关键路径延迟分析
| 环节 | 延迟 | 说明 |
|---|---|---|
| 麦克风→Hexagon DSP (AEC+NS) | ~5-10ms | DSP硬件pipeline |
| DSP→AP端 | ~5ms | 共享内存零拷贝 |
| AP端VR算法处理 | ~20-40ms | 取决于模型大小和AP算力 |
| 混音 | ~5ms | PCM buffer处理 |
| Audio HAL→功放输出 | ~10-15ms | I2S buffer |
| 总计（端到端） | ~45-70ms | 可接受的K歌体验 |
🧠 Hexagon DSP侧算法实现
高通座舱平台的Hexagon DSP（QAF – Qualcomm AI Engine）运行实时音频处理固件，关键算法在DSP中实现：
1. AEC（回声消除）
- 实现位置：Hexagon DSP 音频固件（ADSP）
- 接口：通过QAF（Qualcomm AI Engine）API调用，或通过 HAL下的Audio Voice driver
- 技术方案：自研车载AEC算法（针对车内环境优化），支持双工通话和Karaoke模式切换
- 关键配置：需要知道扬声器输出参考信号和麦克风输入信号的对齐关系
2. NS（噪声抑制）
- 实现位置：Hexagon DSP，与AEC串联
- 技术方案：传统信号处理（谱减法）+ DNN混合，高通8.0+支持AI-NS
- 优化：车内风噪、胎噪、空调噪音等特定噪声模型
3. VAD（语音活动检测）
- 实现位置：Hexagon DSP，always-on
- 用途：唤醒词检测、语音打断、Karaoke时的人声检测
- SDK：QAF Voice SDK
📱 Android AP侧算法实现
1. VR（人声消除/伴奏提取）
- 实现位置：Android AP端，作为独立Native Service或APP内处理
- 技术方案：云端方案（Deezer spleeter API）或本地方案（Facebook MDM、spleeter等开源模型，或厂商自研）
- 模型选择：2-stem（人声/伴奏分离）vs 4-stem/5-stem（更好分离效果，但算力需求更高）
- 部署方式：NPU加速（高通QNPU）或GPU加速（Adreno）或纯CPU（不推荐）
2. Pitch Correction（音高修正）
- 实现位置：Android AP端，Native Service
- 技术方案：Celemony Capstan（商业方案）或自研实时Pitch Shifter
- 延迟：~10-20ms
3. 混音（Mixing）
- 实现位置：Android AP端，AudioTrack或AAudio混合
- 处理：人声音量独立控制、伴奏音量控制、实时耳返（IEM）混音
🎛️ 高通HQX平台Multi-Zone卡拉OK
车载Karaoke的理想场景是：前排乘客K歌，后排乘客继续听导航/音乐。这需要AAOS的Multi-Zone Audio支持。
- Zone 1（前排）：Karaoke音频输出
- Zone 2（后排）：导航播报/音乐继续播放
- 实现：Audio HAL v2+ 的 Dynamic Routing，各Zone独立AudioPolicy
💡 方案选型建议
- 后装/入门方案：纯AP端VR算法，蓝牙麦克风 → 延迟较高（>100ms），但成本低
- 前装中配方案：Hexagon DSP AEC+NS + AP端VR → 体验均衡
- 旗舰方案：Hexagon DSP AEC/NS/VAD + AP端VR + Multi-Zone + 专业DSP后处理 → 最优体验
持续更新中，欢迎行业专家补充指正。