【问题标题】:Resampling captured audio stream with offlineAudioContext使用 offlineAudioContext 重新采样捕获的音频流
【发布时间】:2016-04-11 20:54:28
【问题描述】:

我看到这个页面resample audio buffer from 44100 to 16000 使用offlineAudioContext 从固定缓冲区重新采样音频。有没有办法从流中重新采样音频?我想做的是从麦克风捕获音频,将其重新采样为低比特率并实时上传到我们的服务器。

【问题讨论】:

  • 您是否有理由要使用如此慢的采样率?如果您只是想减少带宽,那么减少位深度是一个更好的主意。 Web Audio API 使用 float32 样本。 44.1 kHz 的 8 位样本比 16 kHz 的 16 位样本要好得多。
  • 是的。与浏览器对话的设备只知道在 ADPMC 中编码的 8K 采样率,即每个样本 4 位。最重要的是,我们所处的环境有数百名用户几乎每天 24 小时同时将实时音频(仅限演讲)上传到云服务器。所以,是的,低带宽绝对是一个要求。 8位样本的好主意。我们可以在服务器端实时对其进行下采样,这使工作变得更加容易,因为我的团队中的大多数人都是由 C、C++ 人员组成的。
  • 您的开发人员了解 Emscripten 吗? kripken.github.io/emscripten-site
  • 没有。很高兴知道。谢谢。

标签: audio webrtc audio-streaming


【解决方案1】:

您需要做的是创建一个ScriptProcessorNode,然后在使用它们调用回调时重新采样缓冲区。

var scriptNode = context.createScriptProcessor(4096, 1, 1);
scriptNode.onaudioprocess = function onAudioProcess(e) {
  // e.inputBuffer contains what you want
};

【讨论】:

  • 感谢您的回复。在执行此操作之前,我是否必须拥有所有示例数据?我正在尝试实时执行此操作,而不是录制 30 分钟的音频然后重新采样。此外,webrtc 规范没有说明回调发生的频率。
  • @user2600798 不,请阅读我为 ScriptProcessorNode 链接的文档。创建它时的第一个参数表示样本中的缓冲区大小。通过将其设置为 4,096,回调将每 4,096 个样本触发一次。我发现 2,048 和 4,096 是延迟与性能的良好折衷,对于大多数一般用途而言。如果需要,您可以将其降低,或在适当的情况下将其升高。 WebRTC 规范与此无关……这是 Web 音频 API。
  • 感谢您清理它。但这一次只能进行一次重采样。一个数据包末尾的信息没有传递到下一个数据包,所以最后的音频有很多异常。
  • @user2600798 你什么意思?您需要稍后将音频重新拼接在一起。
猜你喜欢
  • 2014-05-07
  • 2021-01-07
  • 1970-01-01
  • 2016-02-07
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-11-30
  • 1970-01-01
相关资源
最近更新 更多