我正在尝试确定基于 Web 的音频流媒体网站是否使用 Web Audio API 进行播放，或者它们是否依赖于音频元素或其他内容。
由于音频流服务的用户通常不需要比启动和停止音频更多的功能，所以我猜音频元素就足够了。如果需要 VU-meter，那么我猜会使用 Web Audio API，因为它有一个内置的分析器节点。但由于 IE 不支持 API，那么我想你宁愿使用音频元素来吸引 IE 用户，而不是使用 VU 表等花哨的附加功能。
我一直在查看 Spotifys 网络播放器、Grooveshark、BBC 广播和波兰公共广播的源代码，但我没有找到音频元素或 Web Audio API 的使用。不过，我确实发现瑞典公共广播 (sr.se) 使用了音频元素。
我并不是要求任何人为我浏览 JavaScript 源代码，而是希望熟悉该主题的人可以为我指明正确的方向。
【问题讨论】：
标签： html audio audio-streaming webradio
我们使用 Web Audio 通过 Aurora.js 使用与 HTTP 实时流式传输非常相似的协议进行流式传输。我们这样做是因为我们希望使用相同的流媒体后端来为 iPhone、Android 和网络提供服务。
这是一个非常漫长而痛苦的过程，花费了 6 多个月的努力，但现在一切都完成了，一切都很好。
查看http://radioflote.com 并随时就任何问题提出问题或澄清。如果您愿意，可以继续反汇编代码。没问题。
【讨论】：
我不知道目前有任何互联网广播服务使用 Web Audio API 播放他们的流，但找到一个我不会感到惊讶。我自己一直在使用Audiocog's excellent Aurora.js library 进行开发，通过使用 JavaScript 解码音频，它可以在浏览器中启用通常不可用的编解码器。但是，正如您所指出的，出于兼容性原因，这在今天被认为有点实验性。
大多数互联网广播电台使用渐进式 HTTP 流式传输（SHOUTcast/Icecast 风格），可在 <audio> 元素或 Flash 中播放。这很好用，但很难做到正确，特别是如果您使用 SHOUTcast 服务器，因为它们是not quite 100% compatible with HTTP，会损害某些版本的 Firefox 和许多移动浏览器中的浏览器支持。我最终编写了自己的名为 AudioPump Server 的服务器，以通过 HTTP 渐进式获得更好的浏览器和移动浏览器支持。
根据您的 Flash 代码和可用的 ActionScript 版本，您可能还需要deal with memory leaks in creative ways，因为默认情况下，Flash 会将您的所有流数据无限期地保存在内存中，因为它从未构建为通过 HTTP 流式传输。许多人使用带有 Flash 的 RTMP（在服务器上使用 Wowza 或类似名称），Flash 是为了解决这个问题而构建的。
iOS 支持HLS，它基本上是由 HTTP 服务器提供的静态文件的集合。编码器在编码发生时将流的一部分写入每个文件，客户端只需下载它们并无缝播放它们。这样做的好处是客户端可以选择一个比特率进行流式传输，并随着网络条件的变化而提高和降低质量。这也意味着您可以完全切换网络（例如从 WiFi 到 3G）并且仍然保持流，因为块是独立且无状态地下载的。 Android“支持” HLS，但它有问题。 Safari 是目前唯一支持 HLS 的浏览器。
兼容性检测不是您需要自己解决的问题。有很多播放器，例如jPlayer和JW Player，它们对HTML5音频支持检测，编解码器支持检测，并在播放HTML5音频和Flash之间提供通用API。如果您想快速启动和运行，它们还提供可选 UI。
最后，大多数电台都会提供一个链接，让您可以在自己的媒体播放器中播放流媒体。这是通过链接到下载并经常立即打开的播放列表文件（通常是 M3U 或 PLS）来完成的（由用户及其浏览器配置）。播放器软件加载此播放列表，然后直接连接到流媒体服务器开始播放。在 Android 上，您只需 link to the stream URL。它将检测Content-Type 响应标头，断开连接并打开其配置的媒体播放器进行播放。这些天来，您必须寻找这些直接链接，但它们就在那里。
如果您想知道一个电台正在使用什么，而无需深入研究其编译和缩小的源代码，只需使用Fiddler 或Wireshark 之类的工具并观察流量。你会发现它在底层非常简单。
【讨论】：