TWS耳机主副耳同步ACK机制
TWS（True Wireless Stereo）耳机的左右耳同步和主副耳切换是蓝牙音频领域最具挑战性的底层技术之一。在标准经典蓝牙（Classic Bluetooth）协议中，A2DP音频链路是点对点（Point-to-Point）的，手机标准协议栈原生不支持同时向两个设备发送音频流。
为了打破这种限制，现代TWS耳机（如基于高通TrueWireless Mirroring、络达MCSync或恒玄IBRT的技术）在蓝牙基带（Baseband）和链路控制器（Link Controller）层面对协议进行了深度定制。以下是关于主副耳ACK同步机制以及角色切换逻辑的底层原理解析。
一、 主副耳音频接收与ACK同步机制
现代TWS耳机普遍采用监听（Snooping/Mirroring）模式，而非早期的中继转发（Relay）模式。在监听模式下，手机实际上只与主耳（Master）建立了一条完整的ACL链路，而副耳（Slave）通过"伪装"成主耳，在空中接口（Air Interface）上同步抓取手机发出的数据包。
- 物理层与基带的同步准备
- 时钟与跳频同步： 副耳需要完全掌握主耳的蓝牙设备地址（BD_ADDR）、微微网时钟（Piconet Clock）以及当前的跳频序列（Hop Sequence）。
- 双设备单链路： 手机端对此毫不知情，它依然认为自己在和一个设备通信。
- 底层ACK/NACK同步逻辑（ARQ机制重构）
在蓝牙基带层，每个发送的Packet都需要接收方回复ACK或NACK。既然有两个接收者（主耳和监听的副耳），谁来回ACK？如果两者接收状态不一致怎么处理？这是TWS同步的核心：
- 场景A：主耳和副耳都成功接收（CRC校验通过）
主耳在规定的时隙（Slot）向手机回复ACK。副耳保持静默，更新本地的音频Buffer和包序号（Sequence Number）。 - 场景B：主耳接收成功，但副耳接收失败（或未收到）
这是最棘手的情况。由于手机只认主耳的ACK，如果主耳直接回了ACK，手机就会继续发下一个包，导致副耳丢失一帧音频。为了解决这个问题，通常有两种底层策略：- 策略1：主耳强制NACK（如高通Mirroring机制）。 主耳和副耳之间存在一条极低延迟的隐藏侧链（Intra-ear Link）。副耳如果解包失败，会在这条侧链上瞬间通知主耳。主耳即使自己收到了，也会在对手机的回复时隙中故意回复NACK（或者不回复，触发超时）。手机收到NACK后，会触发重传（Retransmission），此时主副耳再次同时尝试接收。
- 策略2：主耳ACK + 侧链重传（Cross-link Forwarding）。 主耳正常向手机回复ACK，手机继续发下一个包。同时，主耳将副耳丢失的那个包，通过主副耳之间的侧链（通常是高带宽的独立通道）单独补发给副耳。
- 场景C：主耳接收失败
主耳向手机回复NACK，手机重传。此时无论副耳之前是否接收成功，副耳都会根据包序号（Sequence Number）过滤掉重复的包，或者覆盖之前的包。
通过这种基带级别的确认与重传拦截机制，加上A2DP层面的抖动缓冲（Jitter Buffer）和本地时钟漂移补偿（通常通过音频重采样或丢帧/插帧实现），TWS耳机能将左右耳的播放时间差控制在微秒（μs\mu sμs）级别，实现完美的相位同步。
TWS耳机播放本地提示音
TWS耳机主耳播放本地提示音以及和副耳同步的流程：
1:主耳UX发起播放提示音指令，BT HOST收到指令后，通过HCI指示Controller在300ms后发起一个toggle命令给DSP，controller计算toggle所需的时间slot，然后返回event给bt host，host再返回给UX通知其会按计划toggle DSP，于此同时主耳的host还会通过spp协议把这个toggle信息转发给副耳；
2:Ux收到bt host返回的通知后，会给audio dsp上电并准备播放资源以及配置codec通路，这样dsp就会从AP那里读取一帧数据进入DMA缓冲区，然后等待toggle信号；
3:300ms后controller发起toggle信号，同时启动DMA中断，这样DMA每隔10ms就会中断传输给codec芯片；DMA缓冲区的数据是DSP先从AP读到缓冲区，然后解码再送到DMA缓冲区。
4：副耳在收到spp传输过来的toggle时延，这里需要剪掉大概100ms的传输时延，也就是300-100=200ms后controller给dsp发toggle信号，副耳的播放流程只有toggle时延和主耳不同，其他的都一样，这样主副耳就可以同步播放本地提示音了。
TWS耳机主副耳同步播放本地提示音流程图：
副耳设备
主耳设备
主耳UX发起播放提示音指令
BT HOST收到指令
通过HCI指示Controller
300ms后发起toggle命令给DSP
Controller计算toggle所需时间slot
返回event给BT HOST
BT HOST返回通知给UX
将按计划toggle DSP
BT HOST通过SPP协议
转发toggle信息给副耳
UX给Audio DSP上电
准备播放资源
配置codec通路
DSP从AP读取一帧数据
进入DMA缓冲区
等待toggle信号
Controller在300ms后
发起toggle信号
启动DMA中断
DMA每隔10ms中断
传输数据给codec芯片
主耳播放提示音
BT HOST通过SPP
接收toggle信息
计算调整后的时延
300ms - 100ms传输延迟 = 200ms
准备播放资源
配置codec通路
DSP从AP读取一帧数据
进入DMA缓冲区
等待toggle信号
Controller在200ms后
发起toggle信号给DSP
启动DMA中断
DMA每隔10ms中断
传输数据给codec芯片
副耳播放提示音
流程详细说明
数据流向与处理过程
控制时序流
播放指令
Controller计时
toggle信号触发
启动DMA中断
开始播放
音频数据处理流
AP音频数据源
Audio DSP解码处理
DMA缓冲区
Codec芯片
扬声器播放
关键时间节点示意图
主耳时间线 0ms UX发起播放指令 5ms Controller确认计划 并开始300ms倒计时 10ms UX开始准备音频资源 300ms 触发toggle信号 开始播放 副耳时间线 0ms 主耳UX发起播放指令 100ms 副耳收到SPP同步信息 105ms 开始200ms倒计时 并准备音频资源 300ms 触发toggle信号 开始播放 TWS主副耳同步时间轴
流程关键点说明
- 主耳控制流程
· 指令发起：用户通过UX界面发起播放本地提示音指令
· 计划调度：BT HOST通过HCI命令指示Controller在特定时间（300ms后）触发toggle
· 资源准备：在等待toggle期间，UX准备音频播放所需的硬件和软件资源
· 精确触发：Controller使用硬件计时器确保在精确的300ms后触发toggle信号
- 副耳同步机制
· 信息传递：主耳通过SPP协议将toggle计划时间发送给副耳
· 延迟补偿：副耳计算传输延迟（约100ms），调整本地触发时间为200ms后
· 独立准备：副耳独立完成音频资源准备，确保与主耳相同的播放状态
- 音频播放技术细节
· DMA机制：使用DMA（直接内存访问）实现高效音频数据传输
· 中断频率：DMA每10ms中断一次，确保音频流的连续性
· 解码处理：DSP从AP读取音频数据并进行解码处理，然后送入DMA缓冲区
· 硬件协调：Controller、DSP、DMA和Codec芯片协同工作实现精确播放
- 同步精度保障
· 时间同步：主副耳使用相同的时间基准，通过延迟补偿实现精确同步
· 独立触发：每只耳机独立触发播放，避免蓝牙传输抖动影响同步精度
· 硬件计时：使用Controller的硬件计时器，确保触发时间的准确性
这个流程设计确保了TWS耳机主副耳能够实现高精度的音频同步播放，即使在存在传输延迟的情况下也能提供一致的用户体验。