【Telephony 】【Call】音频通话声音问题VM、PCM文件分析（MTK&Unisoc）

一.音频通话演变

本节讲述含技术演变、音频格式、以及网络制式各技术名词，读完就能理解下面很多术语。
我认为背景知识必不可少，理论知识是技术基石，所以有必要写一下。

（1）2/3G、4G、5G语音通话

  2/3G时代 国内是使用CS电路域和PS分组域分别来处理语音业务（打电话）和数据业务（上网），当用户接打电话时，语音业务就会直接抢占数据业务的通路。那时候打电话的时候手机会直接断网，打开网页就是一直转圈圈。
  4G时代到了4G早期，这个问题也没有解决，因为4G网络初期并不能实现语音通话，语音业务仍然需走在电路域里。当时的语音解决方案叫做CSFB（即CS FallBack），用户一旦有语音电话，本来在4G的手机就会回落到2/3G进行通话；为了解决这一落差，4G时代后期推出了VoLTE技术，它可以把语音业务封装成IP数据包，通过分组网络传输，而不必再单独建立语音通道，以IP包的形式直接在PS域传输语音数据的控制系统，这套系统叫做IMS。
  5G时代 5G早期，为了尽快让大家用上5G，使用的是5G、4G共用核心网资源的NSA非独立组网方案，虽然上网业务使用了5G，但打电话却依然是由VoLTE搞定（EPS fallback）；而现在，有了基于SA独立组网的VoNR，打电话就不用再回退到4G了，语音电话、视频电话都可以跑在5G大带宽上。

（2）通话语音编码方式和速率

VoLTE语音编解码包括AMR-WB/AMR-NB/EVS三种语音编码方式，语音编码速率分别有：
AMR-NB有8种：12.2K、10.2K、7.95K、7.4K、6.7K、5.9K、5.15K、4.75K
AMR-WB有9种：23.85K、23.05K、19.85K、18.25K、15.85K、14.25K、12.65K、8.85K、6.6K
EVS有12种：128K、96K、64K、48K、32K、24.4K、16.4K、13.2K、9.6K、8K、7.2K、5.9K
  VoNR采用EVS作为语音编解码。EVS与其他常用语音编码方式（如AMR-WB（adaptive multirate wideband））相比，可以提供更高的语音质量。

（3）通话声音问题引导

  在日常生活中，我们的手机通话模式也比较多样化，有听筒模式，扬声器模式，蓝牙耳机模式，蓝牙耳机编解码更加多样复杂，遇到蓝牙耳机通话问题，需BSP模块协助分析，今天咱们主要分析下在听筒模式扬声器模式下遇到通话语音质量问题，如通话无声、通话卡顿、有杂音该怎么分析？该怎么抓取解析audio log来初步判断是网络问题？还是音频问题？还是硬件问题？

二.MTK平台语音声音问题解析

（1）MTK VM log 抓取

  VM log是MTK平台用来debug音频问题的一种log文件，以.vm为扩展名，其中记录了通话时双方的声音以及与音频编解码相关的信息。
下面先介绍VM log的两种抓取方式，以及抓取log后如何解析，两种方式的区别就是，是否有ELT tool工具可使用

抓取方法1：

本方法通过modem log解析出VM log方法，适用user和userdebug版本，需要使用ELT Tool工具解析。
1 )mtk log录制完成后，从手机中pull modem log出来，使用ELT tool打开后缀muxz的modem log文件；
2 ) 然后在ELT Tool中将该log文件另存为为后缀.elg的文件；
3) 另存完成后，在存放.elg文件的同一个目录下，会自动生成一个VM文件夹，该文件夹里就有.vm文件。

抓取方法2：

本方法在工模hardware testing/audio下抓取，只适用userdebug版本，不需要ELT tool。
1）进入设置把声音与振动-高级设置-把那些按钮音，充电音，锁屏音、触屏音等都关闭
2）手机进入 Engineer Mode
3）进入Audio\speech logger选中enable speech log，选中 Normal VM only，然后在该页最下面点击Dump Speech Debug Info,会出现一个set parameter success （这说明该项设置成功）
4）进入 \Audio\Speech Enhancement\Debug Info\Index 0 ==> 设置该参数的值 =3；
5）进入 \Audio\Speech Enhancement\Common Parameter\Index 0 ==> 设置该参数的值=6；
（常规log抓取是设置为6，回音相关问题是设为7）
这里选择enable speech log时有两个模式， Only VM、EPL VM，稍后解析VMl og时会介绍区别。
额，手机pull出来的原图不见了，从word考过来不清晰，抓log需要帮忙可联系我


6）离开工程模式后，打电话复现问题
7）最后使用adb pull data/vendor/audiohal/audio_dump 把 VMLog_XXX.vm抓取出来

（2）MTK VM log解析

1）分解VM文件

  抓取到VM log后需要用Speech Analyzer tool解析（可在MTK Online网站上下载），Speech Analyzer tool解压后，需要用管理员身份运行run_as_administrator.bat脚本，然后用这个工具打开VMLog_XXX.vm，会在VMLog_XXX.vm同目录下生成以.WAV结尾的各个点位的语音上下行数据。
再用SpeechAnalyzer.exe打开后可获得目标音频解析视图.以及播放各个点位的VM文件的声音。

