背景:在使用水晶球的过程当中,发现有很多在实际使用过程中的case可以积累下来,所以打算来这里积累一下.给后面的使用者积累经验.

问题:在做语音房PK项目时候,发现进行流媒体转发主播的那个机器人发出的声音总是卡顿.

分析:查看水晶球发现,推流身份和拉流身份并没有异常,这个时候去看了下转发推流身份的机器人的水晶球,发现机器人频繁进入退出房间.跟着这个思路,我们发现是我们客户端业务逻辑实现出现了问题,多人使用同一个uid以及这个uid所生成token身份进行转发,出现了机器人互踢的情况,所以导致了.直接听主播的声音是不卡顿的,但是听转发机器人的声音却卡顿的问题.

原因:多人使用同一个uid以及这个uid所生成token身份进行转发,出现了机器人互踢的情况.导致上面的问题.

问题:在做语音房PK项目时候,进行流媒体转发,当PK一方退出流媒体转发,还能收到PK另一方的流媒体转发的声音

分析:PK另一方不知道你这边退出了,还在进行流媒体转发.所以,有一方退出的时候,一定要告知另一方,我退出PK了,你别给我转发流媒体声音了.不然就会出现,对方不知道你退出了,还会转发流媒体声音给你.

原因:有人退出有人退出流媒体转发,不仅要自己给别人的流媒体转发停掉,也要告知别人给你转发的声音停掉,不然就会出现你已经退出PK却还能听到对方转发流媒体声音.

问题:在做语音房PK项目时候,进行流媒体转发过程中,发现转发的没声音了.并爆出code为2的错误码

分析:发现主播的水晶球显示网络频繁掉线,主播对应机器人也频繁掉线,并且onChannelMediaRelayStateChanged回调的RELAY_ERROR_SERVER_NO_RESPONSE(2):

经询问声网技术支持给出回复:

No server response. You can call the leaveChannel method to leave the channel. （这个是这个错误码的本身解释）在连麦返回错误码2的情况来看，可能都和主播的本身网络有关系。 因为我们跨频道连麦的主播和机器人之间会有一个tcp的连接维护，在主播网络较差的时候确实有可能就连麦失败，或者心跳断开导致的连麦失败。 这种情况建议的话是咱们可以监听一下对应错误来进行声网深度规避连接策略。

原因:机器人和主播链接断了,会抛出code2的错误码.当抛出这个错误码,建议进行深度规避网络策略.

问题:看水晶球发现有用户行为轨迹一直在上报静音打点

原因:发现ios设备持续在水晶球上报静音打点,是bug已经推动其修改.

问题:水晶球发现,业务级别已经关闭频道,但是水晶球中看见频道并没有关闭.

分析:发现频道内还有本地录制的用户,原来是反作弊黄反部门用来检测用户合规信息,故意多在频道内停留10min,导致频道不能关闭.

原因:频道内有用户,频道就不能被关闭,所以,本地录制的用户还在,就导致了频道不能被关闭.

问题:听频道内声音卡顿

分析:分析水晶球推流身份上行码率没有问题,网络状态,设备性能也没有问题,拉流身份网络,性能等没问题,但是下行码率有问题.去询问下声网技术支持,发现是远端声网的那个机房网络波动,导致这个连接机房的设备,给到拉流方的音频抖动.造成卡顿.

原因:连接对应那个声网远端的机房网络波动,导致拉流端卡顿.