Chapter 11: 电话接入与特殊处理

开篇段落

本章将深入探讨车载语音系统中一个独特且至关重要的场景：电话接入。与常规的语音交互不同，电话通话引入了外部的、不可预测的音频流（远端说话人），并彻底改变了系统的音频焦点、优先级和隐私边界。这不仅仅是一个功能叠加，而是对系统鲁棒性和架构设计的严峻考验。我们将详细剖析从蓝牙 HFP、应用层 VoIP 到硬件层 eSIM 的不同电话管线，并重点攻克通话期间多参考信号的回声消除、精细化的增益控制、以及语音助手在“服务”与“退避”之间的优雅切换策略。本章的目标是，帮助工程师构建一个无缝、可靠且合规的通话体验，将电话从一个“断一切”的干扰，平滑地集成为座身智能的一部分。

11.1 蓝牙 HFP / VoIP / eSIM 管线

车载电话功能的实现路径直接决定了音频路由的复杂度和控制逻辑的实现深度。理解它们的本质差异是构建稳定系统的基石。

  • 蓝牙 HFP (Hands-Free Profile)：最普及的手机-车机连接方案，本质上是一个标准化的远程音频外设协议。
  • 工作模式：手机作为音频网关(AG)，车机作为免提设备(HF)。所有音频流和控制信令都通过蓝牙协议栈的 AT 命令（如 AT+BRSF 查询支持特性，AT+CIND 获取状态指示，AT+VGS/ATVGM 同步音量）进行交换。音频数据在一条独立的 SCO (Synchronous Connection-Oriented) 或 eSCO (extended SCO) 链路上双向传输。

  • 挑战与细节：

    • 音质协商：系统必须在连接建立时，通过 HFP 的 Codec Negotiation 特性，优先选择宽带语音编码（如 mSBC, 16kHz 采样），并能优雅地回退到带编码（CVSD, 8kHz 采样），以兼容老旧手机。
    • In-Band Ringing：现代手机支持“带内铃声”，即将手机的实际铃声通过 SCO 链路传来，而不是让车机播放预设铃声。系统需要能正确识别并播放此音频流。
    • 延迟与抖动：蓝牙传输固有的延迟和丢包，需要音频子系统有健壮的 Jitter Buffer 来平滑音频流，避免卡顿。

  • VoIP (Voice over IP) 应用：运行在车机操作系统（如 Android Automotive OS）或手机投屏方案（如 CarPlay, Android Auto）上的第三方通信应用。

  • 工作模式：这类应用的音频流对于操作系统而言，是标准的 STREAM_VOICE_CALL 类型应用音频。它们通过操作系统的音频策略管理器（Audio Policy Manager）申请音频焦点（Audio Focus）。

  • 挑战与细节：

    • 焦点管理：系统必须严格执行音频焦点策略。一个设计良好的 VoIP 应用会使用 AudioAttributes.Builder().setUsage(AudioAttributes.USAGE_VOICE_COMMUNICATION) 来声明其意图。当它请求 AUDIOFOCUS_GAIN_TRANSIENT 时，系统应能正确地将音乐等媒体音量压低（Ducking）而不是暂停。
    • 识别与区分：系统如何区分一个 VoIP 通话和一个普通的语音消息播放？这需要依赖应用正确设置的 AudioAttributes。在 Infra 层面，可以对特定包名（如 com.tencent.mm）的应用音频流做策略倾斜，但更通用的方法是依赖标准化的音频属性。

  • eSIM / 车载 T-Box：车辆作为独立的通信终端，拥有自己的电话号码和蜂窝网络连接。

  • 工作模式：通话由车载通信模块（T-Box）中的基带处理器（Baseband Processor）直接处理。解码后的 PCM 音频数据通常通过 I2S 或 TDM 总线直接送入主 SoC 的 DSP 或音频编解码器（CODEC）进行处理。控制信令则通过 RIL (Radio Interface Layer) 与上层软件栈通信。
  • 挑战与细节：
    • 硬件强耦合：音频驱动和 HAL (Hardware Abstraction Layer) 层需要与 T-Box 供应商紧密合作，调试 I2S 时序、数据格式（如 I2S_PHILIPS_MODE, PCM_SHORT）等底层问题。
    • 网络鲁棒性：需要处理 VoLTE (Voice over LTE) 与 CSFB (Circuit Switched Fallback) 之间的切换。当车辆进入 4G 信号弱的区域，通话可能会从高质量的 VoLTE 回落到 2G/3G 的电路域，这会导致音质突变，音频子系统需要能平滑处理这种变化，避免爆音或中断。

