SS2-01项目上市后出现各种语音通话类问题,严重导致客诉、客退现象。
通过本文介绍的语音问题分析定位方法,可使从事modem语音通话方面的相关同事更快、更精准的定位语音通话问题原因。
【1】80-P0167-1EC_A_UMTS_GSM_Audio_Issue_Troubleshooting.pdf
常见有两大类原因导致语音通话问题:第一种为多媒体模块处理后的音频出现异常而导致的语音问题,第二种为modem或者网络在处理和传输的过程中引入问题。首先介绍如何定位语音问题是那个模块引入的。
图2.1 modem取得的音频数据节点
以上行音频处理为例:
从上面的音频处理流程就可以清晰的知道,其实modem拿到的音频数据,以及下行modem发送给音频处理模块的分水岭就是经过信源编码的vocoder packets音频数据,如下图:
所以拿到Audio issue的问题日志时,我们首先要按照如下的方法确定问题是属于modem、网络引入的,还是属于多媒体模块处理本身就产生的问题。如下图用QCAT处理后的音频数据的4个节点,只有在节点2存在异常的时候是modem、网络引入的问题,其余节点出现异常均属于多媒体模块需要进行处理。
图2.3 QCAT处理后的音频数据节点
通过上述方案定位到问题为modem、网络存在异常后,接下来需要定位问题发生的时间点。精准的定位到问题发生时间点,才能正确的定位到问题发生的原因。而一般情况下测试所报的单通和断续问题,基本上是要研发这边去听语音通话内容,然后根据语音通话内容所在的相对时间点结合日志才能确定问题时间点。
如下图首先在QCAT中过滤出空口日志和对应的Vocoder Packet日志,第一个Vocoder Packet包即对应此通电话的语音开始的绝对时间。
QCAT过滤出来的音频数据,以下行的一段日志中的Rx音频数据为例:
diag_log_20160416_211346-diag_log_20160416_211819.isf.voc.rx,此段音频数据中包含了日志中所有通话的音频数据,所以首先要用音频播放器听出是第几通电话的第几分钟第几秒出现了问题,之后根据这通电话的在日志中的开始时间“+”从音乐播放器中听到的相对时间就可以定位到问题发生的时间点。
如下是在第2通电话的4:10时间段出现了断续、听不清,那此时在日志中定位到的时间点就为13:15:01+(4:10-3:01)=13:16:10,之后在这个时间段去查看日志,定位问题。
Cool Edit Pro 工具播放音频数据
确定问题发生时间点之后,首先需要查看这个时间点通话时的信号质量,看看所在信道是否存在干扰,信噪比、BER和接收信号电平,一般多数情况下是因为网络信号质量比较差导致的Audio issue。其次查看,日志中的Vocoder Packet数据包,如果一直出现bad frame的指示,并且信号质量确实比较差,可以确定为网络原因导致。
如下截图问题,很长一段时间下行的Rx Bad Frame Indicator =1,说明下行从网络拿到的音频帧都解析失败了,是坏帧,所以下行音频肯定异常。正常情况下,每20ms就会有一个语音帧,如果发现语音帧不是每20ms一个连续发送,则存在丢帧的可能,也会导致断续和短暂的单通问题的发生。
GSM网络切换属于硬切换,即先与之前的小区断开连接后,再与新小区建立连接。所以在切换的过程中就有可能出现短暂的断续问题,尤其是当终端在通话过程中处于频繁切换的网络环境时,就会造成断续问题比较严重。
为了说明为什么GSM切换会引入语音断续问题,可以从日志中看出GSM切换过程如下:
//通话过程中由于服务小区信号质量变差,邻区信号质量变好,手机收到网络下发的Handover Command消息。
02:34:46.573 [1C] 0x5B2F GSM DSDS RR Signaling Message -- Handover Command
02:34:46.573 rr_gprs_debug.c :IMsg: HANDOVER_COMMAND state RR_DATA_TRANSFER
//modem先停止和当前小区的L2的链接,并在L1配置要切换的目标小区的相关信息。
02:34:46.574 rr_gprs_debug.c gs1:OMsg: DL_SUSPEND_REQ sent to L2
02:34:46.615 rr_gprs_debug.c gs1:OMsg: MPH_HANDOVER_REQ sent to L1
02:34:46.615 l1_ded_if.c gs1:MPH_HANDOVER_REQ to Cell 89 BSIC:42
//发起RACH并启动定时器,直到收到网络下发的Phy Info(RACH成功)或者定时器T3124超时(RACH失败)。
所以在这个状态下如果RACH很久没有成功,此时终端与网络之间处的状态是与之前小区已经断开连接,与新小区的连接还未成功建立,所以音频数据肯定无法正常传输。
02:34:46.675 rr_gprs_debug.c gs1:OMsg: DL_RANDOM_ACCESS_REQ sent to L2
02:34:46.683 rr_inter_ho.c 04066 gs1:Starting T3124(320) TCH
LOG GSM L1 Transmit Burst Metrics 02:34:46.688
Channel = RACH
LOG GSM L1 Transmit Burst Metrics 02:34:46.697
Channel = RACH
……
MSG 02:34:46.808 rr_gprs_debug.c 04157 gs1:IMsg: PHYSICAL_INFORMATION state RR_DATA_TRANSFER
MSG 02:34:46.808 rr_inter_ho.c 04705 gs1:Stopping T3124
//RACH成功后,modem给网络发送HANDOVER_COMPLETE空口信令,但此时切换实质上并未真正的完成。
02:34:46.808 rr_inter_ho.c 00619 gs1:OMsg(NW,HANDOVER_COMPLETE(0)
02:34:46.809 [EF] 0x5B2F GSM DSDS RR Signaling Message -- Handover Complete
正常通话过程中语音帧都是在不断的变化的,如果发现日志中的Vocoder Packet中的语音数据在很长的一段时间里是恒定不变的,或者只有几个数字在变化,这肯定是存在异常的。这种情况多数是因为网络侧存在异常,导致的在下行发送的Homing Sequence。
不同语音编码格式的Homing Sequence如下,如果在日志中发现如下格式的网络发送的语音帧导致的下行无声,可以确定为网络异常:
AMR/NB:
FR:
0x4820, 0xD617, 0x0284, 0x2480, 0x9249, 0x8924, 0x8002, 0x4924,0x2492, 0x0289, 0x2480, 0x9249, 0x8924, 0x8002, 0x4924, 0x2492, 0x0009
EFR:
0x085E, 0xB490, 0xFAAD, 0x603E, 0x3A18, 0x607B, 0x0C42, 0xC080,0x4805, 0x5800, 0x0000, 0x0000, 0x36B0, 0x0000, 0x0000, 0x0000, 0x0000
HR:
0x0371, 0xaf61, 0xc8f2, 0x8025, 0x31c0, 0x0000, 0x0000
AMR/WB:
1. {0x3100, 0x3800, 0x109c, 0x0130, 0x07f2, 0xfa22, 0xeb89, 0x8adb, 0x00d0,0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}
2. {0x0044, 0x000f, 0x550a, 0x5df1, 0x0f22, 0xd794, 0xfa01, 0x85a4, 0x44a7,0xc546, 0xe5e6, 0x0080, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000 }
3.{ 0x4650, 0x7700, 0xdeff, 0xf105, 0x675b, 0x8c8f, 0x70f7, 0xda07, 0xca82,0x5ad1, 0xde42, 0xc05a, 0xee44, 0x5ad3, 0x44e6, 0xd8d1, 0x0000 }
4. {0x18C1, 0xD40B, 0x90EB, 0xEF90, 0x080D, 0x203B, 0xD040, 0x2E94, 0x8000,0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000 }
5. {0x18C1, 0xEEC5, 0x36BA, 0x3A37, 0x9DE4, 0x41A7, 0x8C08, 0x0085, 0x21B2,0x2E0D, 0x8364, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000}
6. {0x18C1, 0xEEC5, 0x36BA, 0x3A81, 0xC7E7, 0xF07C, 0x696D, 0x1693, 0x80C0,0x7C0F, 0x8041, 0x21FB, 0xB3F7, 0xB20E, 0xEDA5, 0x6CF8, 0x0000}
备注:补充一个小问题,如何判断此通语音通话采用的是那种语音编码格式呢?
终端通过QMI消息MsgType = QMI_VOICE_SPEECH_CODEC_INFO_IND上报给上层AP,本通电话所使用Speech Codec。
2016 Mar 14 11:18:04.217 [C4] 0x138F QMI Link 1 TX PDU
QmiVoiceSpeechCodecInfoIndTlvs[1] {
Type = 17
Length = 4
SpeechCodecTypeTlv {
Speech Codec = AMR_WB
}
}
MTK平台抓取的音频日志为后缀为.vm的日志,也是需要用工具处理后才能进行正常的播放,音频处理工具为Speech Analyzer,处理完之后的音频数据的所对应的音频节点如下图:
UL0.wav:进入MagiAIC的原始音频数据
UL1.wav DSP处理后的进入modem的音频数据
UL.wav是modem直接送给网络的音频数据
DL.wav 是下行链路直接传送给modem的音频数据
DL0.wav 是经过DSP处理后的音频数据
DL1.wav是语音话筒出来的音频数据
音频问题modem的协议栈引入问题的可能性不大,modem这边分析目的,主要是为了确定当时的网络是否存在异常。网络正常的情况下出现的音频问题,需要音频同事重点关注,必要时需要硬件同事协调,查看硬件的天线发射和接收性能。