我试图弄清楚基于 Web 的音频流媒体站点是否使用 Web Audio API 进行播放，或者它们是否依赖于音频元素或其他东西。
由于音频流服务的用户通常不需要比启动和停止音频更多的功能，所以我想音频元素就足够了。如果需要 VU 表，那么我猜会使用 Web Audio API，因为它有一个内置的分析器节点。但是由于 IE 不支持 API，那么我想您宁愿使用音频元素来吸引 IE 用户，而不是使用 VU 表等花哨的附加功能。
我一直在查看 Spotifys 网络播放器、Grooveshark、BBC 广播和波兰公共广播的源代码，但我没有发现音频元素或 Web 音频 API 的使用。我确实发现瑞典公共广播（sr.se）虽然使用了音频元素。
我不是要求任何人为我浏览 JavaScript 源代码，而是要求熟悉该主题的人可以为我指明正确的方向。
我不知道目前有任何互联网广播服务使用 Web Audio API 播放其流，但找到一个我不会感到惊讶。我自己一直在使用Audiocog 出色的 Aurora.js 库进行开发，该库通过使用 JavaScript 解码音频，可以在浏览器中启用通常不可用的编解码器。但是，出于兼容性原因，正如您所指出的，今天这将被认为有点实验性。
大多数互联网广播电台使用渐进式 HTTP 流（SHOUTcast/Icecast 风格），可以在<audio>元素或 Flash 中播放。这很好用，但很难做到正确，特别是如果您使用 SHOUTcast 服务器，因为它们与 HTTP 不是 100% 兼容，会损害某些版本的 Firefox 和许多移动浏览器中的浏览器支持。我最终编写了自己的名为AudioPump Server的服务器，以通过 HTTP 渐进式获得更好的浏览器和移动浏览器支持。
根据您的 Flash 代码和可用的 ActionScript 版本，您可能还必须以创造性的方式处理内存泄漏，因为默认情况下，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 上，您只需链接到流 URL。它将检测Content-Type响应标头、断开连接并打开其配置的媒体播放器进行播放。如今，您必须寻找这些直接链接，但它们就在那里。
如果您想知道一个电台正在使用什么，而不需要深入研究其编译和缩小的源代码，只需使用Fiddler或Wireshark之类的工具并观察流量。你会发现它在引擎盖下非常简单。
我们使用与 HTTP Live Streaming 非常相似的协议通过 Aurora.js 使用 Web Audio 进行流式传输。我们这样做是因为我们希望使用相同的流媒体后端来为 iPhone、Android 和网络提供服务。
这是一个非常漫长而痛苦的过程，花了6个多月的努力，但现在一切都完成了，一切都很好。
看看http://radioflote.com并随时就任何问题提出问题或澄清。如果您愿意，可以继续反汇编代码。不是问题。