1. 高通平台音频架构概述：ADSP与CDSP简介、音频框架、降噪算法部署的硬件路径
各位同学，欢迎来到《高通平台降噪算法部署与性能调优》的第一章。
做音频算法部署，最怕什么？最怕你算法写得再好，上了平台就「跑不动」或者「声音断断续续」。我见过不少工程师，在PC上仿真效果一流，一烧到手机上就各种爆音、延迟超标。为什么？说白了，就是没搞懂底层的硬件架构和音频数据流。
这一章，我们先打好地基。我会带你理清高通平台上的两个关键DSP——ADSP和CDSP，搞清楚音频框架ALSA和Audio HAL是怎么工作的，最后把降噪算法的硬件路径画出来。你想想看，路都走不对，车怎么能开得快？
1.1 为什么需要两个DSP？ADSP与CDSP的分工
高通平台上有两个专门干「脏活累活」的处理器：ADSP（音频数字信号处理器）和CDSP（计算数字信号处理器）。很多人刚接触时会问：「一个DSP不够用吗？为什么要搞两个？」
嗯，这个问题我当年也问过。答案是：术业有专攻。
| 特性 | ADSP | CDSP |
|---|---|---|
| 核心定位 | 音频流处理、语音通话、低功耗音频 | 通用计算、AI推理、传感器融合 |
| 典型负载 | ANC降噪、回声消除、音频编解码 | 神经网络降噪、语音识别、视觉处理 |
| 实时性要求 | 极高（<10ms 往返延迟） | 较高（可容忍20-50ms） |
| 功耗 | 极低（常驻运行） | 中等（按需唤醒） |
| 编程模型 | 基于FastRPC的DSP端服务 | 基于SNPE/QNN的AI推理 |
简单来说，ADSP是「老黄牛」，专门处理持续的、低延迟的音频流。它跑的是经典的信号处理算法，比如自适应滤波器、固定波束成形。CDSP则是「特种兵」，适合处理突发的、计算密集型的任务，比如用神经网络做降噪。
我的经验： 在项目中，我习惯把「确定性高」的算法（比如固定滤波）放在ADSP，把「需要模型推理」的算法（比如DNN降噪）放在CDSP。这样既能保证通话的稳定性，又能利用CDSP的算力做更复杂的处理。
1.2 音频框架：从ALSA到Audio HAL的数据流
搞清楚了硬件，我们来看看软件。音频数据从麦克风进来，到你的算法跑起来，中间要经过好几层。这一节我们重点讲两个关键层：ALSA和Audio HAL。
1.2.1 ALSA：内核里的音频管家
ALSA（Advanced Linux Sound Architecture）是Linux内核里的音频驱动框架。在高通平台上，它负责管理音频设备、路由音频数据、控制采样率和位深。
你写算法时，不会直接操作ALSA，但你需要知道它提供的几个关键概念：
- PCM设备： 音频数据的输入输出接口。比如
hw:0,0通常代表主麦克风。 - Control设备： 用来调节音量、切换通路、配置采样率。
- ASoC（ALSA System on Chip）： 高通对ALSA的封装，专门针对嵌入式SoC做了优化。
避坑指南： 我曾经在一个项目里，发现降噪算法跑起来后声音有「咔咔」的杂音。查了两天，最后发现是ALSA的buffer size配置太小，导致音频数据丢帧。记住，ALSA的period size和buffer size一定要和你的算法处理帧长匹配。
1.2.2 Audio HAL：应用与硬件的桥梁
Audio HAL（硬件抽象层）位于Android框架和ALSA之间。它的作用是把上层应用（比如、QQ音乐）的音频请求，翻译成ALSA能理解的命令。
对于降噪算法部署，Audio HAL里有一个关键模块——音频效果器（Audio Effect）。你的降噪算法，通常就是作为一个Audio Effect注册到HAL里的。
// 一个典型的Audio Effect HAL接口定义
struct audio_effect_interface_t {
int (*init)(effect_context_t *context);
int (*configure)(effect_context_t *context, effect_config_t *config);
int (*process)(effect_context_t *context, audio_buffer_t *in, audio_buffer_t *out);
int (*set_parameter)(effect_context_t *context, effect_param_t *param);
int (*get_parameter)(effect_context_t *context, effect_param_t *param);
};你看，这个接口很简单：init初始化，configure配置参数，process处理数据。你的降噪算法，就写在process函数里。
1.3 降噪算法部署的硬件路径：一张图说清楚
好了，理论讲完了，我们来画一张图。这张图是我在项目中反复使用的，它能帮你快速定位问题出在哪个环节。
这张图展示了三种典型的音频数据路径：
- 实时路径（红色）： 麦克风数据 -> 编解码器 -> ADSP。这是最常用的路径，延迟最低，适合ANC、AEC等算法。
- AI路径（橙色）： 麦克风数据 -> 编解码器 -> ADSP -> 共享内存 -> CDSP。当你的降噪算法需要神经网络推理时，数据会通过共享内存送到CDSP处理，处理完再送回ADSP。
- 应用路径（绿色）： 数据从APSS经过Audio HAL到达应用层。这条路径延迟最高，通常用于非实时的音频处理。
注意： 路径选择直接影响算法性能。如果你把需要低延迟的算法（比如通话降噪）放在了应用路径上，那延迟会直接飙到100ms以上，用户会明显感觉到「对不上口型」。我建议，凡是涉及通话的算法，一律走ADSP实时路径。
1.4 本章小结
这一章我们讲了三个核心概念：
- ADSP vs CDSP： 一个负责实时音频，一个负责AI计算。选对平台，事半功倍。
- ALSA与Audio HAL： 音频数据从硬件到应用的桥梁。你的算法就挂在Audio HAL的Effect接口上。
- 硬件路径： 三种路径对应不同场景。实时路径是王道，AI路径是利器，应用路径是备选。