用于直播的网络音频 API? [英] Web Audio API for live streaming?
问题描述
我们需要将实时音频(来自医疗设备)流式传输到网络浏览器，端到端延迟不超过 3-5 秒(假设网络延迟为 200 毫秒或更短).今天我们使用浏览器插件 (NPAPI) 进行解码、过滤(高、低、频段)和播放 音频流(通过 Web 套接字传送).
We need to streaming live audio (from a medical device) to web browsers with no more than 3-5s of end-to-end delay (assume 200mS or less network latency). Today we use a browser plugin (NPAPI) for decoding, filtering (high, low, band), and playback of the audio stream (delivered via Web Sockets).
我们想更换插件.
我正在查看各种 Web Audio API 演示 以及大部分我们所需的功能(播放、增益控制、过滤)似乎在 Web Audio API.但是，我不清楚 Web Audio API 是否可用于流媒体源，因为大多数 Web Audio API 使用短声音和/或音频剪辑.
I was looking at various Web Audio API demos and the most of our required functionality (playback, gain control, filtering) appears to be available in Web Audio API. However, it is not clear to me if Web Audio API can be used for streamed sources as most of the Web Audio API makes use of short sounds and/or audio clips.
可以使用 Web Audio API 播放直播音频吗?
Can Web Audio API be used to play live streamed audio?
更新(2015 年 2 月 11 日):
经过更多研究和本地原型设计，我不确定使用 Web Audio API 进行实时音频流是否可行.由于 Web Audio API 的 decodeAudioData 并不是真正设计来处理随机的音频数据块(在我们的例子中是通过 WebSockets 提供的).它似乎需要整个文件"才能正确处理它.
After a bit more research and local prototyping, I am not sure live audio streaming with Web Audio API is possible. As Web Audio API's decodeAudioData isn't really designed to handle random chunks of audio data (in our case delivered via WebSockets). It appears to need the whole 'file' in order to process it correctly.
参见stackoverflow:
See stackoverflow:
现在可以使用 createMediaElementSource 将 元素连接到 Web Audio API，但根据我的经验， 元素会导致大量的端到端延迟(15-30 秒)，并且似乎没有任何方法可以将延迟降低到 3-5 秒以下.
Now it is possible with createMediaElementSource to connect an <audio> element to Web Audio API, but it has been my experience that the <audio> element induces a huge amount of end-to-end delay (15-30s) and there doesn't appear to be any means to reduce the delay to below 3-5 seconds.
我认为唯一的解决方案是将 WebRTC 与 Web Audio API 结合使用.我希望避免使用 WebRTC，因为它需要对我们的服务器端实现进行重大更改.
I think the only solution is to use WebRTC with Web Audio API. I was hoping to avoid WebRTC as it will require significant changes to our server-side implementation.
更新(2015 年 2 月 12 日)第一部分:
我还没有完全消除 标签(需要完成我的原型).一旦我排除了它，我怀疑 createScriptProcessor(已弃用但仍受支持)将是我们环境的不错选择，因为我可以将我们的 ADPCM 数据流"(通过 WebSockets)到浏览器，然后(在 JavaScript 中)将其转换为PCM.类似于 Scott 的库(见下文)使用 createScriptProcessor 所做的.这种方法不需要像 decodeAudioData 方法那样将数据放在适当大小的块"和关键时间中.
I haven't completely eliminated the <audio> tag (need to finish my prototype). Once I have ruled it out, I suspect the createScriptProcessor (deprecated but still supported) will be a good choice for our environment as I could 'stream' (via WebSockets) our ADPCM data to the browser and then (in JavaScript) convert it to PCM. Similar to what to Scott's library (see below) does using the createScriptProcessor. This method doesn't require the data to be in properly sized 'chunks' and critical timing as the decodeAudioData approach.
更新(2015 年 2 月 12 日)第二部分:
经过更多的测试，我去掉了到Web Audio API接口，因为根据源类型、压缩和浏览器，端到端延迟可能是3-30秒.剩下的就是 createScriptProcessor 方法(参见下面 Scott 的帖子)或 WebRTC.在与我们的决策者讨论讨论后，我们决定采用 WebRTC 方法.我假设它会起作用.但它需要更改我们的服务器端代码.
After more testing, I eliminated the <audio> to Web Audio API interface because, depending on source type, compression and browser, the end-to-end delay can be 3-30s. That leaves the createScriptProcessor method (See Scott's post below) or WebRTC. After talking discussing with our decision makers, it has been decided we will take the WebRTC approach. I assume it will work. But it will require changes to our server side code.
我要标记第一个答案，这样问题"就结束了.
I'm going to mark the first answer, just so the 'question' is closed.
感谢收听.随意根据需要添加评论.
Thanks for listening. Feel free to add comments as needed.
推荐答案
是的，Web Audio API(连同 AJAX 或 Websockets)可用于流式传输.
Yes, the Web Audio API (along with AJAX or Websockets) can be used for streaming.
基本上，您下拉(或发送，在 Websockets 的情况下)一些 n 长度的块.然后您使用 Web Audio API 对它们进行解码，并将它们一个接一个地排队播放.
Basically, you pull down (or send, in the case of Websockets) some chunks of n length. Then you decode them with the Web Audio API and queue them up to be played, one after the other.
由于 Web Audio API 具有高精度计时，如果您正确安排调度，您将不会在每个缓冲区的播放之间听到任何接缝".
Because the Web Audio API has high-precision timing, you won't hear any "seams" between the playback of each buffer if you do the scheduling correctly.
这篇关于用于直播的网络音频 API?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
