1. 蓝牙协议栈概览与车载音响系统架构

各位同学，欢迎来到《车载音响蓝牙协议栈集成实战》的第一课。

做车载音响这么多年，我见过太多工程师一上来就扎进代码里，结果被各种蓝牙连接失败、音频卡顿搞得焦头烂额。其实，搞懂蓝牙协议栈和系统架构，比什么都重要。今天我们就先把地基打牢。

1.1 经典蓝牙(BR/EDR)与低功耗蓝牙(BLE)的区别

蓝牙这东西，说白了就两种：经典蓝牙和低功耗蓝牙。很多人以为BLE就是蓝牙4.0，其实不准确。我习惯这么区分：

• 经典蓝牙 (BR/EDR)：Basic Rate / Enhanced Data Rate。主打高速率、持续连接。适合音频流传输。
• 低功耗蓝牙 (BLE)：Bluetooth Low Energy。主打低功耗、间歇性通信。适合传感器、控制指令。

你想想看，车载音响里，音乐播放必须用经典蓝牙。为什么？因为A2DP协议只跑在BR/EDR上。而像车门解锁、胎压监测这些，用BLE就够了。

我在项目中遇到过一件事：有个同事非要用BLE传A2DP音频，结果折腾了两周，发现BLE的带宽根本扛不住48kHz/16bit的PCM流。嗯，这就是没搞清楚底层区别的代价。

1.2 车载音响系统的整体硬件架构

搞懂了蓝牙类型，我们来看看车载音响里到底有哪些硬件在干活。我习惯把整个系统拆成四个核心模块：

1.2.1 主控芯片 (SoC / MCU)

这是大脑。负责跑操作系统、处理用户交互、管理蓝牙协议栈的上层逻辑。常见的有高通骁龙、瑞萨R-Car、NXP i.MX系列。我个人习惯把蓝牙的HCI命令解析放在主控侧，这样灵活性高。

1.2.2 蓝牙模块 (Bluetooth Module)

这是耳朵和嘴巴。负责射频收发、基带处理、链路控制。现在主流方案是模组形式，比如高通QCC系列、瑞昱RTL系列、赛普拉斯CYW系列。模块内部自带一个MCU，跑蓝牙Controller层。

1.2.3 音频DSP (Audio DSP)

这是调音师。负责音频编解码、降噪、回声消除、音效处理。车载音响里，DSP的地位甚至比主控还重要。常见的如ADI的SHARC系列、TI的TMS320系列、以及一些SoC内置的DSP核。

为什么需要独立的DSP？你想想看，主控要处理导航、蓝牙协议、UI渲染，如果还要实时处理音频，很容易出现卡顿。把音频处理交给DSP，这叫专业的事交给专业的芯片。

1.2.4 功放 (Amplifier)

这是喇叭的驱动。负责把DSP输出的模拟信号放大，驱动车门上的扬声器。常见的有AB类功放和D类功放。D类效率高，但EMI问题多，布局时要注意。

1.3 蓝牙协议栈在车载音响中的分层

蓝牙协议栈不是一块铁板，它是分层的。我习惯把它分成三层：

1. Controller层：物理层、基带、链路控制。这部分通常固化在蓝牙模块内部。
2. Host层：L2CAP、SDP、GATT、ATT、SM。这部分跑在主控上。
3. Profile层：A2DP、AVRCP、HFP、PBAP等。这是和车载应用直接打交道的部分。

举个例子，当手机播放音乐时：

• 手机通过A2DP Profile把音频数据打包
• 经过L2CAP分段重组
• 通过HCI接口传给蓝牙模块
• 蓝牙模块通过射频发送
• 车机蓝牙模块接收后，反向解析
• 最终把PCM数据喂给DSP

你看，这一路下来，任何一层出问题，音频都会断。我调试过最头疼的一个bug，就是L2CAP的MTU协商不一致，导致音频包频繁重传。最后发现是Host和Controller的MTU配置没对齐。

1.4 本章小结

这一章我们聊了：

• 经典蓝牙和BLE的区别——记住，音频用BR/EDR，控制用BLE
• 车载音响的四大硬件模块——主控、蓝牙模块、DSP、功放，缺一不可
• 蓝牙协议栈的三层结构——Controller、Host、Profile，层层关联

下一章，我们会深入A2DP协议，看看音频数据到底是怎么从手机流到喇叭的。到时候我会分享一个我在A2DP SRC延迟优化上的实战案例，保证干货满满。

好，今天就到这里。有问题欢迎在评论区留言，或者直接找我。我是老张，咱们下节课见。