跳到正文
5月27日周三
  1. 声网博客52

    语聊房还是直播间:RTC 100–400ms 对 CDN 直播 10–30 秒

    文章对比两条技术路径:语聊房走 RTC/UDP 通道(端到端 100–400ms,靠 FEC/ARQ 抗抖动),直播间走 RTMP 推流 + HLS/FLV 拉流(10–30 秒,低延迟 FLV 约 1–3 秒),并以 Yalla(纯 RTC、单房 2000 人)与荔枝(CDN 直播 + 偶尔连麦)说明选型差异,指出混合架构需维护两套延迟体系、排查成本高。

5月19日周二
  1. 声网博客22

    声网 SD-RTN 的全球节点调度算法:如何实现毫秒级延迟

    声网 SD-RTN 通过在全球部署 250 多个数据中心,用持续链路探测与实时并行计算调度数据流路由,实现毫秒级超低延迟传输。调度不只看平均延迟,还关注特定时延内的包投递成功率,并综合节点负载、QoS 要求和业务类型选路。面对突发故障,系统以多路并发冗余在可靠性与带宽成本间取舍,并针对不同区域网络特性做适配优化。

5月18日周一
  1. 声网博客58

    声网解读自建实时传输网络 SD-RTN 的调度与质量保障指标

    SD-RTN 以全球 200 多个数据中心(文中另处称 250+)组成软件定义实时网,用基于 UDP 的多路复用传输协议与智能调度系统做动态路由;对外给出分档质量承诺:200ms 内包到达率 99.9%(RTC)、800ms(极速直播)、2s(一般直播),并说明 FEC、自适应码率等弱网对抗手段与传输层加密、抗 DDoS 机制。

    推荐理由:厂商自述底层传输网的架构与可量化 SLA 指标,是理解 RTC 私有传输网络的直接材料。

5月12日周二
  1. 海外技术动态60

    "空闲"并不空闲:Linux 内核优化如何变成 QUIC CUBIC 拥塞窗口钉死 bug

    Cloudflare 排查了一个 QUIC 性能问题:CUBIC 拥塞窗口被钉在最小下限导致吞吐骤降,根因与内核空闲判断优化有关,修复方法是正确测量空闲期、区分 RTT 等待与真正的应用空闲。

    推荐理由:QUIC 拥塞控制在真实生产环境的排障案例,对所有 QUIC 媒体传输方有参考价值。

5月9日周六
  1. 声网博客64

    声网详解 WebRTC Simulcast 多流传输与 SFU 选择性转发

    发送端同时编码 1080p/720p/360p 三路流(约 2Mbps/1Mbps/300Kbps),SFU 按订阅关系只转发合适的一路;文章覆盖 SDP 的 ssrc-group:SIM 与 RID 协商、setParameters 编码参数配置、切换时的 PLI/FIR 关键帧请求优化,以及与 SVC 在带宽消耗和兼容性上的对比。

    推荐理由:完整覆盖 Simulcast 从协商、实现到 SFU 转发的工程细节,并给出移动端编码负担的权衡。

5月8日周五
  1. 声网博客62

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

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

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

  2. 声网博客76

    OpenAI WebRTC 重构:Relay 与 Transceiver 分离

    针对“一会话一端口”与有状态 ICE/DTLS 会话在 Kubernetes 下的扩容冲突,OpenAI 将数据包路由与协议终止分离:Relay 只做无状态 UDP 转发并借 ICE ufrag 编码路由信息实现首包确定性投递,Transceiver 用 Go+Pion 运行完整 WebRTC 端点;该架构已全量上线,支撑 9 亿周活用户的实时媒体流量,客户端无感知。

    推荐理由:罕见的基础设施级披露,展示超大规模实时语音服务的 WebRTC 架构取舍与开源栈的生产验证。

  3. 声网博客66

    声网解析 SFU、MCU 与 P2P 架构差异及选型依据

    以 10 人会议量化三种架构的带宽与计算分布:P2P 每人需维护 9 条连接(约 18Mbps 上行),SFU 把客户端上行降到 1 路但服务端产生约 100Mbps 转发量,MCU 客户端压力最小但编解码计算成本最高;并给出 Simulcast/SVC、分层 SFU、CDN+RTC 混合等增强方案与适用场景。

    推荐理由:用具体数字讲清三种媒体服务器架构的成本结构与选型逻辑,是 RTC 架构选型的完整参考。

5月7日周四
  1. 声网博客62

    声网拆解首帧渲染时间:从信令到渲染的分段优化方法

    把首帧时间拆为信令连接、ICE 协商、设备初始化、编码传输、解码渲染五段分别埋点统计;优化手段包括信令就近部署与预连接、Trickle ICE 边收集边检查、进入大厅即预初始化摄像头、首帧降码率与优先传输、以及进度提示与头像占位;并分场景给出策略——1v1 追求绝对速度、多人会议分批加载防设备过载、直播权衡首帧与缓冲。

    推荐理由:首帧优化的完整方法论,分段统计与分场景策略可直接用于体验优化。

