我目前正在使用JavaScript中的MediaRecorder API来记录音频块，并将其发送到后端进行处理。现在，每次调用stop((时，都会发出一个新的事件回调，其中包含自上次执行start((以来收集的音频。因此，我的音频块是连续的且不重叠的，这意味着如果我想向后端发送2秒的音频，我必须等待2秒的数据收集。
相反，我想做的是将我的音频记录在重叠的块中。因此，例如，我想记录2s的数据，将其发送到服务器，然后等待0.1s，然后再次发送最新的2s数据(0.1s的新数据+1.9s来自前一帧(，然后再等待0.1s并再次发送2s，依此类推。在这种情况下，我的块(或帧或窗口(大小将是2s，重叠1.9s(或95%(，0.1s是"重叠"；跳跃"；。
遗憾的是，我找不到任何好的线索。有没有办法通过MediaRecorder API(或任何其他基于JS的媒体录制API(实现这一点
提前感谢！：(
额外信息：我正在后台运行一个预测模型，我想让我的系统反应更灵敏。我可以通过降低区块大小来减少系统的延迟，但这是不可能的，因为模型只接受2s的数据。；然而，我可以通过降低跳跃大小来提高我的预测的时间分辨率(即，我每秒获得多少个预测(。在当前的实现中，我的跃点大小实际上等于块长度。
您无法使用MediaRecorder创建这些重叠的声音片段：它生成压缩音频流，原则上，每个音频样本的数据取决于前一个音频样本。所以，重叠的剪辑在输出中不是一件事。
您可以连续记录并通过POST或websocket实时将每个ondataavailable数据包发送到服务器。但是，您的服务器将不得不解压缩传入的数据包序列，并生成重叠的剪辑。这比乍一看更难。
更好：您可以使用Web Audio API的ScriptProcessorNode功能每隔一段时间获取一个Javascript事件，让您处理PCM(原始而非压缩(音频样本的缓冲区。在该事件的处理程序中，您可以创建重叠的剪辑，然后使用POST请求或websocket将它们发送到服务器。请注意，这些原始PCM声音片段将比压缩片段占用更多的字节，因此您将通过用户浏览器和服务器之间的网络冲击更多的数据。较高的数据量可能会也可能不会导致操作问题。(好消息是，AWS和Azure不收取传入数据的费用，只收取传出数据的费用。(
解释这一切超出了SO回答的范围。