使用socket.io与MediaStream API实现房间内实时语音聊天遇到问题

第一种方案卡顿断档原因 #

你当前的第一种方案核心问题是每2秒重复申请录音权限、重新初始化MediaRecorder录制整段音频，接收端每次收到2秒的音频都要重新实例化Audio对象播放，天然会存在两段音频的衔接间隙，加上重复调用getUserMedia带来的额外性能开销，必然会出现明显断档，完全不符合实时通话的低延迟要求。

第二种方案运行失败原因 #

第二种方案的逻辑从底层就错了：你调用analyser3.getByteFrequencyData拿到的是音频的频域分析数据，不是可播放的原始音频采样数据，这类数据只能用来做音频波形可视化、频谱展示，根本没法解码成可播放的音频内容，接收端把频域数据封装成Blob播放当然不会有任何声音。

适配你现有Socket.IO架构的可行实现方案 #

不需要改动服务端转发逻辑，仅修改两端客户端代码即可：

音频采集端修改 #

只初始化一次录音实例，通过MediaRecorder的流式回调推送小切片，不要攒大段音频：

let mediaRecorder = null;
// 全局仅申请一次录音权限，不要放在定时器里
navigator.mediaDevices.getUserMedia({ audio: true })
.then(stream => {
  // 用低延迟的opus编码，格式两端要保持一致
  mediaRecorder = new MediaRecorder(stream, {mimeType: 'audio/webm; codecs=opus'});
  // 收到小切片直接推送，不攒数据
  mediaRecorder.ondataavailable = (e) => {
    if (e.data.size > 0) {
      socket.emit('liveAudioToServer', e.data);
    }
  };
  // 每100ms返回一次切片，可调整到50ms进一步降低延迟
  mediaRecorder.start(100);
})
.catch(err => console.log('录音权限申请失败', err));

音频接收端修改 #

用MediaSource实现流式播放，不要每次收到数据都新建Audio对象：

// 全局仅初始化一个音频播放实例
const audio = new Audio();
const mediaSource = new MediaSource();
audio.src = URL.createObjectURL(mediaSource);
let sourceBuffer = null;
// 切片队列，解决缓冲区更新时的时序问题
const bufferQueue = [];

// 初始化媒体源缓冲区
mediaSource.addEventListener('sourceopen', () => {
  sourceBuffer = mediaSource.addSourceBuffer('audio/webm; codecs=opus');
  sourceBuffer.addEventListener('updateend', () => {
    if (bufferQueue.length > 0 && !sourceBuffer.updating) {
      sourceBuffer.appendBuffer(bufferQueue.shift());
    }
  });
});
// 注意：浏览器自动播放策略要求用户有一次页面交互后才能播放，可加一个"进入房间"按钮点击后触发play
audio.play().catch(err => console.log('自动播放被拦截，请触发用户交互后再调用play', err));

socket.on('liveAudioToClient', (data) => {
  // 转成ArrayBuffer写入缓冲区
  data.arrayBuffer().then(buf => {
    if (sourceBuffer && !sourceBuffer.updating) {
      sourceBuffer.appendBuffer(buf);
    } else {
      bufferQueue.push(buf);
    }
  });
});

内容的提问来源于stack exchange，提问作者sponge bobo