A：首先我们要清楚Class D/K类型的PA输出是方波形式（通常频率300KHz-800KHz左右）。如下图
但是AP本身的模拟输入端口相当于一个DAC转换器，会将该输入电压DAC转换成数字信号，然后做后续的分析处理。但是AP模拟输入端口的采样带宽远小于常规示波器，如下是APx525的采样带宽，1-channel时是1MHz，2-channel时是500KHz。
由于Class D/K 输出的方波频率一般在300KHz-800KHz左右，但是AP的模拟转换带宽只有500KHz或1MHz，所以如果Class D/K的输出直接输入给AP的模拟输入口时，根据香农定理，AP无法采样到几百KHz级别的信号，导致信号失真。
因为AP分析的都是音频范围内的信号，为了解决该问题需要将Class D/K的几百KHz的载波频率给滤除掉。一般AP都会选配硬件滤波器，如AUX-0025。AUX-0025是25K的硬件低通滤波器，可以滤除25K以上的信号，加上滤波器后输入给AP的就只有音频信号了。
上图是IIC总线协议对于Clock Stretching的定义，简单理解：
IIC总线的时钟延展（Clock Stretching）指的是，IIC总线上的从机在接收主机数据时，从设备因为处理数据或其他原因而无法及时响应主设备的时钟信号，此时从设备可以通过拉低SCL时钟暂停主机的时钟信号，以便从机可以处理数据，一旦从机准备好继续处理数据时，便会释放SCL时钟，这种暂停时钟的行为被称为时钟延展（Clock Stretching），这也是IIC总线上，从机唯一有权限控制SCL的时候。
一般来说当主机是CPU或者MCU时，从机是传感器、处理器等需要将一些运算结果返回给主机的设备时，可能会出现从机正在处理数据而无法响应主机的命令，所以会拉低SCL，等数据处理完毕后再释放SCL。
RGB灯珠出现偏色现象，一般是由于灯珠的本身特性导致的。
理论上当RGB灯珠的三个通道电流相同时，RGB灯珠应该是白光，但R、G、B三个通道的电流和发光强度曲线不同，导致出现偏色现象。如下图所示，该图是一个RGB灯珠的正向导通电流和流明（发光强度）的曲线。
从上图可以看到，蓝色和绿色的曲线总是高于红色曲线，例如在正向导通电流为10mA时，绿色和蓝色发光强度为1.0，而红色的发光强度只有一半为0.5，此时RGB灯珠会出现偏色现象。在灯珠的选择上，需要尽量选择流明曲线重合部分较多的灯珠。
当然，灯珠偏色还与LED Driver不同通道间电流的一致性、结构相关。
A：
通过软件初始化时对隐藏寄存器4B的bit4 REG值进行修改，bit4默认为1代表200us，修改为0代表30ms。
修改方式如下：
0x69, c2;//打开隐藏寄存器
先读一下4B寄存器，
将4B读出来的值的bit4置0，其余bit位不变。//调整UVLO恢复时间为30ms
0x69, 00;//退出隐藏寄存器
这里以AW20036 IIC写数据的时序为例：
根据上图时序，向AW20036写一个数据需要写入三个字节（byte）：设备地址（Device Address）+寄存器地址（Register Address）+写入数据（Write Data）。
AW20036支持最大的IIC速率为400K，那么写一个比特（bit）的时间为
；写入一个字节（byte）的时间为：8bit数据+1bit的应答位，即
；那么向AW20036写入一个数据需要的时间为：
。
A： AW37501是一款为LCD屏模组的Driver提供偏电压的芯片，它集成了升压式DC-DC变换器用于前置电源，经过LDO和电荷泵可产生+5.4V和-5.4V的双输出电源，内部框图如图所示：
当后级系统出现Latchup现象时，由于AW37501的LDO输出能力太强，会导致后级芯片烧坏。在满足后端带载能力的情况下，可通过配置LDO限流值，将限流减小，以小电流限流，来确保不烧坏芯片。
LDO的输出电流限制可通过寄存器04H的Bits [4]进行配置（默认值370mA），如下图：
A：首先确保PC与手机处于同一个无线网络中
方法一：
1、 查看手机的IP地址
2、 使用
PC通过USB线连接手机，执行如下命令： adb tcpip 5555（PS：5555是端口号，可以随意地指定）
3、使用 adb connect 10.7.61.50:5555 连接手机
方法二：
1、 点击“设置”中的“关于手机”界面的“版本号”5次，让手机处于开发着模式
2、 进入“设置”中的“系统”中的“开发者选项”，打开无线调试
3、 点击“使用配对码配对设备”
4、 PC使用adb pair 10.7.61.50:42303:294611匹配设备
5、 查找手机的IP地址和端口号
6、 使用 adb connect 10.7.61.50:42749 连接手机
问题1：出现<由于目标计算机积极拒绝，无法连接>，
原因是：需要借助usb数据线在手机上开启连接adb无线模式服务，通过上述步骤2可解决；
问题2：找不到HOSH
原因是：后台进程占用了5037
解决方法：
（1） 找到占用5037的PID——例如3032
（2） 在“任务管理器”中关闭PID为3032的进程，并结束该进程
（3） PC重新使用adb pair 10.7.61.50:42303:294611匹配设备
1.确认aw算法是否bypass
MTK nodsp平台bypass aw算法的方式（选其中一种即可）:
AP_HAL算法:
1) 删除awinic_params.bin(路径在vendor/firmware下)
2) 与aw联系出一个bypass参数push到/vendor/firmware/awinic_params.bin
AP_Aurisys算法:
需与AW_DSP.BIN中设置的bypass场景的id匹配，可自行查看logcat log或者与AW确认
例如上图中Bypass场景id为3，因此对应的命令就是
|
adb shell "AudioSetParam AURISYS_SET_PARAM,HAL,ALL,AWINIC,ADDR_VALUE,0x10013d30, 3=SET " |
2.确认平台音效及第三方音效是否关闭
平台音效分为:MTK hal层音效算法，MTK平台BesLoudness算法等
第三方算法分为：杜比音效,misound等
确认方法:
抓取音频节点确认
streamout.pcm.0.AudioALSAStreamOut.flag6.pid682.tid3693.48000.32bit.2ch
AudioALSAStreamOut节点为framework输入给HAL层的数据流，此节点在算法处理前，播放1k0db的音源时因确保该节点无异常(例如频谱不应有凹陷)。
如果此节点有问题需排查framework中的算法，一般为平台BesLoudness算法（DRC算法），杜比音效。
排查BesLoudness是否关闭以及关闭方法请参考[FAQ0101044]如何关闭MTK平台BesLoudness音效
streamout.pcm.0.AudioALSAPlaybackHandlerNormal.flag6.pid682.tid3693.48000.8_24bit.2ch
AudioALSAPlaybackHandlerNormal节点为HAL算法处理后的音频节点，播放1k0db的音源时因确保该节点无异常(例如频谱不应有凹陷)
如果此节点有问题需排查HAL层中的算法，一般为MTK平台EQ算法，MISOUND，AW算法等。
3.确认pa参数是否bypass（带DSP的芯片），AGC是否关闭
带DSP的芯片查看是否bypass方法：
查看04寄存器bit2是否为1
模拟pa查看AGC是否关闭方法:
查看06寄存器是否为0F//AGC3 OFF
查看08寄存器是否为09//AGC2 OFF
查看0A寄存器bit0是否为1//AGC1 OFF
A： 客户选用sensor专用I2C接口会导致无法在kernel中控制pa。
如下图所示，高通该平台参考设计I2C4接sensor（sensor专用I2C）,这路I2C在slpi中可控，但是在kernel里无法控制，如果需要使用这种I2C，需要找平台修改释放这路I2C（可能存在无法释放给PA用的情况），因此建议客户不要选用这种sensor 专用I2C接口。
A：打开摄像头，往OIS芯片（AW86006） 0x0009、0x000A地址写入不同值，如果观察到相机可以前后移动，则说明OIS可以控制相机前后移动完成对焦工作，如下命令：
第一步：/sys/class/aw86006_ois # echo 0x00 0x02 0x0009 0x01 0x3f > awrw //300行程
第二步：/sys/class/aw86006_ois # echo 0x00 0x02 0x0009 0x03 0x00 > awrw //700行程
A：重复打开摄像头，cat reg 检查0x0009与0x000a寄存器值是否存在变化，如果存在变化，则可以确认AF往OIS中成功写入对焦值，操作步骤如下：
第一步：打开摄像头，cat reg：
xxx_64:/sys/class/aw86006_ois # cat reg
reg[0x0000]:0x88
…
reg[0x0008]:0x04
reg[0x0009]:0x00
reg[0x000A]:0x00
reg[0x000B]:0x0D
…
第二步：移动摄像头，重复第一步操作；
A：使用I2C传递IV信号会面临以下问题：
1. 带宽不够，通常IV信号格式通常为频率48Khz位宽32bit，总带宽1.536Mbps。而常规的I2C接口带宽最高带宽400Kbps。
2. 上行的IV信号对实时性要求很高，需要根据实时的IV信号来对喇叭进行保护，有时还会使用IV信号进行通话回声消除，由于I2C是分段传输数据，实时性较差，不能满足要求。
3. I2C的特点是多对多即多个主机可以与多个从机进行通信，如果使用I2C进行IV信号传输，将会长时间占用I2C总线，只要喇叭处于工作状态，I2C只能用于IV信号传输，其他设备均不能通信，极大占用资源。
Awinic推荐：
方案一：采用I2S传递IV信号，目前业界大部分的smart PA都采样这种方式。
方案二：采用内置DSP的PA，喇叭保护相关的算法运行于功放内部DSP，无需上传IV信号。
另外，监测喇叭功耗，直接在主控芯片内部检测主控送给功放的音频信号即可，无需I2C或者I2S。
A：(1)手动关闭方法：
设置->声音->音效改善->将开关置灰
此方法只为临时方案，永久关闭需从代码上修改关闭合入正式版本
（2）代码修改方式（此方法仅供参考，详情可咨询MTK平台端）
MTK_BESLOUDNESS_RUN_WITH_HAL = no
MTK_BESLOUDNESS_SUPPORT = no
在ProjectConfig.mk文件中，把上面两个宏设定成no。
代码关闭修改后，响度一般会有明显变化，同时设置里的BesLoudness开关会消失
A：
1.进入MTK工模UI
进入工模方式:
adb shell "am start -n com.mediatek.engineermode/.EngineerMode"
或者拨号盘输入*#*#3646633#*#*
2.打开ATCI
3.连接MTK tunning tool，检查配置
选到Write模式,Speaker &Music点击DRC+ACF
然后鼠标放在右上角的曲线上后按CTRL+D弹出框中选择MBDRC
确认这里面不能加增益并且曲线要是直的，设置完以后，下载到机器里。
A：
1. 确认是否是两台手机近距离测试造成
如过在解析的audio dump中有些连续声音仅在上行存在而在下行是不存在的 或 UL比REF早到很多且对齐不稳定可能是距离过近导致。
对策：
测试回音问题注意事项如下：
1)测试时，通话双方尽量间隔10米以上，或者最好在2个独立的房间进行测试
2)测试时，尽量一方不说话，让对方数数(不要太快，两个数字之间间隔一小段时间方便分析)，看是否有回声，然后交换过来
2. 是否有ref 信号 以及ref信号来源配置是否正确
若是从PMIC输出则默认从平台AFE拉ref信号。
一般是外接smartPA在I2S这种可能存在没有ref信号，需确认smartPA是否有回送ref信号（抓VMlog）。
如果smartpa没有ref信号，以AW883XX为例，还请排查以下两点:
1） 通话的时候检查kenerl log里是否有aw883xx_startup:capture enter
|
行 10302: 3,7949,16982468,-;.(0)[586:audio.service.m][Awinic][6-0034]aw883xx_startup: capture enter |
如果通话时没有以上log请检查
•检查machine驱动中回传那一路I2S是否配置dai_link。
以MT6833使用I2S0（TX）和I2S3（RX）这组为例
•SmartPa_AudioParam.xml中是否按照驱动移植文档配置
2） 确认平台回声信号取左声道还是右声道，pa参数默认配置是配置在左声道，如果不匹配VMlog中ref也会没有信号
VM log中 ref信号有信号而回声效果仍旧不好请找平台处理，VM log中没有ref信号可联系澳门新莆京手机版免费下载处理分析
沪ICP备10011954号 |
沪公网安备 31011202011955号