蓝牙低功耗音频技术手册：从“为什么我的通话声音听起来像是从罐头里传出来的”到AOSP系统的实现方式

标准编解码器配置

BAP定义了一组具有特定名称的编解码器配置选项，这些配置对应于特定的LC3参数。设备在通信过程中会协商使用这些“预设配置”：

>

)

>

>

对于大多数消费级耳塞来说，媒体播放通常使用48_4配置（48千赫兹采样率，96千比特/秒比特率），而电话通话则使用16_2配置（16千赫兹采样率，32千比特/秒比特率）。这种统一的LC3编解码器配置能够同时满足这两种应用场景——无需在SBC和mSBC之间切换！

音频上下文类型

LE Audio定义了音频上下文类型，这类元数据能够告知接收设备当前正在传输的是哪种类型的音频。这样一来，设备就能根据这些信息优化自身的运行方式（例如，在通话时启用降噪功能，或在播放音乐时增强低音效果）：

>

与传统的音频传输方式相比，LE Audio提供了更为细致的分类。传统方式基本上只区分两种状态：“正在播放音乐”或“正在进行通话”。而利用LE Audio，设备能够根据不同的音频类型做出智能化的处理决策，比如“这是游戏音频，应使用7.5毫秒的帧间隔以降低延迟”，或者“这是一个通知信息，需要将其融入音频流中但不要中断音乐的播放”。

AOSP单播服务器实现机制

在AOSP系统中，单播服务器功能主要用于那些Android设备作为接收端的情况（例如，基于Android系统的助听器或接收音频信号的Chromebook设备）。

相关关键类包括：

• LeAudioService.java：当设备处于接收角色时，负责处理服务器端的操作

• 在原生代码中：le_audio_server.cc负责管理用于承载PACS、ASCS等数据的GATT服务器

广播源实现机制

对于Auracast广播音频而言，AOSP系统中的广播源相关实现包括以下步骤：

