第一章：音频基础与TWS架构
各位同学好，我是老张。在音频行业摸爬滚打了十几年，从最早的MP3播放器做到现在的TWS耳机，踩过的坑确实不少。今天咱们开始第一节课，先把地基打牢。
数字音频基础这部分，说实话，很多工程师做了好几年都搞不清楚采样率和位深到底怎么影响音质。我见过不少项目，明明硬件方案不错，结果音质一塌糊涂，最后发现是采样率转换没处理好。嗯，咱们先从最基础的说起。
1.1 数字音频基础
采样率（Sample Rate）
说白了，采样率就是每秒钟对模拟信号“拍照”的次数。人耳能听到的频率范围是20Hz-20kHz，根据奈奎斯特定理，采样率至少要达到信号最高频率的两倍才能无失真还原。
常见采样率：
- 8kHz：电话语音，够用就行
- 16kHz：宽带语音，我早期做VoIP项目时常用
- 44.1kHz：CD音质，音乐播放的标配
- 48kHz：影视音频，也是TWS耳机最常见的采样率
- 96kHz/192kHz：高解析音频，说实话，在TWS上意义不大
为什么TWS耳机大多用48kHz？我个人习惯用48kHz做开发，因为蓝牙传输带宽有限，48kHz配合合适的编码器，能在音质和延迟之间取得平衡。你想想看，如果硬上96kHz，蓝牙那点带宽根本扛不住，反而会引入更多压缩失真。
位深（Bit Depth）
位深决定了动态范围。每增加1bit，动态范围提升约6dB。16bit的理论动态范围是96dB，24bit能达到144dB。
| 位深 | 动态范围 | 常见应用 |
|---|---|---|
| 16bit | 96dB | CD、普通音乐 |
| 24bit | 144dB | 录音棚、高解析音频 |
| 32bit float | 理论无限 | 专业音频处理 |
避坑指南：我曾经在项目里遇到过，ADC采集用的是24bit，但DSP内部处理只支持16bit，结果截断后底噪明显变大。后来我强制在DSP输入端做抖动处理（dithering），才把问题解决。记住，位深转换时一定要加抖动，不然量化失真会让你怀疑人生。
编解码格式
TWS耳机里常见的音频编解码格式，我按使用频率排个序：
- SBC：蓝牙强制支持的编码，音质一般，但兼容性最好
- AAC：苹果生态的宠儿，Android也支持，压缩效率比SBC高
- LDAC：索尼家的，最高支持990kbps，接近无损
- aptX系列：高通家的，aptX Adaptive现在很流行
- LHDC：华为力推的，规格和LDAC类似
我建议做产品时，至少支持SBC和AAC，这是底线。如果芯片方案支持，再加上LDAC或aptX Adaptive作为卖点。但说实话，在TWS这种小体积设备上，编解码带来的音质差异远不如耳机声学设计本身重要。
1.2 TWS耳机系统架构
TWS耳机的架构，说白了就是解决“两个耳机怎么同步”的问题。我刚开始做TWS时，用的还是转发模式，那延迟简直感人。现在主流方案已经进化了好几代。
主从模式
这是最经典的架构。手机只连一只耳机（主耳），主耳再把音频转发给另一只（从耳）。
工作流程：
- 手机通过A2DP把音频流发给主耳
- 主耳解码后，一路给本地播放，一路通过私有协议转发给从耳
- 从耳收到后解码播放
这种架构的痛点很明显：主耳功耗高，从耳功耗低，用着用着两只耳机电量就不平衡了。我遇到过用户投诉说“左耳半小时就没电了，右耳还能用两小时”，其实就是主从模式导致的。
转发模式
手机同时发两路音频流，一只耳机作为主设备接收，另一只通过监听或转发获取数据。这种模式现在基本被淘汰了，因为蓝牙带宽有限，两路流容易互相干扰。
注意：转发模式在蓝牙5.2之前，延迟通常在200ms以上，打游戏根本没法用。我曾经在项目里测试过，用户说“枪声都响完了，画面才显示开枪”，这就是转发模式的典型问题。
监听模式
这是目前主流TWS芯片（如高通QCC系列、恒玄BES系列）采用的方案。手机只发一路音频流，两只耳机同时监听同一个蓝牙数据包。
为什么监听模式好？因为两只耳机接收的是同一份数据，天然同步。而且功耗均衡，不会出现一只耳机先没电的情况。
我的经验：监听模式下，两只耳机的时钟同步是个大坑。蓝牙时钟漂移会导致左右耳逐渐不同步。我习惯在软件里加一个定时校准机制，每10秒左右强制同步一次时钟，效果很好。
1.3 蓝牙音频协议栈概览
蓝牙音频协议栈，说白了就是蓝牙耳机和手机之间怎么“说话”的规矩。咱们重点说三个最常用的profile。
A2DP（Advanced Audio Distribution Profile）
A2DP负责传输高质量音频，也就是听歌用的。它定义了音频流的编码、传输和解码流程。
A2DP的传输流程是这样的：
- Source（手机）把PCM音频编码成SBC/AAC/LDAC等格式
- 通过蓝牙L2CAP通道发送给Sink（耳机）
- Sink解码后播放
这里有个坑：A2DP默认的编码器协商机制。手机和耳机会互相告诉对方自己支持哪些编码器，然后选一个双方都支持的。我遇到过手机说支持AAC，但实际传输时码率只有128kbps，音质还不如SBC。后来发现是手机端的AAC编码器实现有问题。
HFP（Hands-Free Profile）
HFP负责通话音频，也就是打电话用的。它用的是窄带（8kHz采样）或宽带（16kHz采样）语音编码。
HFP的编码器主要有：
- CVSD：老古董，8kHz采样，64kbps，音质像对讲机
- mSBC：宽带语音，16kHz采样，音质好很多
- LC3：蓝牙LE Audio的新编码，效率高，延迟低
避坑指南：我曾经在项目里发现，HFP通话时，如果耳机同时开了降噪，回声消除（AEC）会出问题。原因是降噪算法改变了麦克风信号的相位，导致AEC参考信号和实际信号对不上。后来我调整了AEC的参考信号路径，把降噪后的信号作为参考，才解决问题。
AVRCP（Audio/Video Remote Control Profile）
AVRCP负责控制，比如播放/暂停、上一曲/下一曲、音量调节等。它和A2DP是配套使用的。
AVRCP的版本很重要：
- AVRCP 1.4：支持基本控制，但不支持歌曲信息显示
- AVRCP 1.5：增加了媒体信息查询，耳机上能看到歌名
- AVRCP 1.6：支持绝对音量控制，耳机调音量手机也跟着变
我建议做产品时，AVRCP至少支持到1.5版本。1.6的绝对音量控制虽然好用，但有些老手机兼容性不好，会出现音量不同步的问题。
好了，第一节课的内容就到这里。数字音频基础、TWS架构、蓝牙协议栈，这三块是后续所有算法调优的基础。下节课咱们开始讲音频信号处理，到时候会用到今天讲的采样率和位深知识，别掉队。