系统架构示意图（增强版）：

+----------------+  AT Cmds   +---------------------+   SCO/eSCO   +-----------------+
| Mobile Phone   |----------->| Bluetooth Stack (HFP)|------------->|                 |
+----------------+            +---------------------+              |                 |

+----------------+            +---------------------+              |                 |
                                                                   |                 |
+----------------+ AudioFocus +---------------------+   App Audio  |   Audio HAL /   |   PCM/I2S    +-----------------+
| In-Car Apps    |----------->| OS Audio Framework  |------------->|      DSP        |--------------| Speaker/Mic HW  |
| (VoIP)         |            | (AAOS, QNX)         |              | (AEC/NS/AGC)    |              +-----------------+
+----------------+            +---------------------+              |                 |
                                                                   |                 |
+----------------+   RIL Cmds  +---------------------+   I2S/TDM    |                 |
| T-Box (eSIM)   |----------->|   Modem Interface   |------------->|                 |

+----------------+            +---------------------+              +-----------------+

Rule-of-Thumb: 无论来源如何，系统内部都应维护一个统一的、高优先级的“通话状态机”（Telephony State Machine）。所有来源（HFP, VoIP, eSIM）的事件最终都应汇聚到这个状态机，由它来统一指挥系统的音频策略、AEC配置和UI展示，避免出现多个通话互相冲突的混乱局面。

11.2 来电识别、静音穿透、回声与双端增益

保障通话清晰度是音频处理的核心目标，每个环节都至关重要。

  • 来电识别与系统状态切换:
  • 系统通过监听 TelephonyManager 的 CALL_STATE_RINGING, CALL_STATE_OFFHOOK, CALL_STATE_IDLE 等核心状态，触发全局模式切换。

  • 进入 CALL_STATE_OFFHOOK 状态后，系统必须原子性地执行一系列操作：

    1. 音频策略切换：立即暂停或压低（Ducking）非必要的音频，如媒体、导航。
    2. 语音助理模式切换：将持续监听的免唤醒模型切换为“仅唤醒词/按键触发”的保守模式，并关闭后续的语义理解链路，这是关键的隐私保护措施。
    3. AEC配置切换：将 AEC 的参考信号源从本地 TTS/媒体，动态切换到远端通话音频流。

  • 回声消除 (AEC):

  • 这是通话场景下音质的生命线。除了切换参考信号，生产级 AEC 还需关注：

    • 延迟估计 (Delay Estimation)：AEC 算法必须能实时估计从远端音频流进入 DSP，到经过 D/A 转换、功放、喇叭播放，再被麦克风拾取后 A/D 转换，最终回到 DSP 的总延迟。这个延迟（通常在几十到几百毫秒）是动态变化的，准确的估计是回声消除的前提。 $ \hat{s}_{near}(t) = y(t) - \hat{H}(t) * s_{far}(t - \hat{\tau}) $ 其中 $\hat{\tau}$ 是估计的延迟。

    • 双讲检测 (Double-Talk Detection, DTD)：当车内用户和远端用户同时说话时，AEC 必须能精确检测到这种情况。在双讲期间，AEC 应减弱其自适应滤波器的更新强度，甚至完全冻结，以防止将近端用户的语音错误地当成回声进行消除，导致近端语音被抑制或失真。

    • 非线性处理 (Non-Linear Processing, NLP)：线性自适应滤波器只能消除线性的声学回声。但扬声器、功放和车内声学环境会引入非线性失真。一个高质量 AEC 模块必须包含一个非线性处理器，用于抑制残余的非线性回声。

  • 静音穿透 (Mute Passthrough):

  • 用户的静音操作必须是端到端的。当用户在车机上点击静音，该指令需要通过 AT 命令 (AT+CHUP 的变体或专用命令) 或 RIL 接口传递到协议栈或基带，在源头将上行链路静音。为何如此重要？ 因为这能确保手机 UI 和网络侧状态（例如，电话会议中你的头像会显示静音）的同步，提供一致的用户体验，并且在协议层静音比在本地丢弃数据更节省蓝牙带宽或蜂窝网络上行带宽。

  • 双端增gidn控制 (Dual-end Gain Control):

  • 上行增益 (Uplink AGC)：与麦克风阵列的波束形成（Beamforming）紧密配合。波束形成先在空间上“聚焦”于说话人，抑制其他方向的噪声。AGC 则在此基础上对聚焦后的信号进行音量归一化，目标是让远端用户收到的语音电平稳定在-18dBFS 到 -12dBFS 之间，论说话人是轻声细语还是激动地大喊。
  • 下行增益 (Downlink SVC)：动态音量补偿（Speed-Compensated Volume）不仅仅与车速线性相关。一个更精细的策略应综合考虑：车速、发动机转速（反映引擎噪音）、HVAC 风扇档位、车窗开启状态（通过 CAN 总线获取）、甚至雨刮器状态。这构成一个多输入的音量调节模型，确保在任何驾驶条件下，远端用户的声音都清晰可闻但又不震耳。