// 在LeAudioService.java或BroadcastService中
public void startBroadcast(BluetoothLeBroadcastSettings settings) {
    // 1. 使用广播参数配置LC3编码器
    // 2> 设置扩展广告信息，并添加相应的广播元数据
    // 3> 根据流传输参数设置周期性广告功能
    // 4> 通过HCI创建BIG对象
    // 5> 开始在BIS通道上发送ISO格式的数据

<原生实现方式：>

• broadcaster.cc / broadcaster_impl：负责管理广播连接的生命周期。

• 使用广播名称和元数据来配置扩展广告功能。

• 配置周期性广告，以传输BASE（广播音频源端点）数据结构。

• 创建包含适当数量BIS流的BIG对象。

• 将编码后的音频数据路由到BIS数据路径中。

12. 客户端端实现

“客户端”指的是单播客户端，通常就是用户的手机。该客户端负责发现、连接并控制LE Audio设备。

连接流程

以下是您连接LE Audio耳塞时所经历的步骤：

连接流程包括：BLE扫描与设备发现、GATT连接、服务发现（查找PACS、ASCS、CSIP、VCS）、读取PAC记录以了解音频功能、读取CSIS以确定是否属于协调组，随后进行ASE配置（配置编解码器、服务质量等），最后创建CIS并开始音频流传输。

AOSP客户端实现细节

步骤1-3：设备发现与连接

// LeAudioService.java
public void connect(BluetoothDevice device) {
    // 为该设备创建一个新的LeAudioStateMachine对象
    LeAudioStateMachine sm = getOrCreateStateMachine(device);
    sm.sendMessage(LeAudioStateMachine.CONNECT);
    
    // 这个状态机负责处理以下操作：
    // - GATT连接流程
    // - 服务发现过程
    // - 特性读取操作
}

LeAudioStateMachine负责管理整个连接生命周期：

// LeAudioStateMachine.java (简化版)
class LeAudioStateMachine extends StateMachine {
    
    class Disconnected extends State {
        void processMessage(Message msg) {
            if (msg.what == CONNECT) {
                // 通过原生接口启动GATT连接
                mNativeInterface.connectLeAudio(mDevice);
                transitionTo(mConnecting);
            }
        }
    }
    
    class Connecting extends State {
        void processMessage(Message msg) {
            if (msg.what == CONNECTION_STATE_CHANGED) {
                if (newState == CONNECTED) {
                    transitionTo(mConnected);
                }
            }
        }
    }
    
    class Connected extends State {
        void enter() {
            // GATT服务已发现
            // 音频功能信息已获取
            // 设备已准备好进行流传输
            broadcastConnectionState(BluetoothProfile.STATE_CONNECTED);
        }
    }
}

步骤4-6：功能识别

底层模块会读取PACS文件，以了解远程设备支持哪些功能：

// 在le_audio_client_impl（C语言实现）中
void OnGattServiceDiscovery(BluetoothDevice device) {
    // 从PACS文件中读取相关数据
    ReadPacsCharacteristics(device);
    
    // 读取CSIS信息以获取协调设置详情
    ReadCsisCharacteristics(device);
    
    // 读取ASCS信息以获取ASE的数量及状态
    ReadAscsCharacteristics(device);
}

void OnPacsRead(BluetoothDevice device, PacRecord sink_pac) {
    // sink_pac中包含以下信息：
    //   codec_id: LC3
    //   sampling_frequencies: 48000, 44100, 32000, 24000, 16000, 8000
    //   frame_durations: 10ms, 7.5ms
    //   channel_counts: 1
    //   octets_per_frame: 40-155 （对应不同的比特率）
    //   supported_contexts: MEDIA, CONVERSATIONAL, GAME
    
    // 将这些功能信息保存起来，以便后续进行编解码器配置协商
    device_info.sinkcapabilities = sink_pac;
}

步骤7-12：流媒体设置

当音频播放开始时，客户端会配置并启用相应的流媒体通道：

// 在codec_manager（C语言实现）中
CodecConfig SelectCodecConfiguration(
    PacRecord remote_capabilities,
    AudioContext context  // 如MEDIA、CONVERSATIONAL等
) {
    // 对于媒体播放，优先选择高质量配置：
    //   48 kHz采样频率，10ms的帧长，每个通道32 kbps的比特率
    
    // 对于语音通话，则需要优化延迟：
    //   16 kHz采样频率，7.5ms的帧长，每个通道32 kbps的比特率
    
    // 进行协商，选择双方都支持的最佳配置方案
}

// 在le_audio_client_impl中
void GroupStreamStart(int group_id, AudioContext context) {
    auto group = GetGroup(group_id);
    auto codec_config = SelectCodecConfiguration(
        group->GetRemoteCapabilities(), context);
    
    // 遍历组中的每个设备：
    for (auto& device : group->GetDevices()) {
        // 遍历设备上的每个ASE：
        for (auto& ase : device->GetAses()) {
            // 步骤8：配置编解码器
            WriteAseControlPoint(device, OPCODE_CONFIGCodec, {
                .ase_id = ase->id,
                .codec_id = LC3,
                .codec_specific = {
                    .sampling_freq = 48000,
                    .frame_duration = 10ms,
                    .channel_allocation = LEFT,  // 或RIGHT
                    .octets_per_frame = 120
                }
            });
        }
    }
    // 在编解码器配置完成后，进行后续操作：
    //   步骤9：配置QoS参数 → 步骤10：启用流媒体传输 → 步骤11：创建CIS信息
}

步骤13：音频数据流动过程

一旦开始流媒体播放，音频数据就会按照以下方式在AOSP框架中传递：

上图展示了LE Audio流媒体传输过程中音频数据流动的路径：来自Android音频框架的PCM音频数据首先到达蓝牙音频HAL层，然后被LC3编码器进行编码，随后被打包成带有时间戳的ISO SDU格式的数据包，通过HCI协议发送给控制器，再通过CIS无线技术传输到耳塞设备中。在耳塞设备内部，这些数据包会由LC3解码器进行解码，最终被转换为音频信号并播放出来。

广播接收机制的实现

为了接收广播音频信号（例如Auracast功能），AOSP采用了以下实现方式：

// 广播接收流程（原生代码）
void OnBroadcastSourceFound(AdvertisingReport report) {
    // 解析广告数据以获取广播相关元信息
    BroadcastMetadata metadata = ParseBroadcastMetadata(report);
    
    // 显示相关信息，例如：“机场B47登机口——英语频道”
    NotifyBroadcastSourceFoundmetadata);
}

void SyncToBroadcast(BroadcastMetadata metadata) {
    // 1. 与周期性广告信号同步
    HCI_LE_Periodic_Advertising>Create_Sync(metadata.sync_info);
    
    // 2. 当与广播信号的同步建立后，解析BASE数据
    BASE base = ParseBASE(periodic_adv_data);
    
    // 3. 选择相应的子组及BIS流
    // 4. 与BIG信号同步
    HCI_LE_BIG_Create_Sync(base.big_params, selected_bis);
    
    // 5. 设置ISO数据传输路径
    HCI.LE_Setup_ISO_Data_Path(bis_handle, HCI_DATA_PATH);
    
    // 6. 开始接收并解码音频数据
}

13. 负责整体流程控制的状态机

AOSP的LE Audio实现机制实际上依赖于多个相互关联的状态机来完成各项功能：

连接状态机

该状态机负责管理所有设备的连接生命周期过程：

该状态图清晰地展示了LE Audio连接状态机的四种状态变化过程：断开连接、连接中、已连接以及正在断开连接。

状态转换规则如下：当发生“连接”事件时，系统会从“断开连接”状态进入“连接中”状态；如果连接成功，就会进入“已连接”状态；而“断开连接”事件会导致系统返回“断开连接”状态；如果在尝试连接过程中出现超时或失败情况，系统同样会回到“断开连接”状态。

