选择 web api 进行录音

问题描述

任务是实现基于标准网络音频 api 的录音机。仔细研究了 ScriptProcessorNode.onaudioprocess 和 AudioWorkletProcessor.process 两种方式后没有做出最终决定。官方表示 onaudioprocess 自 2014 年起已被弃用，完全替代的是音频工作人员。我是 javascript 新手，也许这个问题听起来很愚蠢，但为什么到今天仍然积极使用 onaudioprocess？

让我们深入了解细节。 AudioWorkletProcessor api 可供 73% 的用户使用，而 onaudioprocess api 可供 93% 的用户使用。在接下来的 2 年里，我们可以希望增长 10%。 （野生动物园用户）。有很多项目、文章、解决方案使用 onaudioprocess。甚至 specific tasks 也可以通过使用 onaudioprocess 来解决。这样的解决方案对于 AudioWorklet 是不可能的。 AudioWorklet 文档很差，互联网上很少提及。例如，我仍然不明白为什么 WebWorker 知道 blob 是什么，而 AudioWorklet 不知道（devTools 异常：Uncaught ReferenceError: Blob is not defined）。在打字稿中，basic functionality 的声明类型存在长期开放的情况。这一切给人的印象是 onaudioprocess 比 AudioWorklet 更活泼。也许 AudioWorklet 效率更高但难以实现，或者 javascript 社区不需要网络音频 api？解释一下为什么我要根据官方推荐选择AudioWorklet？

解决方法

你在这里问了很多问题。首先，您会很高兴知道 Safari 已经实现了 AudioWorklets。见https://wpt.fyi/webaudio。

Second WebWorkers 和 Worklets 是不同的东西，具有不同的功能。 AudioWorklets 是 Worklets，所以 AudioWorklets 只能得到 Worklet 的东西，而不是 WebWorker 的东西。

第三，是的，ScriptProcessorNode 已被弃用，但仍有重要用途。您可以在 https://www.chromestatus.com/metrics/feature/timeline/popularity/646 看到这一点。 将其与 AudioWorkletNode 的 https://www.chromestatus.com/metrics/feature/timeline/popularity/2263 进行比较。

当然，AudioWorklets 是可行的方法，但是当我想要快速而肮脏的东西并且不介意在主线程上处理时，我使用 ScriptProcessorNode。但是，如果我正在做一些具有生产质量的事情，我会尝试改用 AudioWorkletNode。