11.3 通话期间的助理旁路与边说边做

通话期间，语音助手应从“主动服务者”转变为“待命副驾”，在需要时才介入。

  • 助理旁路 (Assistant Bypass):

  • 这是一条硬性产品原则。在通话激活时，系统必须在架构上保证，除了唤醒词检测引擎外，麦克风音频流不会被送入任何意图识别、实体提取或对话管理模块。这不仅是技术实现，更是对用户隐私的承诺。

  • 边说边做 (Concurrent Interaction):

  • 允许用户在通话时下达车控指令，是提升体验的亮点功能，但实现复杂。

  • 实现细节:

    1. 低层音频流复制 (Tee-Splitting)：激活后，麦克风的原始 PCM 流必须在尽可能低的层次——理想情况下是在 DSP 固件或 Audio HAL 中——被复制成两份。一份流向通话上行链路（编码后发送给远端），另一份流向 ASR 引擎。在应用层做复制会引入不可接受的延迟。

    2. 多参考信号AEC：这是一个巨大的挑战。当语音助手播放 TTS 响应时，系统扬声器同时在播放远端通话音频和本地 TTS 音频。这两个声音都会产生回声。此时，AEC 模块必须： a. 支持多参考信号输入：同时接收通话下行流和 TTS 输出流作为参考。 b. 动态切换/混合：如果硬件不支持多参考，则需要在 TTS 播放时，将 AEC 参考信号快速切换为 TTS 流，并在结束后切回通话流。但这可能导致切换瞬间的回声泄漏。最佳方案是硬件支持。

    3. 极简交互闭环：交互流程必须设计得极其简短。例如：“导航去公司” -> “好的，已开始导航”。避免任何需要用户二次确认或澄清的多轮对话，因为这会长时间压低通话音量，严重影响通话体验。

交互与音频流示意图：

State: IN_CALL

  - Mic Stream -> Call Uplink
  - Call Downlink -> Speaker
  - AEC Ref: Call Downlink
      |
      +---- [User says "Hey Assistant"] ----> State: IN_CALL_ASSISTANT_ACTIVE
      |     - Duck call audio volume (e.g., to -20dB)
      |     - Tee Mic Stream: copy to ASR, copy to Call Uplink
      |
      +---- [Assistant TTS starts] ----> State: IN_CALL_ASSISTANT_SPEAKING
      |     - AEC Ref: Call Downlink + Assistant TTS
      |
      +---- [Assistant TTS ends] ----> State: IN_CALL

            - Restore call audio volume
            - Stop Tee-Splitting, Mic Stream -> Call Uplink only
            - AEC Ref: Call Downlink only

11.4 录音/提示与合规

