WebSocket实现音轨同步的关键是逻辑时钟+时间戳+插值，通过服务端广播节拍事件校准客户端时钟，JSON传输结构化音符，缓冲与ScheduledTime抗抖动，版本号保障状态收敛，重连时同步节拍与未确认音符。
WebSocket 是实现实时音轨同步最直接有效的方案，关键不在连接本身，而在于如何设计时间基准、处理网络抖动、协调客户端状态。网页端无法做到专业 DAW 级精度（微秒级），但通过“逻辑时钟 + 音符时间戳 + 客户端插值”组合，可实现 50ms 内的感知同步，满足协作创作需求。
统一时间轴：用服务器作为逻辑时钟源
所有客户端不依赖本地 Date.now() 或 AudioContext.currentTime，而是由服务端广播带时间戳的节拍事件（如每 16 分音符触发一次）。每个消息包含：
- beatId：单调递增的整数，标识当前节拍序号
- serverTime：服务端发出该消息的毫秒时间戳（Date.now()）
- expectedLocalTime：客户端应播放此节拍的本地时间（服务端预估，含基础延迟补偿）
客户端收到后，用 performance.now() 计算往返延迟，动态校准本地逻辑时钟偏移量，后续所有音符都按此逻辑时间轴对齐，而非物理时间。
音符数据结构化传输：避免原始音频流
不传 PCM 或 MP3——带宽高、延迟大、难同步。改用轻量 JSON 描述音符事件：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- trackId：唯一轨道标识（如 "piano-001"）
- noteOn/noteOff：{ pitch: 60, velocity: 92, time: 12480 }，time 为逻辑节拍时间（单位：毫秒，相对于会话起始）
- duration：显式标注时长（避免依赖 noteOff 时序，防丢包）
服务端仅做广播与冲突检测（如同一时间同一音符被两人同时添加），不参与音频合成；各客户端用 Web Audio API 在本地精确调度播放。
抗网络抖动：客户端缓冲 + 时间插值
即使逻辑时钟对齐，网络延迟波动仍会导致消息到达不均匀。解决方案是：
- 客户端维护一个 音符缓冲区（buffer window = 200–300ms），只播放已提前到达、且时间戳 ≤ 当前逻辑时间 − 缓冲阈值 的音符
- 对刚到达但尚未到播放点的音符，用
AudioContext的scheduledTime精确预约（非 setTimeout） - 当检测到连续丢包或延迟突增，临时降速逻辑时钟推进速率（类似视频播放的卡顿补偿），再平滑恢复
状态同步与协作控制
除音符外，需同步以下元操作以保证界面一致：
- 播放/暂停/跳转：由房主发起，服务端广播全局状态，所有客户端强制对齐 playbackTime
- 轨道静音/独奏：广播 trackState 变更，不影响他人轨道，仅控制本地 AudioNode.connect()/disconnect()
- 新增轨道：分配唯一 ID，同步轨道参数（乐器类型、音色、效果链配置），但音频资源由客户端自主加载（避免服务端带宽瓶颈）
所有状态变更均附带 version number，客户端拒绝处理旧版本指令，防止因消息乱序导致状态错乱。
不复杂但容易忽略：WebSocket 连接断开重连时，必须从服务端拉取最新逻辑节拍号和未确认音符列表，再用客户端本地 buffer 补齐中间状态，才能无缝续上。整个系统成败，取决于时间模型是否闭环、数据是否无歧义、状态是否可收敛。
