为什么选择 LiveKit
在实时语音 AI 场景里,很多团队起初只盯着音频传输能不能通,但真正落地时会发现更多坑:连接稳定性、会话管理、设备控制、Agent 协同以及扩展能力。LiveKit 的价值在于它不仅是传输层,更是一个面向实时 AI Agent 的平台能力层,统一了房间、参与者、媒体轨道和数据通道能力。
官方定位很明确:构建 voice / video / physical AI agents 的平台。
BK7258 工程架构解析
结合 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 管实时连接。
适配总体流程
实际落地通常遵循这条链路:
- 设备启动:初始化板级外设、音频驱动、任务和事件系统
- 网络就绪:配网成功后,状态机从 NET_* 进入可激活/可连云状态
- 协议层初始化:打开 CONFIG_PROTOCOL_USE_LIVEKIT 后,走 LiveKit 协议分支
- 进入房间:调用 join_room(),构建 room options,准备 server_url/token
- WebRTC 建链:完成 JOIN、addTrack、Offer/Answer、ICE trickle
- 音频上行/下行闭环:上行将 mic Opus 帧送入 LiveKit,下行订阅音频帧写入喇叭播放
- MCP 设备控制扩展(可选):通过 tools/list 与 tools/call 把'语音问答'扩展到'语音控制设备'
关键配置项
配置阶段,这几个宏开关是关键:
CONFIG_LIVEKIT=yCONFIG_PROTOCOL_USE_LIVEKIT=yCONFIG_PROTOCOL_IOT_MCP=y(如果需要设备工具调用)
音频相关 Opus/AEC/VAD 配置需与云端策略匹配。实践建议先只保留 LiveKit 主链路,尽量减少并发变量(WSS/MQTT 先关),跑通连接与音频后再叠加 UI、摄像头、外设控制。
音频链路是成败核心
整个适配过程中,最关键的是把端侧音频回调和 LiveKit 媒体接口打通:
- 采集侧:音频驱动回调拿到 Opus 帧
- 发送侧:调用引擎发送接口推到 LiveKit 房间
- 接收侧:订阅远端音频帧
- 播放侧:写入 bk_aud_intf_write_spk_data() 到喇叭
最短闭环就是:Mic -> Opus -> LiveKit -> Agent/TTS -> LiveKit -> Speaker。只要这条链路稳定,后续能力都能围绕它扩展。