组音频状态机

该状态机用于管理由多台设备组成的音频组的运行状态：

<此状态图展示了群组音频的状态机，其包含以下几种状态：空闲状态、编解码器配置完成状态、服务质量配置完成状态、启用状态、流传输状态以及禁用状态。在音频流被建立起来的过程中，系统会按照一定的顺序依次经过这些状态；而“释放”操作则会使系统恢复到空闲状态。

各部分是如何协同工作的（代码演示）

以下是当你连接了LE Audio耳塞后，在音乐应用中按下“播放”按钮时，各项操作的具体流程的简化说明：

上图展示了当用户在使用LE Audio耳塞的音乐应用中按下“播放”按钮时，各项事件发生的先后顺序。

具体流程如下：

1. 音乐应用会将PCM音频数据写入到AudioTrack中。

2. Android的AudioFlinger会将这些音频数据转发给蓝牙音频HAL。

3. 蓝牙音频HAL会通知LeAudioService音频播放已经开始。

4. LeAudioService会查找当前处于活动状态的音频组，并在原生代码栈中触发GroupStreamStart函数。

5. 原生代码栈会通过向每只耳塞上的ASCS控制点发送指令，来配置这两只耳塞的相关参数（包括编码格式、服务质量设置等）。

6. 原生代码栈会通过HCI机制创建一个包含两个CIS通道的CIG结构。

7. 这两个CIS通道会被建立起来，以便音频数据能够在它们之间传输。

8. ISO数据传输路径也会被设置完毕。

9. PCM音频数据会从蓝牙音频HAL传递给LC3编码器，编码器会将这些音频数据压缩成帧结构。

10. 压缩后的帧会被作为ISO SDU格式的数据，通过HCI机制传输给控制器。

11. 控制器会在预定的时间间隔内，将这些帧通过无线信号发送出去。

12. 耳塞接收到这些数据后，会对其进行解码，并在规定的延迟时间内播放出来。

14. 整体流程概述：一个LE Audio数据包的“一天”

让我们追踪一下从一个音乐应用发送到耳塞的一个音频数据包的完整传输过程：

上图详细展示了音频数据包在LE Audio传输管道中经过的每一个环节。

从最顶端开始：音乐应用生成PCM音频数据，这些数据会通过Android的AudioFlinger传递给蓝牙音频HAL。蓝牙音频HAL会将每10毫秒内的480个样本（采样频率为48 kHz）压缩成一个约120字节的帧。

这个压缩后的帧会被封装成ISO SDU格式的数据包，其中会包含时间戳和序列号等信息，然后通过HCI机制传输给蓝牙控制器。控制器会将这些SDU数据分割成链路层的PDU格式，然后在下一个预定的传输间隔内，通过协商好的物理层协议（例如2M PHY协议）将这些数据发送出去。

在耳塞端，控制器会接收这些数据包，重新组合ISO SDU格式的数据，然后将LC3帧传递给耳塞中的解码器。解码器会将这些数据还原成480个PCM采样值，这些采样值会被暂时存储起来，直到达到预定的显示延迟时间点，之后才会被发送到扬声器驱动芯片中进行播放。

总延迟：从手机到耳机的延迟约为40毫秒（其中包括10毫秒的帧处理时间、数据传输延迟以及音频呈现延迟）。相比之下，传统的蓝牙A2DP技术的延迟通常在100到200毫秒之间！

音频呈现延迟：实现同步的关键因素

音频呈现延迟是蓝牙LE Audio技术中的一个关键概念。这种延迟是在数据流建立阶段由双方共同确定的固定值。所有音频内容都必须严格按照以下公式进行播放：

渲染时间 = 参考点位置 + 音频呈现延迟

这样的设计能够确保：

• 左右耳机的音频会同时被播放出来

• 即使数据传输在两个声道之间存在差异，也不会影响音频的同步播放

• 音频呈现延迟为接收端提供了“缓冲区”，有助于消除信号抖动

可以把这个过程想象成合唱团指挥：“所有人都在数字‘3’的时候开始唱歌，不能提前也不能推迟，必须正好在‘3’这个时刻。”

15. 总结

蓝牙LE Audio可以说是自蓝牙音频技术诞生以来最重要的升级。让我们回顾一下它的优势：

它解决了哪些问题

• 更优秀的编解码器（LC3）——在相同的比特率下能够提供更好的音质，或者在较低的比特率下保持同样的音质

• 多数据流传输——不再需要使用中继耳塞结构，从而延长电池续航时间

• 广播音频功能（Auracast）——支持一对多的音频传输，为新的应用场景打开了大门

• 适用于助听器——终于有了一个标准化、可互操作的解决方案

• 统一的音频处理机制（BAP）——无论是播放音乐还是接听电话，都使用相同的设置，无需在A2DP和HFP模式之间切换