2、双耳通话架构设计：TWS拓扑与主从模式
好，我们直接进入正题。双耳通话，说白了就是让两只耳机协同工作，把通话这件事做好。你想想看，手机只有一个蓝牙射频，却要同时跟两只耳机通信，这中间的门道可不少。
我个人习惯把TWS通话架构拆成三个核心要素：拓扑结构、主从角色、数据分发方式。这三者决定了通话的稳定性、延迟和功耗。我在项目中见过太多因为架构选型失误导致产品返工的案例，所以这一章我会把坑都给你指出来。
2.1 TWS真无线立体声拓扑结构
先看拓扑。TWS的拓扑其实就两种主流方案：
- 手机-主耳-从耳（经典中继模式）
- 手机-双耳直连（双发模式）
目前市面上90%的TWS耳机用的都是第一种。为什么？因为成熟、稳定。我最早做TWS项目时也想过用双发模式，结果发现手机兼容性是个大坑——很多老款手机不支持同时连接两个蓝牙设备做同步播放。
来看一个典型的拓扑示意图：
┌─────────┐ ACL链路 ┌──────────┐
│ 手机 │ ────────────────→ │ 主耳 │
│ (Source) │ │ (Primary)│
└─────────┘ └────┬─────┘
│
eSCO/ACL │ 中继链路
│
┌────▼─────┐
│ 从耳 │
│(Secondary)│
└──────────┘这里要注意，主耳和手机之间走的是标准的ACL链路（异步无连接），用于传输语音数据包。而从耳的数据，要么通过监听空中包获取，要么由主耳转发过去。
关键点：双耳通话的拓扑核心是单链路入耳。手机只跟主耳建立一条eSCO链路（增强型同步连接），从耳的数据全靠内部机制获取。这样做的好处是——手机端不需要做任何特殊适配，标准蓝牙协议就能搞定。
2.2 主从耳模式（Primary/Secondary）
主从模式，这是TWS的灵魂。主耳负责跟手机通信，从耳负责接收主耳的数据。角色一旦确定，在整个通话过程中基本不会切换——除非主耳没电了或者掉出耳朵。
主耳承担的工作量其实挺大的：
- 管理eSCO链路：跟手机协商语音参数，比如编码格式、包类型、重传策略
- 语音数据接收：从手机接收下行语音包（对方说话的声音）
- 数据分发：把下行语音包同步给从耳
- 上行语音采集：采集本耳麦克风信号，打包发送给手机
- 从耳上行数据转发：把从耳的麦克风数据也转发给手机
从耳相对轻松，只需要：
- 接收主耳转发的下行语音
- 采集本耳麦克风信号，发给主耳
嗯，这里有个容易忽略的点——主从耳的时钟同步。我曾经在一个项目里发现，主耳和从耳的播放时间戳差了将近20ms，导致用户感觉声音在两只耳朵之间「飘」。后来查出来是两边的晶振精度不一致，加上没有做定期的时钟校准。
我的建议：主从耳之间至少每100ms做一次时钟同步。可以用蓝牙的蓝牙时钟（Bluetooth Clock）作为基准，主耳定期发送同步包，从耳据此调整本地时钟。别小看这个细节，它直接决定了双耳播放的同步性。
2.3 监听模式（Snoop）
监听模式，说白了就是从耳「偷听」手机发给主耳的数据包。这个机制利用了蓝牙的跳频同步特性——从耳知道主耳和手机之间的跳频序列，所以能在正确的时隙、正确的频率上抓到数据包。
监听模式的工作流程是这样的：
1. 主耳与手机建立连接后，把连接参数（跳频序列、时钟偏移等）告诉从耳
2. 从耳根据这些参数，计算出手机→主耳的接收时隙
3. 从耳在自己的接收窗口内，监听空中数据包
4. 抓到包后，解析出语音数据，送入本地播放队列你可能会问：「从耳监听的时候，会不会影响主耳接收？」
答案是：不会。蓝牙的空中接口是广播式的，主耳和从耳只是监听者，不参与发送。所以从耳监听对主耳没有任何干扰。但有个前提——从耳的射频接收灵敏度要够好，否则容易丢包。
注意：监听模式有个天然缺陷——无法获取上行数据。从耳只能听到手机发给主耳的下行语音，但无法把自己的麦克风数据通过监听方式传给手机。所以监听模式必须配合转发模式使用，才能实现完整的双耳通话。
我在做第一个TWS通话项目时，就只用了监听模式，结果发现从耳的声音传不回去。当时调试了整整两天，最后才意识到——监听是单向的，上行还得靠转发。
2.4 转发模式（Forward）
转发模式，就是主耳把从耳的上行语音数据，通过蓝牙链路转发给手机。这个链路可以是ACL，也可以是eSCO——具体看芯片方案。
转发模式有两种实现方式：
| 方式 | 原理 | 延迟 | 功耗 |
|---|---|---|---|
| ACL转发 | 主耳将从耳数据打包成ACL包，在空闲时隙发送 | 较高（约20-30ms） | 较低 |
| eSCO转发 | 主耳在eSCO保留时隙内转发从耳数据 | 较低（约10-15ms） | 较高 |
我个人更倾向于用ACL转发。为什么？因为eSCO时隙是预留的，如果转发数据量突然增大，可能会挤占主耳自己的上行时隙。而ACL转发更灵活，可以利用空闲带宽。
转发模式的关键技术点有两个：
- 数据合并：主耳需要把自己和从耳的两路上行语音合并成一路。合并方式可以是简单的叠加，也可以是更复杂的波束成形。
- 时序控制：从耳的数据到达主耳后，主耳要尽快转发出去，否则手机端会感觉到延迟。
避坑指南：我曾经在一个项目里遇到转发数据丢包的问题。查到最后发现，主耳在转发从耳数据时，没有做重传机制。蓝牙空中环境干扰大，丢包是常态。所以转发链路一定要加上ARQ（自动重传请求），否则通话质量会非常差。
2.5 监听+转发的混合架构
实际产品中，很少单独用监听或转发。主流方案是下行用监听，上行用转发。这样既保证了下行语音的低延迟同步，又解决了上行数据的回传问题。
来看一个完整的通话数据流：
手机 → 主耳（eSCO下行）：对方语音数据
主耳 → 从耳（监听获取）：对方语音数据（从耳直接监听空中包）
从耳 → 主耳（ACL上行）：从耳麦克风采集的本地语音
主耳 → 手机（eSCO上行）：主耳麦克风数据 + 从耳麦克风数据（合并后）这个架构的好处很明显：
- 下行同步性好，两只耳机几乎同时播放对方声音
- 上行数据由主耳统一管理，手机端只需要处理一条eSCO链路
- 兼容性好，任何支持标准蓝牙的手机都能用
当然，代价就是主耳的功耗会高一些——它既要监听下行，又要转发上行，还要做数据合并。所以主耳的电池容量通常会比从耳大10%-15%。
一个小技巧：在做主从耳角色分配时，可以优先把麦克风性能更好的那颗耳机设为主耳。因为主耳要处理两路上行数据，如果它的麦克风信噪比高，最终的通话质量会更好。我在项目里就是这么做的，效果很明显。
好了，这一章的内容就到这里。双耳通话的架构设计，说白了就是解决好「数据怎么来、怎么分、怎么回」这三个问题。监听和转发是两种互补的手段，理解它们的原理和适用场景，你就能设计出稳定可靠的TWS通话方案。
下一章我们会深入语音编解码的选型，看看不同的编码格式对通话质量的影响。到时候再聊。