demo实时转码并上传代码：添加在间隔太短时mp3因为首尾静默导致停顿问题严重的描述

assets/runtime-codes/teach.realtime.encode_transfer.js

@@ -7,17 +7,29 @@
 
 如果不需要获得最终结果，可实时清理缓冲数据，避免占用过多内存，想录多久就录多久。
 
-小技巧：测试结束后，可执行mp3、wav合并的demo代码，把所有片段拼接到一个文件
+【拼接小技巧】测试结束后，可执行mp3、wav合并的demo代码，把所有片段拼接到一个文件
 
-mp3格式因为lamejs采用的CBR编码，因此后端接收到了mp3片段后，通过简单的二进制拼接就能得到完整的长mp3。
+【mp3拼接】mp3格式因为lamejs采用的CBR编码，因此后端接收到了mp3片段后，通过简单的二进制拼接就能得到完整的长mp3；前端、后端实现拼接都可以参考mp3合并的demo代码。
+
+【wav拼接】本库wav格式音频是用44字节wav头+PCM数据来构成的，因此只需要将所有片段去掉44字节后，通过简单的二进制拼接就能得到完整的长pcm数据，最后在加上44字节wav头就能得到完整的wav音频文件；前端、后端实现拼接都可以参考wav合并的demo代码。
+
+【引入杂音、停顿问题】除wav外其他格式编码结果可能会比实际的PCM结果音频时长略长或略短，如果涉及到实时解码应留意此问题，长了的时候可截断首尾使解码后的PCM长度和录音的PCM长度一致（可能会增加噪音）；
+wav格式最终拼接出来的音频音质比mp3的要好很多，因为wav拼接出来的PCM数据和录音得到的PCM数据是相同的；
+但mp3拼接出来的就不一样了，因为每次mp3编码时都会引入首尾的静默数据，使音频时长略微变长，这部分静默数据听起来就像有杂音和停顿一样，在实时转码间隔很短的情况下尤其明显（比如50ms），但只要转码间隔比较大时（比如500ms），mp3的这种停顿就会感知不到，音质几乎可以达到和wav一样。
 ******************/
-var testOutputWavLog=false;//本测试如果是输出mp3，就顺带打一份wav的log，方便对比数据
+var testOutputWavLog=false;//本测试如果是输出mp3，就顺带打一份wav的log，录音后执行mp3、wav合并的demo代码可对比音质
 var testSampleRate=16000;
 var testBitRate=16;
 
-var SendInterval=50;//转码发送间隔（实际间隔比这个变量值偏大点，取决于bufferSize）。这个值可以设置很大，但不能设置很低，毕竟转码和传输还是要花费一定时间的，设备性能低下可能还处理不过来。
-//mp3格式下一般大于500ms就能保证能够正常转码处理，wav大于100ms，剩下的问题就是传输速度了。由于转码操作都是串行的，录制过程中转码生成出来mp3顺序都是能够得到保证，但结束时最后几段数据可能产生顺序问题，需要留意。由于传输通道不一定稳定，后端接收到的顺序可能错乱，因此可以携带编号进行传输，完成后进行一次排序以纠正顺序错乱的问题。
-//当出现性能问题时，可能音频编码不过来，将采取丢弃部分帧的策略。
+var SendInterval=300;/******
+转码发送间隔（实际间隔比这个变量值偏大点，取决于BufferSize）。这个值可以设置很大，但不能设置很低，毕竟转码和传输还是要花费一定时间的，设备性能低下可能还处理不过来。
+
+mp3格式下一般大于500ms就能保证能够正常转码处理，wav大于100ms，剩下的问题就是传输速度了。由于转码操作都是串行的，录制过程中转码生成出来mp3顺序都是能够得到保证，但结束时最后几段数据可能产生顺序问题，需要留意。由于传输通道不一定稳定，后端接收到的顺序可能错乱，因此可以携带编号进行传输，完成后进行一次排序以纠正顺序错乱的问题。
+
+mp3格式在间隔太低的情况下中间的停顿会非常明显，可适当调大间隔以规避此影响，因为mp3编码时首尾出现了填充的静默数据（mp3.js编码器内已尽力消除了这些静默，但还是会有些许的静默停顿）；wav格式没有此问题，测试时可以打开 testOutputWavLog + mp3、wav合并demo 来对比音质。
+
+当出现性能问题时，可能音频编码不过来，将采取丢弃部分帧的策略。
+******/
 
 //重置环境
 var RealTimeSendTryReset=function(type){