2）解析VM文件

  上面说的方法2中，抓取的log有Only VM和EPL VM有什么差别？图片红框中为普通VM的2个取样点，右边为EPL VM的4个取样点，一般来说音频问题前期分析录普通VM log就可以先判断是网络问题还是手机问题，如果有发现疑点才会要求再录EPL VM。
VM log分解出来的文件有7个wav文件，对应在下图，我从MTK官方文档截出来备注了一下

  解释一下Downlink(上行数据)、Upling(下行数据)，这个上下关系是相对运营商网络的，上行的意思代表我们的声音输入mic后传达到网络，下行网络数据下行到扬声器或听筒。
这样我们对图中的各个绿点就有了基本认知，也能从中找出问题点。例如
1）机器UL1.wav声音正常，UL.wav无声，说明在Speech encode音频解码过程出现异常。
2）MO机器UL.wav声音正常，MT机器的DL.wav异常，说明是在网络传输过程有问题。
3）UL00.wav、UL0.wav无声，直接确定主副mic有问题
…
具体问题具体分析，这个方法能解析出问题点，但是具体代码流程需要自行debug。
  大部分问题直接看UL.wav和DL.wav，能确定MO端还是MT端的问题，然后再查找细节，一般情况下Network这边是网络信号质量问题、编解码方式不匹配等问题。

三.Unisoc平台语音声音问题解析

（1） Unisoc Audio log 抓取

1）在工程模式中打开(一般使用暗码*##83781##,)
工程模式–>DEBUG&LOG–>YLog–> 点击右上角三点—> Template—>Audio。


2）点击右上角三点–> Setting中关闭CP log to PC开关。
3）确保/data/ylog/modem下面产生了md_**.log，使用logel工具 FIle --> replay打开该log后，工具上再FIle --> save as（这里路径选择为和上面的log文件相同，文件名命名为dsp

4）然后再重新FIle --> replay打开保存的dsp.logel文件，（弹出界面不用管，直接点击ok）
等待完成后，Tool–> Audio --> Audio Dsp Transfer 查看mem file是否为空，不为
空即可。
5）然后依次操作Tool—>Audio—>Audio Dsp Transfer，会自动加载（
也可手动选择）生成的.mem文件，点击Transfer按钮即可得到按照特定规则命名的Pcm格式语音文件。
下载安装cooledit工具或者Audacity打开Pcm格式语音文件

注意事项：
1、必须关闭Modem To PC，否则离线抓不到dsp log。
2、Log存放路径不要太长，也不要带中文名，否则有可能会影响pcm数据的解析。
3、通过Logel工具回放，保存不带中文和特殊字符 如果保存后没有生成xx_dsp_ag.org以及xx_dsp_ag_iq.mem文件，
需要重新点击logel工具上的file->replay，加载刚才生成的.logel文件，加载完成后就
有xx_dsp_ag.org以及xx_dsp_ag_iq.mem文件了。

（2）Unisoc Pcm解析

类似MTK的分析图，我类比到Unisoc来：
1点表示下行解码前的bit流，然后用工具反解出的声音。
2点表示下行解码器解出的声音。
3点表示下行DSP写入到VBC中的声音。
4点表示上行DSP从VBC拿到的主MIC声音，也是CVS处理前的声音。
5点表示上行DSP编码前的声音。
6点表示上行编码后的bit流，然后用工具反解出的声音。
注解：VBC是一款虚拟音频虚拟声卡驱动软件；可以使所有传输到线路输出的声音信号都将被重定向为声音输。DSP 即数字信号处理技术，DSP 芯片即指能够实现数字信号处理技术的芯片
这是我解析后的PCM文件

大致分析思路：
  如果6点有问题肯定不是网络问题，而是上行出了问题。如果6点有问题，就继续去看4点，如果4点有问题，表示上行采集数据就出了问题，需要流转给BSP模块排查，如果4点没问题，就看5点有没有问题，如果5点有问题，说明音频参数处理出了问题，流转到Audio模块排查音频参数。
  如果1点有问题，表示从网络拿到的数据有问题，那么有两个可能，一个是对端上行传到网络的数据有问题，另一个个是运营商网络就有问题；一般1点有问题的时候就需要同步抓取对端log，看对端6点有没有问题，如果对端6点没有问题，那么就是网络问题，需要流转到我们Network模块分析网络出了什么问题
我找了个例子：
【问题概括】某项目通话无声，但是在点击保持通话按钮开启再关闭后会恢复正常（Umobile 运营商）
解析：此问题在根据上面流程解析PCM后，是2点下行解码器解出的声音明显出了问题。
查看Log:

Debug代码：
  协商的与终端实际使用的decodePayLoadType不一致。收到空RE-INVITE，200（OFFER）中使用listCacheMedia回复，其中AMRWB coder PayLoadType为104，随后收到ACK响应（ANSWER）且negAnswerWithInitParam=1时，需使用全能力协商，从而调用_MNS_initOutboundSession获取全能力（本端默认coder）存入listMedia，而decodePayLoadType取本端默认AMRWB coder中98，encodePayLoadType取OFFER中的104，导致decodePayLoadType与网络下发的语音RTPPayLoadType不一致，从而解码错误无声。
  简单来说，就是解析AMRWB（第一节说到了的9种类型）音频时，使用的解析格式不对。需要modem侧的代码进行修改兼容，需要升级modem版本，使终端实际使用的decodePayLoadType与协商中的一致，从而使用decodePayLoadType可正常解码网络下发的语音包。
  还是那句话，具体问题具体分析，解析出问题点，具体代码流程需要自行debug。
完。