https://sonictl.github.io/categories/technology/Recent content in Technology on Combine Art and SciencesHugoen-usSat, 30 May 2026 19:03:00 +0800https://sonictl.github.io/posts/p20260530191618/Sat, 30 May 2026 19:03:00 +0800https://sonictl.github.io/posts/p20260530191618/webSocket 传输语音不连续（几百毫秒断音）的根因及解决方法 一般有 4 个关键问题，它们共同导致了接收方语音出现几百毫秒的断音： 🔴 问题 1：环形缓冲区欠载（最严重） 位置: audio-worklet.js 第 60 行 buffer: new Float32Array(this._frameSamples * 8), // 8帧缓冲 (~480ms) 8 帧 = 480ms 缓冲，但解码器输出是异步的，网络抖动 + 编解码延迟很容易超过 480ms 更关键的是：_frameSamples 在 config 消息更新后才重新计算，但 初始创建 peerBuffer 时使用的是旧的 _frameSamples 值。如果 config 消息在第一个 pcm 数据到达之后才到达，缓冲区大小会算错 欠载后直接重置为未就绪状态（第 155 行），导致重新预缓冲，造成连续断音 🔴 问题 2：解码器输出直接推入 Worklet，无缓冲预填 位置: client.js 第 260-270 行 output: (audioData) => { // 解码完成 → 立即发送 PCM 到 Worklet workletNode.port.postMessage({ type: 'pcm', peerId: peerId, data: pcmForPlayback }); } 解码器输出回调是异步的，可能多个帧同时到达 没有做预填缓冲（pre-buffering），Worklet 刚启动时立即欠载 没有做帧序号检测，乱序包直接解码可能导致错误 PCM 🔴 问题 3：无丢包隐藏（PLC） 当网络丢包或延迟抖动导致帧丢失时，Worklet 直接输出静音 没有重复上一帧或做简单的 PLC 🔴 问题 4：解码器创建时机问题 位置: client.