首先FMS的资料在网上太少了，也许因为FMS卖得太贵，很少有人正式使用。但是Flash安装量不可忽视呀，FMS也有两个代替品Red5、Wowza Media Server，前者是免费开源基于java的解决方案，后者是付费但是比FMS便宜的解决方案，因此以后这方面还是会发展，选择也会更多样化；FMS研究一下也无妨。
研究了就会有问题，这次的问题是使用Flash自身的encoder机制和使用Flash Media Live Encode 3的机制推送到FMS服务器后声音效果不一样，后者严重的声音断续，大概6秒就断一次，基本上无法正常传送音乐，语音的话偶尔就把说话的人几个字抹掉了。一开始使用Flash自身来推送声音和视频这种现象并不常见，迁移到FMLE的原因是FMLE有更多的视频推送参数可以选择，并且支持H.264编码，推送的视频质量也比Flash自身编码的效果好，在一点发送，多点接收的直播项目中，选择FMLE可以提高用户视觉体验。
于是问题产生了就要分析解决问题，先是由代理服务器改成直接推送，再是由外网测试到直接内网直接连接测试，Flash与FMLE比对，细调FMLE参数都无法排除这个问题，网上搜索国内外均无此问题的资源。心情极度郁闷呀，已经忙活了一个下午没有什么进展。
忽然间，视线从FMLE转到FMS，开始检查FMS服务器的配置参数，一般来讲FMS安装好后很少动默认的参数，我也一直没有时间仔细的查看每一个参数的意思来调整，主要也是adobe的那个说明文档太粗糙，基本上都是一带而过，而且还有些错误还要自己去猜正确答案是什么。但是现在开始怀疑它了，貌似配置文件的备注比文档说明的更详细，备注、文档两个对着开始尝试一条条瞎改，最后发现了一个配置参数并且文档中有一句话大概的意思是如果直播的话建议将此参数关闭，这个参数是Queue，位于{FMSROOT}/conf/_defaultRoot_/_defaultVHost_/Application.xml文件中，这个参数以及子集参数是来设定publish的消息队列，这个队列的内容通过一些优化操作再发给订阅者，将这个参数关闭后，第一是时效性增加了，断音的情况也消失了，留下的是不太能听得清楚的一些杂音，这些杂音可能和码流设定和网络状况有关，猜测队列可以缓存后再平滑的向接收方输出，但是这中间出了些问题，也许是缓冲区不够大，还有一些类似消息数据整合的操作导致的断音。暂时不想这么多了，有太多的诡异问题等着呢，关之，原理稍后再说。FMS不开源很多东西都没有办法深究，所以走一步看一步吧。
后记：
上述调整只能减缓问题，但是无法根本解决问题，在稍后的几天里，我们在实际网络中运行还是发现断续的现象，无奈继续一个个尝试修改配置文件，没有效果。最后还是仔细的google了一下，结论是在直播流的这种情况下，客户端flash接收一定要设置一个缓冲时间，如果缓冲是零的话，效果就不好，于是乎设置了一个0.5秒的buffer，暂时再没有发现断音的现象了。
