jiangchaobing_2017的博客

录音时，codec源源不断地把A/D转换好的音频数据经过dai送入dma buffer中，而应用程序则不断地从该buffer中读走音频数据，当写入的数据快，播放的数据慢时，当数据量较多buffer有可能被冲掉，声音会出现类似“爆破”（Pop-Click）杂音的现象。播放时，应用程序把音频数据源源不断地写入dma buffer中，然后相应platform的dma操作则不停地从该buffer中取出数据，经dai送往codec中，当写入的数据慢，播放的数据快时声音会出现断断续续，一卡一卡的现象。

因为系统中可能存在多个音轨同时播放，而每个音轨的采样率可能是不一致的，比如在播放音乐的过程中，来了一个提示音，这时需要把音乐和提示音混音并输出到硬件设备，而音乐的采样率和提示音的采样率不一致，问题来了，如果硬件设备工作的采样率设置为音乐的采样率的话，那么提示音就会失真，因此最简单见效的解决方法是：硬件设备工作的采样率固定一个值，所有音轨在 AudioFlinger 都重采样到这个采样率上，混音后输出到硬件设备，保证所有音轨听起来都不失真。无论是框架层还是内核层，都是以帧为单位去管理音频数据缓冲区的。

客户方对于音量加减键从静音到最大音量十五个档位区域的音量变化趋势有定制化需求。对于安卓原生的音量曲线的调整，原生SDK里也默认提供了对应的安卓音量曲线配置文件提供用户进行定制化修改与应用验证。

1.2.1 对于杂音类问题，只需听pcm dump是否有杂音即可确认问题端发生在应用层，如果in.pcm已存在杂音，则问题可能存在于audio hal之前，如audio service、软件编解码器、或者音源本身存在杂音；如果控件没有差异，可在播放时，dump一下寄存器并作对比，将升级前后的寄存器dump上传到Aservice供进一步分析，如果没有差异，则需寄板子、上传原理图与位号图，进行进一步排查分析。功能异常的情况下，除了针对小系统的原理图设计进行检查，也需要针对外围电路，例如功放电路进行检查核对。