电话功能的隐私合规性是不可逾越的红线，一旦出错将导致法律风险和用户信任的崩塌。

  • 录音策略:
  • 设计原则：默认禁止 (Deny by Default)。在系统架构层面，不应为任何组件提供录制通话双向音频流的 API，除非有经过法务、隐私和安全团队严格审批的特定需求。

  • 合规实现：若必须提供录音功能，其实现必须是“强提示”和“防绕过”的。

    1. 语音提示注入：通话建立时播放的“本次通话将被录音”提示音，应在 Audio HAL 或 DSP 层直接混入（Mix-in）到上行和下行链路中，确保应用层无法捕获到“干净”的音频，也无法通过软件手段跳过该提示。
    2. 明确的视觉信号：UI 必须在状态栏等永久可见区域显示一个清晰的录音图标，用户点击该图标应能直接跳转到隐私设置或停止录音。
    3. 加密与权限：录音件必须使用强加密存储，并且访问权限应受到严格控制，遵循最小权限原则。

  • 提示与透明度:

  • 对于“边说边做”这类功能，尽管不存储通话内容，但因为它在通话期间处理了用户的语音指令，也应在隐私政策中详细说明。例如：“在通话中，当您使用唤醒词激活语音助手时，您的该条指令将被处理以执行您的请求，但您的通话内容本身不会被监听或记录。”
  • 利用系统级的隐私仪表盘（如 Android 12+ 的 Privacy Dashboard），让用户可以清晰地追溯到“电话服务”和“语音助手”在何时访问了麦克风，提供完全的透明度。

Rule-of-Thumb: 将合规性需求视为与功能需求同等重要的设计输入。在项目的早期阶段就创建一份“数据流图”和“隐私影响评估”文档，明确每一份音频数据在系统中的生命周期：从哪里来，经过哪些处理，到哪里去，是否存储，存储多久。

本章小结

  • 统一状态，分离路径：通过统一的通话状态机管理全局行为，但为 HFP、VoIP、eSIM 等不同来源的音频数据和信令设计清晰、独立的处理路径。
  • AEC是动态系统：生产级的 AEC 不仅仅是一个静态模块，它需要根据通话状态、双讲情况、延迟变化、多重参考信号（通话+TTS）进行动态配置和自适应调整。
  • 通话中的助理是“克制的副驾”：助理的介入必须是用户明确发起的，交互过程必须极简，且技术实现上要通过底层音频流复制和多参考 AEC 来保证通话和交互的并行质量。
  • 合规是架构的一部分：隐私和法律合规不是事后检查清单，而是必须融入硬件、驱动、框架和应用层设计的核心原则，尤其是对于录音等敏感功能。

常见陷阱与错误 (Gotchas)

  1. AEC 参考信号混淆：最常见且后果严重的错误。调试技巧：在实验室环境，使用音频分析仪（如 Audio Precision）或编写脚本，通过 adb shell dumpsys media.audio_flinger 检查活动输出流的属性，确保通话时 AEC 的参考输入确实是 USAGE_VOICE_COMMUNICATION 对应的音频流。进行客观评测，测量 ERLE（回声返回损失增强）指标，在双讲场景下应能保持稳定。
  2. 音频焦点冲突：导航播报以全音量粗暴打断通话。调试技巧：设计一个“音频事件日志系统”，记录每一次焦点请求、获取、释放和音量压低事件。当问题复现时，分析日志即可定位是哪个应用没有遵守音频焦点规则。
  3. 麦克风资源独占：“边说边做”时，远端用户几秒钟内听到死寂。调试技巧：使用供应商提供的 DSP 调试工具，或在 Audio HAL 中加入日志，实时监控音频流的拓扑结构，确认麦克风数据是否被正确地“tee”（一分二），而不是被“switch”（切换）。
  4. 隐私泄露的边界情况：话结束瞬间，免唤醒模型立即激活，可能捕获到通话的最后一句话并错误执行。调试技巧：在状态机设计中，从 CALL_STATE_IDLE 恢复到常规语音监听模式之间，增加一个短暂的“冷却”或“静默”期（如 500ms），确保通话音频完全排空。进行红队测试，专门攻击各种状态切换的边界。
  5. 蓝牙 HFP 兼容性黑洞：在特定手机和车载系统版本组合下，出现无法接听、音量无法同步、或 mSBC 编码协商失败。调试技巧：除了建立广泛的手机兼容性测试矩阵外，利用蓝牙协议分析仪（Sniffer）捕获并分析 HCI (Host Controller Interface) 日志，是定位这类问题的终极手段。它可以清晰地展示手机和车机之间每一条 AT 命令的交互和响应，定位失败的根源。