Pretty much any solution you choose will suffer from bad acceptance on one device or another, and web-based solution is even worse (as extensively pointed out by everybody).
If you want to cover the largest audience possible, set up a streaming server like Icecast and broadcast over MP3 and/or OGG (both is better). Pretty much every internet connected device with reasonable capabilities will be able to play streaming audio, so let the user pick the appropriate player or its favorite one.
我认为仅使用 JavaScript 和 HTML5 无法完成类似的操作。如果可以的话，我们很可能需要等待很长时间才能让客户端在浏览器中使用它。正如 David 所说，Flash 可以工作，但问题是：A) 很多设备不支持它，B) Flash 远非免费。还有其他方法可以完成您所描述的操作，但它们需要其他编程或至少需要其他插件。我能想到的唯一的其他选择是 Microsoft 的 Silverlight，免费且不太难使用，它确实有麦克风支持，但不确定它有多棒。希望这有帮助。
I don't think that you can do something like this with just JavaScript and HTML5. And if we could, we would most likely have to wait a long while before clients could use it in there browser. Like David said, Flash would work, the problem with that is: A) a lot of devices wouldn't support it and B) Flash is far from free. There are other ways of doing what you described but they would require other programming or at least other plugins. The only other alternative I can think of is Silverlight from Microsoft, free and not overly hard to use, it does have mic support, not sure how great it is though. Hope this helps.
HTML 音频标签没有指定任何特定的编解码器，因此浏览器供应商可以自由选择自己的编解码器。目前，没有一个支持流格式，尽管这种情况有可能发生。至于录制，我不确定您是否真的希望支持浏览器的无限录制，因为您会遇到并发问题？你真的会让每个人同时录音吗？
对在服务器上记录流媒体会话进行有限访问，然后允许通过浏览器对其进行存档访问似乎更有意义。使用 HTML AUDIO 标签可以轻松执行检索，但本质上我们刚刚发明了播客。
The HTML audio tag does not specify any particular codec, so browser vendors are free to choose their own. Currently, none support a streaming format, although that could happen. As to recording, I'm not sure you'd really want to support unlimited recording from the browser, because you'd have concurrency issues? Would you really allow everybody to record at once?
It seems to make more sense to have a limited access to recording a streaming media session on the server, and then allow archived access to that through the browser. The retrieval could be easily performed with the HTML AUDIO tag, but essentially we've just invented the podcast.
It would be possible to manipulate audio tags to "stream" content, but there'd have to be a buffer of a couple seconds (at least). Re-set the source of the tag to a URL which provides the next couple seconds every couple seconds (not static files of course, but served dynamically from the stream). Admin side I think you're stuck with a plugin since you need mic access.
对于服务器端（“麦克风”音频输入），我假设您可以自由地做任何您想做的事情。例如，应该可以不实际将麦克风连接到服务器，而是让服务器从另一个源/服务器运行某种转码器进程。然后，您可以拥有一个 Web 客户端连接到的 CGI/FastCGI 应用程序来获取最新的流窗口（流的一部分，例如 1-5 秒？）。
在 Web 客户端，您可以使用音频标签并通过 JavaScript 控制它，以使用新的流窗口定期更新它。不支持音频样本排队，因此您必须想出某种自定义同步机制。一种解决方案可能是使用两个交叉淡入淡出的同步音频样本（从而最大限度地减少由于计时不准确而导致的咔嗒声和卡顿声）。
I think that what you are proposing is doable in theory, but in practice web clients and standards are still not really mature enough yet. For instance, check out this interesting blog about audio synthesis in JavaScript.
Now, for the theory:
Alternative 1: Wait for browsers to add support for a streaming audio format (typically, the audio tag currently supports WAV, OGG and/or MP3).
Alternative 2: Implement streaming yourself...
For the server side (the "mic" audio input thing) I assume you are free to do pretty much whatever you want. For instance, it should be possible to not actually connect the mic to the server, but rather let the server run some sort of transcoder process from another source/server. Then you can have a CGI/FastCGI application that web clients connect to to get the latest stream window (part of the stream, say 1-5 seconds?).
On the web client side, you can probably use the audio tag and control it from JavaScript to update it periodically with new stream windows. Queuing of audio samples is not supported, so you would have to come up with some sort of custom synchronization mechanism. One solution could be to use two simultaneous audio samples that cross-fade (thus minimizing clicks & hickups resulting from inaccurate timing).
发布评论
评论（8）
几乎您选择的任何解决方案都会在一种或另一种设备上受到不良接受，而基于网络的解决方案甚至更糟（正如每个人广泛指出的那样）。
如果您想覆盖尽可能多的受众，请设置一个流媒体服务器，例如 Icecast 并通过 MP3 和/或OGG（两者都更好）。几乎所有具有合理功能的互联网连接设备都能够播放流媒体音频，因此让用户选择合适的播放器或其最喜欢的播放器。
Pretty much any solution you choose will suffer from bad acceptance on one device or another, and web-based solution is even worse (as extensively pointed out by everybody).
If you want to cover the largest audience possible, set up a streaming server like Icecast and broadcast over MP3 and/or OGG (both is better). Pretty much every internet connected device with reasonable capabilities will be able to play streaming audio, so let the user pick the appropriate player or its favorite one.
http://web.psung.name/zeya/ - 此应用程序可以即时对您的音乐进行转码，并且使用 HTML5 对其进行流式传输。也许这会有所帮助；）
http://web.psung.name/zeya/ - this app transcodes your music on the fly and streams it using HTML5. Maybe this will help a little bit ;)
有一个与设备交互的规范，例如麦克风，但现在还处于早期阶段，我不知道有任何支持。
如果您现在想要一些可以与麦克风交互的东西，请考虑 Adobe Flash。
There is a specification for interacting with devices, such as microphones, but it is early days and I'm not aware of any support for it.
If you want something that can interact with a mic today, look to Adobe Flash.
我认为仅使用 JavaScript 和 HTML5 无法完成类似的操作。如果可以的话，我们很可能需要等待很长时间才能让客户端在浏览器中使用它。正如 David 所说，Flash 可以工作，但问题是：A) 很多设备不支持它，B) Flash 远非免费。还有其他方法可以完成您所描述的操作，但它们需要其他编程或至少需要其他插件。我能想到的唯一的其他选择是 Microsoft 的 Silverlight，免费且不太难使用，它确实有麦克风支持，但不确定它有多棒。希望这有帮助。
I don't think that you can do something like this with just JavaScript and HTML5. And if we could, we would most likely have to wait a long while before clients could use it in there browser. Like David said, Flash would work, the problem with that is: A) a lot of devices wouldn't support it and B) Flash is far from free. There are other ways of doing what you described but they would require other programming or at least other plugins. The only other alternative I can think of is Silverlight from Microsoft, free and not overly hard to use, it does have mic support, not sure how great it is though. Hope this helps.
HTML 音频标签没有指定任何特定的编解码器，因此浏览器供应商可以自由选择自己的编解码器。目前，没有一个支持流格式，尽管这种情况有可能发生。至于录制，我不确定您是否真的希望支持浏览器的无限录制，因为您会遇到并发问题？你真的会让每个人同时录音吗？
对在服务器上记录流媒体会话进行有限访问，然后允许通过浏览器对其进行存档访问似乎更有意义。使用 HTML AUDIO 标签可以轻松执行检索，但本质上我们刚刚发明了播客。
The HTML audio tag does not specify any particular codec, so browser vendors are free to choose their own. Currently, none support a streaming format, although that could happen. As to recording, I'm not sure you'd really want to support unlimited recording from the browser, because you'd have concurrency issues? Would you really allow everybody to record at once?
It seems to make more sense to have a limited access to recording a streaming media session on the server, and then allow archived access to that through the browser. The retrieval could be easily performed with the HTML AUDIO tag, but essentially we've just invented the podcast.
可以操纵音频标签来“流式传输”内容，但必须有几秒钟的缓冲区（至少）。将标记的源重新设置为每隔几秒提供接下来几秒的 URL（当然不是静态文件，而是从流动态提供）。管理方面，我认为您被插件困住了，因为您需要麦克风访问权限。
It would be possible to manipulate audio tags to "stream" content, but there'd have to be a buffer of a couple seconds (at least). Re-set the source of the tag to a URL which provides the next couple seconds every couple seconds (not static files of course, but served dynamically from the stream). Admin side I think you're stuck with a plugin since you need mic access.
我认为你所提出的建议在理论上是可行的，但在实践中网络客户端和标准还不够成熟。例如，查看这个关于JavaScript 中的音频合成的有趣博客。
现在，理论：
替代方案 1：等待浏览器添加对流音频格式的支持（通常，音频标签当前支持 WAV、OGG 和/或 MP3）。
替代方案 2：自己实现流媒体...
对于服务器端（“麦克风”音频输入），我假设您可以自由地做任何您想做的事情。例如，应该可以不实际将麦克风连接到服务器，而是让服务器从另一个源/服务器运行某种转码器进程。然后，您可以拥有一个 Web 客户端连接到的 CGI/FastCGI 应用程序来获取最新的流窗口（流的一部分，例如 1-5 秒？）。
在 Web 客户端，您可以使用音频标签并通过 JavaScript 控制它，以使用新的流窗口定期更新它。不支持音频样本排队，因此您必须想出某种自定义同步机制。一种解决方案可能是使用两个交叉淡入淡出的同步音频样本（从而最大限度地减少由于计时不准确而导致的咔嗒声和卡顿声）。
I think that what you are proposing is doable in theory, but in practice web clients and standards are still not really mature enough yet. For instance, check out this interesting blog about audio synthesis in JavaScript.
Now, for the theory:
Alternative 1: Wait for browsers to add support for a streaming audio format (typically, the audio tag currently supports WAV, OGG and/or MP3).
Alternative 2: Implement streaming yourself...
For the server side (the "mic" audio input thing) I assume you are free to do pretty much whatever you want. For instance, it should be possible to not actually connect the mic to the server, but rather let the server run some sort of transcoder process from another source/server. Then you can have a CGI/FastCGI application that web clients connect to to get the latest stream window (part of the stream, say 1-5 seconds?).
On the web client side, you can probably use the audio tag and control it from JavaScript to update it periodically with new stream windows. Queuing of audio samples is not supported, so you would have to come up with some sort of custom synchronization mechanism. One solution could be to use two simultaneous audio samples that cross-fade (thus minimizing clicks & hickups resulting from inaccurate timing).
Apple 网站上的这份文档可能就是您要查找的内容。它建议对 iPad、iPhone 和 iPod Touch 等设备使用 HTTP Live Streaming：https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html
可能就是您所追求的。
This document on the Apple website might be what you are looking for. It recommends using HTTP Live Streaming for devices like the iPad, iPhone and the iPod Touch: https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/Introduction/Introduction.html
Might be what you are after.