5月6日周三
  1. 声网博客60

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

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

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

4月24日周五
  1. 中文技术动态58

    腾讯云 TWeTalk 与 TRTC 软硬一体方案:AI 语音对话全链路延迟压至 1 秒内

    源自腾讯全球数字生态大会的分享:TWeTalk 智能硬件 AI 对话方案与 TRTC 组成端云协同架构,音视频端到端延迟稳定低于 300ms,AI 语音对话全链路延迟压缩至 1000ms 以内,并指出长对话上下文丢失率约 12%、中英混杂识别错误率约 8% 的行业痛点。

    推荐理由:腾讯云在智能硬件 AI 对话方向的代表性方案,含明确延迟与痛点数据。

4月17日周五
  1. LiveKit Blog70

    LiveKit 逐项对比语音 Agent 两种架构:STT-LLM-TTS 级联与端到端 Realtime

    LiveKit 对照级联管线(STT-LLM-TTS)与实时端到端(S2S)模型在延迟、工具调用、话轮检测、语音自然度、可控性与调试、成本、合规与电话场景上的差异:实时模型在情绪与韵律感知、串行开销上有结构优势,但工具调用准确率与可定制性较弱;管线在每层可观测、可替换、可在文本层脱敏 PII、可做区域数据驻留上更可控,但需要靠流式重叠(部分转写进 LLM、token 边到边进 TTS)才能压到接近实时模型。文章另给出两种混合方案:realtime 模型配独立 STT,以及半级联(realtime 只出文本、由独立 TTS 出声)。并指出电话网络为 8kHz G.711 音频,而实时模型多按 16–48kHz WebRTC 音频训练,呼叫中心场景管线通常更可靠。

    推荐理由:语音 Agent 架构选型的系统性对照,覆盖延迟、工具调用与合规等实际决策维度。

4月16日周四
  1. LiveKit Blog64

    LiveKit 用观察者模式做语音 Agent 护栏:后台模型读转录并向上下文注入处置

    LiveKit 给出观察者模式(observer pattern)的完整实现:通过 AgentSession 的 conversation_item_added 事件旁路监听转录,用更强、可更慢的独立 LLM 异步做策略分类,再以 update_chat_ctx 把护栏指令作为系统消息注入主 Agent 上下文,主 Agent 在下一轮生效,全程不阻塞对话;必要时观察者可直接结束通话或接管控制。示例中主会话使用 gpt-4.1-mini、观察者使用 gpt-4.1,并以网约车乘客被司机要求线下现金支付的违规场景演示分类与响应分离。文章还列出三项工程细节:同一违规类型每会话最多注入一次、并发保护确保同时只跑一次评估且不丢用户轮次、以及 JSON 解析失败的兜底。

    推荐理由:把安全策略与对话模型解耦的可复用工程模式,直接缓解复杂护栏挤占对话能力的问题。

4月13日周一
4月2日周四
  1. 海外技术动态52

    Ant Media 对比 WebRTC 与 MoQ 选型差异

    文章从传输层(UDP/DTLS-SRTP 对 QUIC/WebTransport)、架构(SFU 对 pub/sub relay)、浏览器支持与生产成熟度逐项对比两种协议,指出 WebTransport 在 2026 年仍只占网页加载的极小比例,而 Safari iOS 26.4 刚宣布支持 WebTransport;建议交互场景继续用 WebRTC、面向 2028 年的大规模分发再准备 MoQ。

4月1日周三
  1. LiveKit Blog62

    LiveKit 拆解 talker-reasoner 模式:快慢双模型加异步工具,让语音 Agent 不阻塞

    LiveKit 介绍 subagent delegation(又称 talker-reasoner、快脑慢脑)模式:每个会话轮次由延迟优化的主 Agent(示例用 google/gemma-4-31b-it)处理,需要多步推理或慢工具的任务交给后台推理模型(示例用 google/gemini-3.1-pro),两者仅通过一个异步工具连接——主 Agent 调用后首次进度更新即释放对话,可继续应答或追问,子 Agent 结果在空闲时以追加回复返回,且会话历史不进入子 Agent 以保持轮次成本低。文章同时给出不适用情形:答案需先核实(价格、医疗建议)、单个快模型已够用、主 Agent 无事可做只能念填充话术、以及通话普遍短于 30 秒。

    推荐理由:面向长耗时推理的语音 Agent 编排模式,给出了可落地的分工与适用边界。

