谈谈音频开发

一般ASIC内部会有专门的验证工程师做一轮验证，也会让软件工程时做一轮验证（做芯片验证是芯片公司里软件工程师的主要工作之一，出一款新芯片就要做一次芯片验证），均OK后才会去流片。所以在平台上跑之前要做好各种充分的准备，跑一次像一次，得到想要的结果，不然会很浪费时间的。音频中会用到各种memory，包括片内的（ITCM， DTCM）以及片外的（DDR， SRAM， ROM等）。如果收到，相应的bit为1，这时再去检查有没有进中断服务程序，如果进了，说明ADSP给AP的IPC是好的。

从ROM的只读特性知道放进ROM的code就不能改动了，因此放进ROM的code是经过充分验证的不会再改的代码，在音频领域主要是一些非常成熟的算法的代码，比如MP3解码算法的代码就适合放进ROM里。即以前MP3解码的code和其他的code是放在一起的，以前MP3解码的data和其他的data是放在一起的，现在要把它们拿出来放在一个独立的区域。ROM里的函数调用函数memcpy()时，函数地址还是做ROM时的，可是后面随着软件的开发，memcpy()在RAM上的地址变了。上面六步就是把软件模块固化的过程。

蓝牙语音通话相关的HFP（Hand Free Profile）强烈建议在宽带语音通话时要用上语音丢包补偿（packet lost concealment，PLC）算法来保证丢包时的语音质量，也给出了推荐的PLC算法的浮点实现。不仅找到了，而且还是算平方根的倒数的（Word32 Isqrt(Word32 L_x)，输入是一个32位的值，输出是Q0.31的值），这样除法就变成了乘法。从图上可以看出，在做丢包补偿时，定点的和浮点的实现部分PCM值有误差，但误差都是在1范围内，这是可以接受的。

激活值的分布范围一般都比较广, 这种情况下如果直接使用最大值非饱和量化, 就会把离散点噪声给放大从而影响模型的精度，最好是找到合适的阈值|T|，将|T|/127作为量化scale，把识别率等指标的降幅控制在一个较小的范围内，这就是饱和量化。这个方法用的是饱和量化。发现它不是一个纯定点的实现，即里面有部分是float的，当时觉得里面最关键的权重和激活值都是定点运算了，部分浮点运算可以接受， 我也先做一个非纯定点的实现，把参数个数较少的bias用浮点表示。在函数里根据激活值的量化scale只做激活值的量化。

从图看出，音频帧也分两部分：帧头和帧内容。帧头占一个字节（8个bit），各个比特的含义已在图中表示出来，其中P表示0，FT占4个比特，从二进制的0000到0111，共8个值，对应AMR-NB的8种码率。从上图看出，录音的音频数据是从ADSP-CP的sharememory里取的（ADSP-CP的sharememory放着上下行的音频数据）。从上图看出，每隔固定时长从驱动获得48k的PCM数据，如要保存成WAV格式就重采样成16k，如要保存成AMR格式，不仅重采样成8K, 而且好要做AMR-NB编码得到码流。

从上图可以看出上行要经过audio driver / resampler / VE(AEC/ANS/AGC) / encoder / IMS等模块，下行要经过IMS / decoder / VE(ANS/AGC) / resampler / mixer / audio driver等模块。7） ADSP给AP发DISABLE_ADSP_STREAM_ACK，告诉停止ADSP上的语音流是否OK。9） CP给AP发DISABLE_CP_STREAM_ACK，告诉停止CP上的语音流是否OK。

ADSP没有音频数据时又会通过DATA_REQ向AP要音频数据，AP收到后会向ADSP发送音频数据，当SBC码流的字节数达到A2DP_DATA_REQ请求的个数时又会给AP发A2DP_DATA_REQ_ACK。4） AP收到ADSP发来的DATA_REQ后就会给ADSP回DATA_REQ_ACK，带上音频数据（AP把音频数据放在双方都能访问的share memory里，实际上在命令里带上的是这块音频数据在share memory里的起始地址， ADSP收到命令后从这个起始地址处拿音频数据）。

BT下的驱动相对内置codec下的，ADMA等做些值的修改，主要调ASSP。调驱动时首先调的就是AP与ADSP之间的IPC，确保AP和ADSP之间通信正常，ADSP的log输出正常，能正常dump音频数据，在IPC好的基础上再去调其他的。在一个loop里，ADSP先从上图中的Play buffer里取CP放进去的要播放的语音数据，然后从ADSP audio buffer里取采集到的语音数据，采集到的语音数据经处理（比如重采样）后送到上图中的Record Buffer里，最后给CP发一个IPC中断。

