技术方向
实时通信的技术与实践：SFU 架构、信令、端到端延迟、回声消除，以及 RTC 场景下的工程取舍。
60 条精选近 30 天 11 条共收录 150 条
mediasoup-client 3.23.0 移除 transport.produce() 的 headerExtensionOptions，改为 Device 层 forcedRtpExtensions 按扩展 URI 强制开/关；该能力目前仅最新 Chrome 支持 WebRTC RTP Extension Control API，并修复了 Canary 149 中 abs-capture-time 引发的 codec collision 报错。
推荐理由：浏览器 RTP 扩展控制能力落地到主流 SFU 客户端库，影响采集时间同步等特性接入方式。
LiveKit 发文梳理语音智能体对 yes、no、ok 等短语音应答失败的原因，指出回合结束需要 final_transcript 和 end_of_speech 两个事件同时满足，中间转写不会关闭回合。文章列举 STT 未生成最终转写、端点检测过于激进或过于宽松、噪声抑制误删短语音、SIP 通话质量差以及 backchannel 被误判为打断等成因，并给出对应做法，包括启用 transcription_timeout 做优雅恢复、turn_detection="stt" 时将 endpointing.min_delay 设为 0、按场景选择 voice isolation 或 background noise suppression、优先使用 G.722 等支持 HD voice 的编解码器，以及用自适应打断处理识别 backchannel。
推荐理由：LiveKit 官方梳理短语音回合检测失败的常见成因，并给出可逐项排查的配置与恢复手段。
声网发布游戏语音质量评估方法，把语音可用拆成加入频道、发布订阅、音频播放等环节，建议接通率按进入队伍后 5 秒内成功加入频道并接收至少一名队友音频来统计，持续低于 98% 视为链路存在系统性问题。排查上先查频道、订阅和音频路由状态再查网络，用 audioLossRate、frozenRate、networkTransportDelay、jitterBufferDelay、e2eDelay 和 mosValue 区分网络卡顿与客户端卡顿，并给出首版质量看板的八项核心指标。
推荐理由：声网把游戏语音质量拆成接通率、卡顿率、延迟和弱网恢复四类指标，并给出可复用的排查顺序与看板指标。
LiveKit 在 LiveKit Agents 中发布 expressive mode，用一个开关让语音智能体根据对话上下文调整语气。该模式在 LLM 提示中注入各家 TTS 的标记方言，由框架统一转换，并会把多句合并成更大块再送入 TTS，以稳定情绪和音高且不显著增加延迟。目前支持 Fish Audio、Inworld、Cartesia 和 SpaceXAI 的 LiveKit Inference 模型，前端可通过 lk.expression 属性获取情绪信号。
推荐理由：LiveKit 官方说明 expressive mode 如何把 LLM 输出转成各家 TTS 的情绪标记，并给出开启方式与前端联动做法。
声网发布游戏语音质量监控方法，把语音可用链路拆成开启语音、获取频道信息、加入频道、发布订阅、音频播放五个时间点，建议接通率以最后必要环节为准，持续低于 98% 通常说明存在系统性问题。文章结合 Unity RTC 回调给出排查顺序：听不到先查频道、OnRemoteAudioStateChanged 订阅状态和音频路由，再查网络；卡顿用 OnRemoteAudioStats 的 audioLossRate、frozenRate、jitterBufferDelay、e2eDelay 和 mosValue 区分网络与客户端问题，并建议质量看板先保留接通率、可听首帧时间、卡顿率、端到端延迟 P95 等八项指标。
推荐理由：声网结合自家 Unity RTC 回调，把游戏语音从玩家反馈到指标看板的排查链路拆成可落地步骤。
以东南亚移动热点（丢包 8%-15%）客户案例切入：丢包超 5% 时 MOS 从 4.2 降到 3.0 以下、端到端超 400ms 对话节奏被破坏、抖动超 30ms 音频变调；工程上采用 ULPFEC 不均等保护（I 帧与音频 30%-50% 冗余、P 帧 10%-20%，20% 丢包下恢复率约 70%）、动态 Jitter Buffer 在 80-200ms 间伸缩，并观察到 BBR 在移动网络带宽突降时收敛比 GCC 快约 1.5 倍。
推荐理由：有案例、有阈值、有参数取舍的弱网优化实战记录，FEC 分级与缓冲策略可直接借用。
LiveKit 官方文章聚焦 agent 加入延迟，即后端请求 agent 到 agent 就绪进入房间的时间，并指出用户侧表现为持续响铃、静音、头像黑屏、客户端超时或提前离开。文章列出常见原因：LiveKit Cloud 上 Build 计划会缩容到零导致冷启动，自托管需维护预热进程池并调整 num_idle_processes，入口点阻塞代码和过大的容器镜像也会拖慢加入，虚拟形象会额外增加一个参会者并处于关键路径上。排查时可记录显式 dispatch 前与 await ctx.connect() 返回后的时间戳，并通过 job metadata 传递 ID 关联两条日志。
推荐理由：LiveKit 官方拆解 agent 加入房间延迟的成因与排查路径，自托管团队可据此定位冷启动和扩容问题。
Tsahi 以客户案例论证 WebRTC 与 SIP 的媒体质量上限相当（都走 RTP/SRTP），质量问题常被误判为协议问题；他主张在改架构前先用 getStats() 做客户端侧全量采集，因为服务端指标“只能看到一半故事”，有观测后定位问题可从数天缩短到数分钟，并明确反对在数据不足时切换 SFU、盲目上 AV1 或追逐 MoQ。
推荐理由：对“换栈解决问题”倾向的纠偏，强调客户端可观测性优先于架构决策。
声网把 Voice Agent 的端到端延迟拆成 RTC 延迟、算法前处理延迟、ASR 延迟、LLM 延迟和 TTS 延迟，启用数字人时再加渲染延迟，并给出各段典型范围，如 RTC 150-300 ms、ASR 末字延迟 400-700 ms、LLM 首字节 250-1000 ms、TTS 首字节 100-350 ms。文章建议按轮次记录 session_id、turn_id、asr_final_ts、llm_first_token_ts、tts_first_audio_ts、interrupt_detect_ts 等字段，并分别观测 ASR 的 TTLW 与 WER、LLM 的 TTFB 与 TTFS、TTS 首帧音频、VAD 的起止检测延迟和打断成功率。选型阶段可用声网 AI 模型评测平台对比 ASR、LLM、TTS 组合的 P50、P90、P99 延迟与成本，上线后再用会话级 trace 定位瓶颈。
推荐理由：把 Voice Agent 的端到端延迟拆成 RTC、ASR、LLM、TTS、VAD 各段，并给出可采集的会话字段与仪表盘结构，适合直接对照搭建观测体系。
LiveKit 发布指南，说明 LiveKit Agents 每个任务运行在独立子进程中，由 supervisor 通过事件循环上的 ping/pong 健康检查监控，循环阻塞会导致响应延迟、进程被杀并在约 15 秒内被新实例替换。内置事件循环监控在 Python livekit-agents 1.8.1+ 和 Node.js @livekit/agents 1.9.1+ 默认开启，对 100ms 及以上的停顿告警并给出阻塞代码行，排查可用 py-spy、asyncio debug 模式和 Node.js 事件循环延迟测量。
推荐理由：LiveKit 官方梳理了阻塞事件循环的日志特征与排查手段，可对照自家 Agent 的告警和 trace 定位问题。
LiveKit 正式发布 Unity SDK v2.0.0，将其从开发者预览转为正式版本，并称该 SDK 已与现有 LiveKit SDK 达到功能对齐。开发者可在 Unity 游戏中接入实时语音、视频和 AI，用于语音聊天、音视频直播、VR 远程操控机器人以及语音 AI 驱动的 NPC。2.0.0 带来移动端和桌面端的原生平台音频、基于 DataTracks 的高频数据消息和可配置 token 源的简化鉴权；官方支持 Unity 2022.3 及以上版本，覆盖 macOS、Windows、Linux、iOS 和 Android。
推荐理由：LiveKit Unity SDK 结束开发者预览并达到与其他 SDK 的功能对齐，可据此判断现有 Unity 项目是否迁移。
Agora 实验室用 iPhone 13 加人工发声设备、可控网络模拟丢包、双轨录音逐帧取时、每项 n=30 的方法测试三代 ChatGPT 语音模式：GPT-Live-1 正常网络中位响应 1099ms（P90 1203ms、SD 104ms），Advanced Voice Mode 为 1304ms（P90 2318ms、SD 489ms），Standard 级联模式 5197ms；10% 上行丢包下 GPT-Live 仅增 314ms，同级丢包的 P90 仍优于零丢包的上一代；插话停止延迟中位数 1399ms 比上一代慢 498ms，但背景人声误触发从 22 次降到 1 次。
推荐理由：方法论透明、样本量与局限都交代清楚的端到端延迟实测，弱网下的对比尤其有信息量。
Cartesia 发布语音转文本模型 Ink-2，面向实时语音代理，称其在 Artificial Analysis 流式榜单上以最低词错误率排名第一，并内置语义端点检测。官方数据显示其 Time-to-Final-Transcript 为 0.1s，在 14 种英语口音的 AppTek 基准上 WER 为 8%，内部生产环境基准 WER 为 6.5%，轮次检测 F1 为 93%。Ink-2 已在 play.cartesia.ai 上线，可通过 API 使用，并接入 LiveKit、Vapi 和 Pipecat，多语言支持尚在开发中。
推荐理由：官方给出 Ink-2 在准确率、轮次检测和延迟三项指标上的对比数据，可据此判断语音代理的选型取舍。
Tavus 宣布 PAL 可像邀请同事一样加入 Google Meet：开摄像头、跟随对话并实时应答，可做会议记录、随行销售通话或主持站会；官方称 Zoom 与 Microsoft Teams 支持为下一步。
推荐理由：AI 视频智能体深度嵌入主流视频会议平台，是行业级产品动作。
腾讯云游戏用自研 Tencent-RTC 做抗抖动与网络自适应：发送端缓存视频帧、接收端按网络动态调缓冲深度，并用预测算法生成中间帧补偿丢包；传输上基于 UDP 并叠加 FEC 与 ARQ，按数据类型（游戏指令、视频帧、音频）设差异化优先级；量化表现为稳定网络下端到端 50-70ms，盛趣游戏案例做到 1080P/60 帧下延迟小于 40ms，全球部署 2000+ 边缘节点。
推荐理由：云游戏这一延迟最敏感场景的厂商实测数据与机制说明，40ms/1080P60 的案例有参考价值。
把弱网定义为高丢包（10%-30%）、高延迟高抖动、低带宽三维度同时恶化；音频侧 FEC 在 20% 丢包下几乎无感、PLC 在 60%-80% 丢包仍可懂、可降至 Opus 6kbps 在 30kbps 网络上保语音不断；视频侧自适应码率加 SVC 平滑降级、关键帧优先保护、帧率优先于分辨率；并引即构数据：音频抗 80% 丢包、视频抗 70%、抖动容忍 1000ms、带宽可压至 30kbps。
推荐理由：按音频/视频/传输/业务四层给出弱网策略清单，附厂商实测基线数据。
把弱网分为带宽抖动、高丢包、高延迟、持续拥塞四类，对应三件武器——自适应编码动态调码率与量化参数、弹性帧率从 60/120fps 平滑降到 30fps、关键帧与参考帧选择性重传；核心是用智能码控统一决策“降码率 vs 降帧率 vs 加重传”，避免编码器与重传模块策略打架导致总带宽失控。
推荐理由：讲清了多机制并发时的策略冲突与统一指挥思路，对自建弱网策略编排有启发。
用 Ookla 2025 数据定位战场：印尼移动均速 45.01Mbps（低于东南亚均值 91.79）、外岛 3G 常态，丢包超 10%、抖动超 100ms 时音频流明显劣化；给出四件套的适用边界——FEC 适合 10%-30% 丢包且 RTT>150ms（代价 10%-30% 带宽）、NACK 要求 RTT<150ms 且丢包<10%、Opus 从 32-64kbps 降级到 8-12kbps、动态 Jitter Buffer 工作范围 60-200ms，并强调本地节点对 RTT 的实质影响与 tc netem 测试方法。
推荐理由：少见的按目标市场网络实测数据反推弱网策略的实战文，参数边界清晰可落地。
LiveKit 基于自身实时基础设施发布面向机器人的遥操作、数据采集与远程推理生产级方案（LiveKit Portal），延续其在多参与者机器人场景的布局。
推荐理由：实时音视频进入物理 AI/机器人遥操作场景的代表性产品方案。
W3C Media Working Group 于 2026-06-08 同日发布 AV1、AVC/H.264、HEVC/H.265、Linear PCM、Vorbis、A-law PCM 六份 WebCodecs 注册规范（随后 9 月又补齐 Opus 与 MP3），逐一定义各编解码器的 codec 字符串、EncodedVideoChunk/AudioDecoderConfig 描述字节及 VideoEncoderConfig 扩展；这使浏览器低层编解码 API 在视频侧主要格式的互操作语义全部落到正式工作组出版物。
推荐理由：WebCodecs 是浏览器端自研转码/推流管线的基础 API，AV1 与 HEVC 注册定稿让 Web 侧编码策略有了可依赖的规范锚点。