3月3日周二
  1. 海外技术动态60

    直播编码新趋势:用 VMAF 直接驱动码率控制闭环

    Streaming Learning Center 盘点直播编码器把感知质量指标纳入率控闭环的进展:MainConcept 的 VMAF-E 以实时 VMAF 代理在编码序内驱动率控,Synamedia 用 pVMAF 实现按频道的画质目标与优先级调度,Meta 与 FFmpeg 7.0+ 将 PSNR/SSIM/VMAF 用于实时监控与机群可视化。文章建议采购直播编码器时重点确认三件事:是否暴露可独立验证的指标、指标是否在率控环内、能否按频道设定画质目标。

    推荐理由:质量指标从离线评估走向在线率控是直播编码的重要工程趋势,文中给出可落地的采购核查清单。

2月10日周二
1月26日周一
  1. 中文技术动态68

    火山引擎 RTC 支撑抖音百万并发"云侃球":单房间 500 人、9 人上麦的边看边聊架构

    文章拆解抖音世界杯"边看边聊"方案:单房间 500 人加入、9 人上麦、其余旁听,对比语音聊天室与 RTC 互动语聊两种方案后选择后者以避免 CDN 转推 1-3 秒的聊天不同步,RTC 通话语音切片存储供审核并提供踢人/拉黑运维 OpenAPI。

    推荐理由:字节系大型赛事语聊场景的第一手工程架构文,含方案选型对比。

1月19日周一
  1. 声网博客52

    声网讲解 SRT 协议:选择性重传、AES 加密与延迟窗口权衡

    SRT 基于 UDP 引入序列号与时间戳,用选择性自动重传替代 TCP 的顺序阻塞重传以避免队头阻塞,并可在配置的延迟窗口内换抗丢包能力;协议层内置 AES-128/256 端到端加密、传输层统一时间基准做音视频同步、仅出站连接简化防火墙穿透,还持续监测丢包/RTT/带宽/抖动以自适应调整;定位为专业直播与远程制作的低延迟传输方案。

1月14日周三
  1. 声网博客52

    声网梳理媒体鲁棒性四层防线:编码加固、动态适配与错误隐藏

    把抗弱网能力分为四层:发送前加固(抗错编码、I 帧最高保护等级的不平等保护、FEC 冗余)、传输中动态适配(实时探测带宽/丢包/延迟/抖动并调码率、按延迟预算决定是否重传)、接收端补救(运动补偿错误隐藏、FEC 解码恢复)、系统级协同(Wi-Fi 与蜂窝多路径传输、按接收者网络选发低码率高保护流)。

1月10日周六
  1. 声网博客22

    声网对话式 AI 引擎:2 行代码 15 分钟搭建 24 小时 AI 客服

    声网推出对话式 AI 引擎,主打 2 行代码、15 分钟快速构建 AI 客服智能体,集成 ASR、NLP、LLM 与 TTS 全链路。其端到端响应延迟控制在 650 毫秒以内,打断响应为 340 毫秒,并可抑制高达 95% 的环境人声与背景噪声。接入需开通服务、集成 v4.5.1 及以上实时互动 SDK,并配置 LLM 与 TTS 供应商信息。

1月4日周日
  1. 声网博客54

    声网解析丢包容错(PLC):插入、插值与重构三类算法

    按发送端丢包恢复与接收端 PLC 两条线展开:发送端靠 FEC 与低比特冗余,接收端 PLC 不占额外带宽、不增延迟,分插入、插值(波形替换、音高波形复制、时域校正,G.711 采纳音高复制)与基于重构的合成(如 G.723.1 插值线性预测系数)三类,并说明 PLC 常与 FEC、自适应码率配合使用。

12月24日周三
  1. 声网博客50

    声网讲解自适应媒体质量控制:码率、分辨率与帧率的协同调节

    按“感知—评估—决策—调整—反馈”闭环组织:持续监测吞吐、丢包、RTT、抖动与缓冲趋势做带宽估计,检测到丢包上升、RTT 增大或缓冲积压即启动拥塞控制,再渐进式调整码率、分辨率、帧率与编码结构以避免大幅波动;定位为 RTC、互动直播与弱网移动场景的核心支撑技术。

12月19日周五
12月3日周三
11月4日周二
3月3日周一
  1. Cartesia Blog29

    如何用 Cartesia API 构建语音 AI 智能体:从架构到生产部署的分步指南

    用 Cartesia API 和 Sonic 模型可在 Python 中搭建语音 AI 智能体,流程为语音识别转文本、LLM 生成回复、再由 Sonic 合成自然语音。教程要求准备 Cartesia 账号、API key 并安装 FFmpeg,语音识别可选用 Whisper、Deepgram 等服务,也可借助 LiveKit、VAPI 或 RASA 平台快速起步。