最近在项目上遇到一个问题，也不能说是最近项目上的问题了，是之前一直存在的问题，但是对项目没什么影响，所以我就不怎么理会，直到最近，同事说这个杂音已经影响到了项目的开发，所以今天花了一天时间整理了下问题，不断的修改测试中，终于搞完了。
说个题外话，年前招了一个帅哥有了新的发展，离开了我们，我内心非常不舍，说不舍有点牵强，他特别喜欢踢足球⚽，平时交集不是特别多。但是他在技术上真的也是我学习的榜样，我喜欢看他对事情认真的样子，总结一个文档和技术也非常有条理，在面对新的问题和技术难点的时候，他总是能找到解决的办法。在这点上，我觉得自己确实从他身上吸收到了好的东西。
然后，他现在去做的也是音频相关的，希望他在新的岗位，新的企业能发展得更好。
之前音频相关的文章
音频系统，Alsa 里面的buff 是怎么计算的？
为什么需要超过48k的采样音频？
我在MTK平台下调试音频ALSA
音频几个重要的参数
openwrt 音频开发
(干货)Ai音箱和Linux音频驱动小谈
Android 音频数据流分析之程序员干架产品经理
Alsa里面恶心的DAPM
1、问题
正常使用tinycap录音，在音频的开始位置会有一段杂波，这段杂波让人看起来会非常不爽。
2、排查过程
先是排查了硬件，我担心是硬件的GPIO口模式不正确，这个也是同事提醒的，后面检查了下，发现这个GPIO口是特殊口，这个GPIO口就是干这个事情的，所以说没有模式正确不正确，它就只有这个功能。
然后检查了上电，因为DMIC有一个供电，之前的文章写过，我担心供电时间过慢导致，后面修改了代码让DMIC持续供电，不过测试几次录音的时候问题还是存在，所以排除了这个问题。
还有就是DMIC的特性了，查看了DMIC的上电特性，DMIC有一个上电的时间，也就是这个时间影响了稳定。
如下图
后面跟思必驰的技术沟通，跟他讨论了这个问题，他也说到他们在其他项目中也遇到过，解决的办法就是写0。
3、解决
上面已经说了解决办法了，就是在开始录音的时候写0，但是在哪里写成了问题，如果应用直接写0就好了，但是我不能直接修改应用的代码。所以只能在内核里面做手脚。
在HAL搞这个事情可能会标准化一些。
先是确定了读音频的函数，流程是
snd_pcm_capture_ioctl1()
->snd_pcm_lib_read()
-->snd_pcm_lib_read_transfer()
修改的patch如下
diff --git a/kernel-4.4/include/sound/pcm.h b/kernel-4.4/include/sound/pcm.h
old mode 100644
new mode 100755
index b0be092799..ecaca74273
--- a/kernel-4.4/include/sound/pcm.h
+++ b/kernel-4.4/include/sound/pcm.h
@@ -460,6 +460,7 @@ struct snd_pcm_substream {
/* -- assigned files -- */
void *file;
int ref_count;
+ int once_f;/*weiqifa modify*/
atomic_t mmap_count;
unsigned int f_flags;
void (*pcm_release)(struct snd_pcm_substream *);
diff --git a/kernel-4.4/sound/core/pcm_lib.c b/kernel-4.4/sound/core/pcm_lib.c
old mode 100644
new mode 100755
index 17e69848d3..8a057f1445
--- a/kernel-4.4/sound/core/pcm_lib.c
+++ b/kernel-4.4/sound/core/pcm_lib.c
@@ -2220,6 +2220,11 @@ static int snd_pcm_lib_read_transfer(struct snd_pcm_substream *substream,
return err;
} else {
char *hwbuf = runtime->dma_area + frames_to_bytes(runtime, hwoff);
+ if(substream->once_f < 1)
+ {
+ memset(hwbuf,0,frames_to_bytes(runtime, frames));
+ substream->once_f++;
+ }
if (copy_to_user(buf, hwbuf, frames_to_bytes(runtime, frames)))
return -EFAULT;
}
diff --git a/kernel-4.4/sound/core/pcm_native.c b/kernel-4.4/sound/core/pcm_native.c
old mode 100644
new mode 100755
index 3de88974ee..0ead670a38
--- a/kernel-4.4/sound/core/pcm_native.c
+++ b/kernel-4.4/sound/core/pcm_native.c
@@ -2229,6 +2229,7 @@ static void pcm_release_private(struct snd_pcm_substream *substream)
void snd_pcm_release_substream(struct snd_pcm_substream *substream)
{
+ substream->once_f = 0;
substream->ref_count--;
if (substream->ref_count > 0)
return;
@@ -2277,6 +2278,7 @@ int snd_pcm_open_substream(struct snd_pcm *pcm, int stream,
goto error;
substream->hw_opened = 1;
+ substream->once_f = 0;
err = snd_pcm_hw_constraints_complete(substream);
if (err < 0) {
里面写0的帧大小需要调试一下，这是我最后测试出来的结果。
修改后录音得到的音频频谱图如下
从之前的文章知道计算公式，从这里反推断mute写0的时间
跟上面截图看到的时间差不多。
完美~ 下班
推荐阅读：
专辑|Linux文章汇总
专辑|程序人生
专辑|C语言
我的知识小密圈