HTML5实时语音通线KB每秒
自从Recorder H5 GitHub开源库优化后，对边录边转码成小语音片段文件实时上传服务器这种操作支持非常良好，因此以前不太好支持的H5语音通话已经有了更好的突破空间。
准备局域网内两台设备(Peer A、Peer B)用最新版本浏览器(demo未适配低版本)分别打开demo页面（也可以是同一浏览器打开两个标签）。勾选页面中的H5版语音通话聊天，在Peer A中点击新建连接。
把Peer B自动生成的本机信息手动复制传输给Peer A，粘贴到远程信息中，并点击确定连接。
github demo中考虑到减少对服务器的依赖，因此采用了WebRTC P2P传输功能，无需任何服务器支持即可实现局域网内的两个设备之间互相连接，连接代码面部痣的位置与命运也算简单。有服务器支持可能就要逆天了，不过代码也会更复杂。
如果正式使用，可能不太会考虑使用WebRTC，用WebSocket通过服务器进行转发可能是最佳的选择。
[......]//通过peerA.onicecandidate获得所有的ICE连接信息候选项，如果有多个网络适配器，就会有多个候选//创建连接通道对象，A端通过这个来进行数据发送
编码最佳使用MP3格式，因为此格式已优化了实时编码性能，可做到边录边转码，16kbps 16khz的情况下可做到2kb每秒的文件大小，音质还可以，实时传输时为3kb每秒，15分钟大概3M的流量。
因为存在缓冲，就需要进行实时同步处理，如果缓冲内积压了过多的音频片段，会导致语音播放滞后太多，因此需要适当进行对数据进行丢弃，实测发现网络正常、设备性能靠谱的情况下基本没有丢弃的数据。
最开始用一个Audio停顿感太明显，因此用两个Audio轮换抹掉中间的停顿，但发现不同格式Auido播放差异巨大，播放wav非常流畅，但播放mp3还是存在停顿（后面用解码的发现是得到的PCM时长变长了，导致事件触发会出现误差，为什么会变长？怪异）。
因此后面写了一个解码然后再播放，mp3这次终于能正常连续播放了，wav格式和双Audio的播放差异不大。
实时解码里面也用到了双Audio中的技巧，其实也是用到了两个BufferSource进行类似的轮换操作，以抹掉两个片段间的停顿。
返回搜狐，查看更多数据传输改成WebSocket，做个仿微信语音通线版还是可以的（受限于Recorder浏览器支持）局域网H5版对讲机（前端玩具）