BK7258 接入 LiveKit WebRTC：端侧适配实践

为什么选择 LiveKit

做实时语音 AI 时，很多团队起步只盯着'音频能不能传'，真落地才发现坑更多：连接稳不稳、会话怎么管、设备如何协同。LiveKit 的价值在于它不只是传输层，更是一个面向实时 AI Agent 的平台能力层，统一了房间、参与者、媒体轨道和数据通道。

简单来说，它帮你把 voice / video / physical AI agents 的构建标准化了。

工程架构解析

基于 projects/livekit/ 工程，核心模块分工很明确：

• main/app_main.c：系统启动入口，负责拉起核心模块。
• main/dialog_component/system_manager/system_manager.c：全局状态机，管网络、激活、会话、录音和播放的状态流转。
• main/dialog_component/dialog/dialog_module.c：处理麦克风采集和喇叭播放。
• main/dialog_component/protocols/protocol.c：协议统一门面，兼容 WSS/MQTT/LiveKit。
• main/dialog_component/protocols/protocol_livekit.c：LiveKit 协议的具体入口。
• main/example.c：执行 join_room()，完成房间创建与连接。
• components/livekit/core/engine.c：LiveKit 引擎状态机，处理信令与媒体通路。

核心逻辑其实很清晰：system_manager 管流程，dialog_module 管音频，livekit engine 管实时连接。

适配总体流程

实际落地通常遵循这条链路：

1. 设备启动：初始化板级外设、音频驱动、任务和事件系统。
2. 网络就绪：配网成功后，状态机从 NET_* 进入可激活或可连云状态。
3. 协议层初始化：打开 CONFIG_PROTOCOL_USE_LIVEKIT 后，走 LiveKit 协议分支。
4. 进入房间：调用 join_room()，构建 room options，准备好 server_url 和 token。
5. WebRTC 建链：完成 JOIN、addTrack、Offer/Answer、ICE trickle。
6. 音频上行/下行闭环：上行将 mic Opus 帧送入 LiveKit，下行订阅音频帧写入喇叭播放。
7. MCP 设备控制扩展（可选）：通过 tools/list 与 tools/call 把'语音问答'扩展到'语音控制设备'。

关键配置项

配置上建议先确认这些宏开关：

CONFIG_LIVEKIT=y
CONFIG_PROTOCOL_USE_LIVEKIT=y
CONFIG_PROTOCOL_IOT_MCP=y // 如果需要设备工具调用

音频相关的 Opus/AEC/VAD 配置也要和云端策略匹配。

实践建议是：先只保留 LiveKit 主链路，尽量减少并发变量（WSS/MQTT 先关）。先跑通连接与音频，再叠加 UI、摄像头、外设控制。

音频链路：适配成败的关键

BK7258 适配里，最关键的是把端侧音频回调和 LiveKit 媒体接口打通：

• 采集侧：音频驱动回调拿到 Opus 帧。
• 发送侧：调用引擎发送接口推到 LiveKit 房间。
• 接收侧：订阅远端音频帧。
• 播放侧：写入 bk_aud_intf_write_spk_data() 到喇叭。

最短闭环就是：Mic -> Opus -> LiveKit -> Agent/TTS -> LiveKit -> Speaker。只要这条链路稳定，后续能力都能围绕它扩展。