Javascript 为什么使用MediaElementAudioSourceNode播放更长的声音更合适？

完整问题：对于较长的声音，为什么使用

MediaElementAudioSourceNode

比使用

AudioBuffer

更合适

:

这些类型的对象设计用于保存小的音频片段，通常小于45秒。对于较长的声音，实现MediaElementAudioSourceNode的对象更合适

:

此接口表示内存驻留音频资源（用于单发声音和其他短音频剪辑）。其格式为非交错32位线性浮点PCM值，正常范围为[−1,1][−1,1]，但值不限于此范围。它可以包含一个或多个通道。通常，预计PCM数据的长度相当短（通常略小于一分钟）。对于较长的声音，如音乐配乐，流媒体应与audio元素和MediaElementAudioSourceNode一起使用

在

音频缓冲区上使用
MediaElementAudioSourceNode
有什么好处

使用

MediaElementAudioSourceNode

制作短片时是否有任何缺点

MediaElementSourceNode具有流式播放的潜在能力，当然也可以在下载和解码整个声音文件之前开始播放。它还能够做到这一点，而无需将声音文件转换（可能会扩展！）为32位线性PCM（CD质量的音频每通道仅为16位）并转换为输出设备采样率。例如，以16位16kHz录制的1分钟播客本机大小将略低于2兆字节；如果您在48kHz设备上播放（这并不少见），将代码转换为32位48kHz意味着您将使用将近12兆字节的音频缓冲区

MediaElementSourceNode无法提供精确的播放时间，也无法管理/播放大量同时播放的声音。对于您的用例来说，精度可能是合理的，但它不会像AudioBuffer那样精确计时

---

有趣的是，

MediaElementSourceNode

为什么不需要转码到输出设备采样率？我认为，如果播放的声音的采样率与输出设备的采样率不同，那么采样的音高和速度就会改变（根据我的经验，

AudioBuffer

）。我确实需要最精确的播放时间，因为我正在构建某种DAW，所以我将坚持使用

AudioBuffer

s。谢谢你的帮助！它确实需要转码到输出采样率（也称为AudioContext速率），但它一次可以对流的一块进行转码，而不仅仅是整个缓冲区。如果使用decodeAudioData（），则应将AudioBuffers适当地重新采样到正确的采样率。