跳到正文
  1. Mux Blog62

    Mux 复盘基础码率阶梯:保留 270p 并新增 720p 后成本与画质如何变化

    Mux 将基础码率阶梯从 270p/480p/1080p 调整为 270p/480p/720p/1080p,于 4 月通过功能开关逐步上线。对比上线前后各一个月的数据,720p 交付分钟数从约十分之一升至约一半,480p 降至个位数百分比,270p 基本不变;每分钟交付字节增加约 6.5%,PTE 调优抵消近 5%,Video Quality Score 从 99.1 升至约 99.7,起播延迟改善、拖动延迟持平。Mux 曾评估删除 270p,实测折叠到 480p 的缓存效率收益有限,最极端情况仅打平,因此保留该档。

    推荐理由:Mux 用真实 CDN、存储与 QoE 数据复盘码率阶梯取舍,可迁移到自建转码阶梯的决策方法。

  1. 声网博客62

    声网讲解游戏语音质量评估:接通率、卡顿率、延迟与弱网恢复的排查方法

    声网发布游戏语音质量评估方法,把语音可用拆成加入频道、发布订阅、音频播放等环节,建议接通率按进入队伍后 5 秒内成功加入频道并接收至少一名队友音频来统计,持续低于 98% 视为链路存在系统性问题。排查上先查频道、订阅和音频路由状态再查网络,用 audioLossRate、frozenRate、networkTransportDelay、jitterBufferDelay、e2eDelay 和 mosValue 区分网络卡顿与客户端卡顿,并给出首版质量看板的八项核心指标。

    推荐理由:声网把游戏语音质量拆成接通率、卡顿率、延迟和弱网恢复四类指标,并给出可复用的排查顺序与看板指标。

  1. 声网博客62

    声网拆解游戏语音卡顿排查:从玩家反馈到 RTC 指标的质量监控方法

    声网发布游戏语音质量监控方法,把语音可用链路拆成开启语音、获取频道信息、加入频道、发布订阅、音频播放五个时间点,建议接通率以最后必要环节为准,持续低于 98% 通常说明存在系统性问题。文章结合 Unity RTC 回调给出排查顺序:听不到先查频道、OnRemoteAudioStateChanged 订阅状态和音频路由,再查网络;卡顿用 OnRemoteAudioStats 的 audioLossRate、frozenRate、jitterBufferDelay、e2eDelay 和 mosValue 区分网络与客户端问题,并建议质量看板先保留接通率、可听首帧时间、卡顿率、端到端延迟 P95 等八项指标。

    推荐理由:声网结合自家 Unity RTC 回调,把游戏语音从玩家反馈到指标看板的排查链路拆成可落地步骤。

  1. 声网博客62

    声网拆解 Voice Agent 延迟:STT、LLM、TTS 与 VAD 的可观测指标

    声网把 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 各段,并给出可采集的会话字段与仪表盘结构,适合直接对照搭建观测体系。

  1. LiveKit Blog66

    LiveKit 官方指南:诊断 LiveKit Agents 中的事件循环阻塞

    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 定位问题。

  1. 声网博客62

    声网讲解 RTC 网络探测:带宽、延迟、丢包与抖动的测量方法

    区分容量探测(主动加压测可用带宽上限)与被动估计(借 ICE 阶段 STUN/TURN 消息推断),强调探测目标应与实际通话服务器同节点、控制在 1-3 秒内、可后台预探测并设 30 秒级缓存有效期;并给出根据探测结果调整编码参数、提前提示用户、通话中被动监测加主动探测的闭环做法,以及 NAT 超时、移动网络切换对探测准确性的影响。

    推荐理由:弱网自适应的感知基础,方法、参数与坑位都讲得比较完整。

  1. 声网博客60

    声网拆解卡顿率、丢包率与延迟对 RTC 体验的差异化影响

    按场景给出指标优先级:强交互场景延迟是第一杀手(端到端超 400ms 对话节奏被破坏),内容消费场景卡顿最致命,音频质量敏感场景丢包率需严控;并说明三者连锁反应——丢包超 10% 时卡顿率通常同步上升,以及声网在教育、社交、会议场景的分层保障策略(大班课教师端 400ms 内、学生端 CDN 3-5 秒)。

    推荐理由:把延迟、丢包、卡顿三个指标放进场景比较优先级,对质量监控体系设计有直接参考价值。

已经到底了