SRC是各种采样率(8k / 16k / 44.1 k /48k等)的转换，以前写过专门的文章，具体见以下文章（不同的是少了一些外设（在手表这种产品形态下就不需要有线耳机和听筒等了），同时把外置codec芯片换成了内置codec，即把codec芯片集成到SOC里面了。有专门的codec芯片厂商，他们把codec芯片的功能做的比较丰富。）介绍了安卓智能手机上的音频。相对智能手机而言，相同的是依旧有AP/ADSP/CP，不同的是不再用安卓系统，同时音频外设只有内置codec上的麦克风和扬声器，以及蓝牙。

即算出的浮点的fbank值作为浮点实现模型的输入，将浮点的Fbank值根据定标转换成定点值作为定点实现模型的输入，然后每层的浮点实现和定点实现并行运行。需要说明的是目前完成的是16bit的定点实现，后面会在此基础上做8bit的定点实现。1， 在python下根据paddlepaddle提供的API（named_parameters）得到模型每层的参数（weight & bias），同时看每层的weight和bias的绝对值的最大值，从而确定参数的Q格式，再以这个Q格式对weight 和bias做量化。

一边训练模型，一边请更多的人用手机录“你好米雅”的唤醒词音频，还要对这些录好的做7k HZ处的低通滤波处理。整个数据集是由3个子数据集（“你好米雅”数据集，“你好米雅”相似词数据集，AIDATATANG数据集）组成的，前两个是同一出品方且用相同的设备录的。又想试试真实录音的wav的准确率如何，请了几个人在办公室环境下用手机录了“你好米雅”的音频，在得到的模型下去测试，结果让我大失所望，识别率特别低。等做产品时用的数据集是私有的，把找到的方法用到模型训练上，就能出一个性能不错的语音唤醒方案。

将音频格式从flac转到wav的两种方法

paddlespeech kws C deployment

PaddleSpeech提供了MDTC模型在Hey Snips数据集上的语音唤醒(KWS)的实现。这篇论文是用空洞时间卷积网络（dilated temporal convolution network, DTCN）的方法来做的，曾获the 2020 personalized voice trigger challenge (PVTC2020)的第二名，可见这个方案是比较优秀的。想看看到底是怎么做的，于是我对其做了一番初探。

音频音量调整中的ramp up & down

远场关键词识别 前端实践 完整方案

语音识别主要分两大类：大词汇量连续语音识别技术（Large Vocabulary Continuous Speech Recognition，LVCSR）和关键词识别（keyword Spotting，KWS）。LVCSR由于对算力要求较高，一般在云端（服务器侧）做，而KWS对算力的要求相对较小，可以在终端上做。我们公司是芯片设计公司，主要设计终端上的芯片，想要在语音识别上做点事情，最可能的是做KWS，于是我们就选择KWS来实践语音识别。按距离远近，语音识别可分为近场识别和远场识别，远场的应用场景更丰富些，

语音识别有近场和远场之分，且很多场景下都会用到麦克风阵列(micphone array)。所谓麦克风阵列是一组位于空间不同位置的麦克风按一定的形状规则布置形成的阵列，是对空间传播声音信号进行空间采样的一种装置，采集到的信号包含了其空间位置信息。近场语音识别将声波看成球面波，它考虑各麦克风接收信号间的幅度差；远场语音识别将声波看成平面波，它忽略各麦克风接收信号间的幅度差，近似认为各接收信号之间是简单的时延关系。麦克风阵列可分为一维、二维和三维麦克风阵列。一维麦克风阵列，即线性麦克风阵列，各个麦克风位于同一条直

做音频软件开发10+年，包括语音通信、语音识别、音乐播放等，大部分时间在做语音通信。做语音通信中又大部分时间在做VoIP语音处理。语音通信是全双工的，既要把自己的语音发送出去让对方听到，又要接收对方的语音让自己听到。发送又可叫做上行或者TX，接收又可叫做下行或者RX。之前写了好多关于VoIP语音处理方面的文章，本文想结合框图对相关知识做一个梳理。先综述发送和接收方向的处理，再具体到每个知识点上。讲到某个知识点，如曾经写过相关的文章，就给出链接，如没有写过，等以后写到时再补上链接。由于一些知识点在发送和接收两

上篇文章（基于MCRA-OMLSA的语音降噪(二)：实现）讲了基于MCRA-OMLSA的语音降噪的软件实现。本篇继续讲，主要讲C语言下怎么对数学库里的求平方根（sqrt()）、求自然指数（exp()）、求自然对数（log()）的函数做替换。1，求平方根求平方根最常用的方法是牛顿迭代法。下图是y = f(x)的曲线，当f(x) =0时的值(α)就是该方程的根。可以通过多次迭代逼近的方法求得这个根，原理如下：任取一个x0，这个值对应的y值为f(x0)。在.