为什么选择 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 管实时连接。
适配总体流程
实际落地通常遵循这条链路:
- 设备启动:初始化板级外设、音频驱动、任务和事件系统。
- 网络就绪:配网成功后,状态机从 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=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。只要这条链路稳定,后续能力都能围绕它扩展。


