谈谈音频开发

BT 电话时消耗者是BT，BT会定期的给ADSP发中断来驱动ADSP运转起来，ADSP也会给CP发中断驱动CP运转起来，完成整个通话的处理。从上图看出，蓝牙语音通话时，上行时蓝牙耳机采集语音数据通过蓝牙空口送给SoC上内置的BT core，BT core处理后通过IPC送给ADSP，ADSP处理后通过IPC送给CP，CP处理后通过空口送给对方。所以通话时动态切换设备，ADSP跟CP之间的交互是不需要改变，从而CP上audio相关的代码不需要改变，改变的是ADSP与codec以及BT的交互。

工作中开发到跟蓝牙相关的功能，跟蓝牙同学讨论，能听懂蓝牙相关的术语，定义好跟蓝牙交互的接口。如音频PCM数据是8K采样，就会用CVSD（Continuous Variable Slope Delta Modulation, 连续可变斜率增量调制）编解码，如音频PCM数据是16K采样，就会用mSBC（modified SBC，改进的SBC）编解码。播放蓝牙音乐时，手机手表上的音频PCM数据要通过蓝牙传输给耳机首先要做蓝牙编码。BT Host里主要是蓝牙协议栈，包括多个蓝牙协议，如播放蓝牙音乐用的A2DP等。

唤醒源就是那些能唤醒ADSP的中断，通常配置的唤醒源有其他核的IPC（比如AP的IPC）、内置的timer等，ADSP收到这些中断后就会被唤醒，先走唤醒流程，然后开始工作。上文说过，低功耗模式时memory配的是RETENTION模式，进入低功耗模式后memory里的内容还在，即软件还在，要处理的就是跟硬件相关的。没有音频场景使用时，ADSP的低功耗处理我处理过两种，一种是音频子系统（包含ADSP、SRAM等）没有PMU（power management unit,电源管理单元）的，另一种则是有PMU的。

对于智能手机来说，audio的基本功能如下：codec播放音乐，codec APP录音，codec电话，蓝牙播放音乐，蓝牙电话，codec VoIP电话，蓝牙 VoIP电话。上行时蓝牙耳机采集音频数据通过蓝牙空口发给蓝牙芯片，蓝牙芯片通过PCM bus 和ADMA把音频数据送给ADSP，ADSP处理后送给AP。做bringup时有个相对的先后顺序，比如调IPC通常是最先做的，因为它不仅是核间通信，ADSP上的log以及dump音频数据等debug手段也要靠它，可以说是基础设施了，它好了才可以调其他功能。

中断有中断向量表，表里放的是每个中断的中断服务程序（ISR）。下面是几种场景下的入口地址，主要包括boot时的入口地址（图中定义为0x10,即boot时ADSP从地址0x10处开始运行,然后调函数_boot）、产生异常(exception)时的入口地址(图中定义为0x60,即产生异常时ADSP从地址0x60处开始运行，然后调函数_critical_handler)，发生中断时的入口地址(图中定义为0x70,即发生中断时ADSP从地址0x70处开始运行，然后调函数_common_handler)。

PROVIDE（__DDR_CODE_CACHED_START = ABSOLUTE(.)）就表示定义个一个全局变量__DDR_CODE_CACHED_START，用它来指定要cached的code的起始地址，这个起始地址是用定位符获取的。蓝框7和蓝框8都是放data，只不过一个放的是常量等，一个放的是未初始化的。Elf文件是可执行链接文件，是执行链接的产物（编译后的产物是*.o），elf文件可以在CEVA的IDE集成开发环境上运行，但是不能在芯片上运行。再来看图4，它是关于ROM的。

介绍一款智能手表上音乐播放场景下是怎么做功耗优化的

一般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上的地址变了。上面六步就是把软件模块固化的过程。

不仅找到了，而且还是算平方根的倒数的（Word32 Isqrt(Word32 L_x)，输入是一个32位的值，输出是Q0.31的值），这样除法就变成了乘法。在定点化的过程中，每一步定点化时都要比较定点的结果和浮点的结果，确保误差在很小的范围内，通常不超过1。代码中可以看出x2,y2均是32位的，相乘后很可能超出32位，而Isqrt()的输入是32位的，不能直接使用，需要做些变形，变成 m *从图上可以看出，在做丢包补偿时，定点的和浮点的实现部分PCM值有误差，但误差都是在1范围内，这是可以接受的。

从图看出，音频帧也分两部分：帧头和帧内容。帧头占一个字节（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收到命令后从这个起始地址处拿音频数据）。

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

在音量ramp过程中，要想做好ramp up & down，ramp过程中每个采样点的gain都是不一样的，从当前的gain值逐渐变到目标gain值。上面算出的是ramp up时的值，当ramp down时，就是-ΔdB。mute时相当于把音量从当前值变为-88dB，unmute时就相当于把音量从-88dB变回去)，是个ramp down的过程，几乎就听不到声音了。在ramp过程中假设当前采样点的音量为N dB，对应的gain记为g1，则下个采样点的音量为(N + Δ) dB，对应的gain记为g2。

设共有N个麦克风，A点处为第n个，A处的麦克风的方位角为α（方位角为信号源映射到XY平面上与X轴的夹角），∠AOX = 2*pi*n/N （X轴的方向为角度0）, 令β = ∠AOA’= ∠AOX – α= 2*pi*n/N – α。从上图可以看出，先对每个通道上的语音数据做去混响，同时用每个通道上的语音数据做声源定位得到说话人的角度（方位角和俯仰角等），然后用去混响后的语音数据和算出的说话人的角度去做波束形成得到单通道的语音数据，最后对单通道的语音数据做降噪给后续模块使用。原理讲完了，是在时域下讲的。

在发送方向，从codec芯片采集到语音PCM数据后如有需要首先做重采样（SRC），然后做前处理（回声消除/AEC，噪声抑制/ANS，增益控制/AGC，俗称3A算法）。如果是语音就要去做编码，如果是静音则不需要编码，仅仅是周期性的（比如200毫秒）发送一个带能量大小的SID包给对方，对方收到这个包后去做CNG产生舒适噪声，让通话者感觉更舒服些。当然有些是必须的，比如编解码。9，jitter buffer（JB）：把从网络收到的RTP包放进JB里缓一下，同时把乱序的包排好序等，有利于播放的流畅。

1，求平方根求平方根最常用的方法是牛顿迭代法。下图是y = f(x)的曲线，当f(x) =0时的值(α)就是该方程的根。可以通过多次迭代逼近的方法求得这个根，原理如下：任取一个x0，这个值对应的y值为f(x0)。在.

上篇文章（基于MCRA-OMLSA的语音降噪(一)：原理）讲了基于MCRA-OMLSA降噪的原理，本篇讲怎么做软件实现。软件实现有多种方式。单纯看降噪效果可用python，因为python有丰富的库可用，可节省不少时间，把主要精力放在降噪效果提升上。如果要把算法用在产品上就得用其他语言。我们是芯片公司，且我们team偏底层，最常用的语言是C，所以我又用C实现了该算法。本文先讲讲在python下的实现，再讲讲在C下的实现。一，python下的实现Python有丰富的库，音频文件读取的librosa

前面的几篇文章讲了webRTC中的语音降噪。最近又用到了基于MCRA-OMLSA的语音降噪，就学习了原理并且软件实现了它。MCRA主要用于噪声估计，OMLSA是基于估计出来的噪声去做降噪。类比于webRTC中的降噪方法，也有噪声估计（分位数噪声估计法）和基于估计出来的噪声降噪（维纳滤波），MCRA就相当于分位数噪声估计法，OMLSA就相当于维纳滤波。本文先讲讲怎么用MCRA和OMLSA来做语音降噪的原理，后续会讲怎么来做软件实现。一 MCRAMCRA的全称是Minima Controlled R

上篇(webRTC中语音降噪模块ANS细节详解(三))讲了噪声的初始估计方法以及怎么算先验SNR和后验SNR。 本篇开始讲基于带噪语音和特征的语音和噪声的概率计算方法和噪声估计更新以及基于维纳滤波的降噪。一， 带噪语音和特征条件下的语音概率先看怎么算带噪语音和特征条件下的语音概率。其中会用到先前算好的先验SNR和后验SNR，也会用到特征条件下的语音概率，从而涉及到怎么算特征条件下的语音概率，有了特征条件下的语音概率后带噪语音和特征条件下的语音概率就好算了。1， 带噪语音和特征条件下的语音概.

上篇(webRTC中语音降噪模块ANS细节详解(二))讲了ANS的处理流程和语音在时域和频域的相互转换。本篇开始讲语音降噪的核心部分，首先讲噪声的初始估计以及基于估计出来的噪声算先验信噪比和后验信噪比。1，初始噪声估计webRTC中ANS的初始噪声估计用的是分位数噪声估计法（QBNE，Quantile Based Noise Estimation），对应的论文为《Quantile Based Noise Estimation For Spectral Subtraction And Wiene.

上篇(webRTC中语音降噪模块ANS细节详解(一))讲了维纳滤波的基本原理。本篇先给出webRTC中ANS的基本处理过程，然后讲其中两步（即时域转频域和频域转时域）中的一些处理细节。ANS的基本处理过程如下图1： 图1从图1可以看出，处理过程主要分6步，具体如下：1） 把输入的带噪信...

ANS(adaptive noise suppression) 是webRTC中音频相关的核心模块之一，为众多公司所使用。从2015年开始，我在几个产品中使用了webRTC的3A(AEC/ANS/AGC)模块。以前仅仅是使用，对其中的算法原理只是初步了解。近半年来，我利用业余时间在看着《语音增强：理论与实践》和《实时语音处理时间指南》这两本书，对降噪算法有了更深的理解，同时又对ANS的代码进行了调试，基本掌握了算法实现。我想把我对ANS的理解写出来。由于内容细节较多，就出一个系列吧。webRTC中的ANS是

前面的文章（语音降噪论文“A Hybrid Approach for Speech Enhancement Using MoG Model and Neural Network Phoneme Classifier”的研读 ）梳理了论文的思想。本篇就开始对其实践，主要分以下几步：1，基于一个语料库算出每个音素的单高斯模型；2，训练一个输出是一帧是每个音素概率的NN分类判别模型；3，算法实现及调优。1，得到每个音素的单高斯模型要想得到每个音素的单高斯模型，首先得做好音素对齐，知道某一帧对应哪个音.

最近认真的研读了一篇关于语音降噪的论文（A Hybrid Approach for Speech Enhancement Using MoG Model and Neural Network Phoneme Classifier）。它是一种利用混合模型降噪的方法，即既利用了生成模型（MoG高斯模型），也利用了判别模型（神经网络NN模型）。本文根据自己的理解对原理做了梳理。论文是基于“Speech Enhancement Using a Mixture-Maximum Model”提出的MixMAX.

上篇（基于sinc的音频重采样（一）：原理）讲了基于sinc方法的重采样原理，并给出了数学表达式，如下： (1)本文讲如何基于这个数学表达式来做软件实现。软件实现的细节很多，这里主要讲核心部分。函数srcUD()和filterUD()就是实现的主要函数（这两个函数是在源码基础上作了一定的改动，核心思想没变）。srcUD()是实现一帧中点的重采样...

我在前面的文章《音频开源代码中重采样算法的评估与选择 》中说过sinc方法是较好的音频重采样方法，缺点是运算量大。https://ccrma.stanford.edu/~jos/resample/ 给出了sinc方法的原理文档和软件实现。以前是使用这个算法，没太关注原理和实现细节。去年（2020年）由于项目的需要和组内同学把这个算法的原理和软件实现细节搞清楚了。本文先讲讲sinc方法的原理，后面文章会讲讲软件实现的细节。1，sinc函数和信号的采样与重建在数字信号处理中，sinc函数定义为：.

当音频的声道数多于一个时，音频数据的存放有两种格式，即交织的（interleave）和非交织的（non-interleave）。以最常见的双声道为例，交织和非交织的音频数据存放如下图：上图中L表示左声道数据，R表示右声道数据，整数1、2等表示第几个采样点，这样L1就表示左声道的第一个采样点数据。从上图看出，所谓交织的是指一个采样点的两个声道的数据依次放在一起，非交织的是指先放左声道的所有采样点的数据，再放右声道的所有采样点的数据。在音频处理时，有时需要交织的数据，而有时又需要非交织的数据..

在现实生活中，音频（audio）主要用在两大场景中：语音（voice）和音乐（music）。语音主要用于沟通通信，如打电话，现在由于语音识别的发展，人机语音交互也是语音的一个应用，目前正在风口上，好多大厂都推出了智能音箱。音乐主要用于欣赏，如音乐播放。下面简单介绍音频的基础知识：采样和采样频率：现在是数字时代，在音频处理时要先把音频的模拟信号变成数字信号，这叫A/D转换。要把音频的模拟...

手机可以说是现在人日常生活中最离不开的电子设备了。它自诞生以来，从模拟的发展到数字的，从1G发展到目前的4G以及不久将来的5G，从最初的只有唯一的功能（打电话）发展到目前的全功能，从功能机（feature phone）发展到智能机（smart phone），可谓变化巨大。对于手机上的音频来说，刚开始只有语音通信功能，现在不仅语音通信，还可以听音乐、录音、智能语音（语音输入/语音交互）等。智能手机中...

上一篇文章（Android智能手机上的音频浅析）说本篇将详细讲解Android智能手机中各种音频场景下的音频数据流向，现在我们就开始。智能手机中音频的主要场景有音频播放、音频录制、语音通信等。不同场景下的音频数据流向有很大差异，即使是同一场景，在不同的模式下音频数据流向也有所不同。1，音频播放Android系统audio框架中主要有三种播放模式：low latency playbac...

要想快速运行，data和code最好都放在内部memory，但是内部memory的空间又特别小，DTCM和PTCM都只有几十K Word（DSP上的基本单位是Word，一个Word是两个字节），memory不仅不能随意用，在写代码时时时刻刻都要注意省内存，还要优化（经常遇到的是开发新feature，memory不够了，先优化memory，然后再开发，memory都是一点一点抠出来的），最后优化也抠不出memory了，怎么办呢？既有在ARM上开发的，又有在DSP上开发的，总之各有特色。

语音通信从最初的只有有线通信变成后来的有线通信与无线通信（移动通信）的竞争，当移动语音通信价格下来后有线语音通信明显处于逆势。如今移动语音通信的竞争对手是OTT（On The Top）语音，OTT语音是互联网厂商提供的服务，一般免费，如微信语音。目前语音通信技术上就分成了两大阵营：传统通信阵营和互联网阵营，互相竞争，推动着语音通信技术的发展。具体到编解码器上互联网阵营提出了涵盖语音和音乐的音频编解...

我在前面的文章（Android智能手机上的音频浅析）中说过Android手机上有一块专门用于音频处理的DSP，它的特点是频率低（一般几百MHZ）、内部memory小（通常不超过100k word）。要想让Audio DSP上放下更多的内容以及能流畅的运行，要有一些应对措施。今天就聊聊这些措施。1，频率低的应对措施由于DSP的频率低，要想软件能流畅的运行，就得把运行时的load降下来。...

时延是语音通信中的一个重要指标，当端到端(end2end)的时延（即one-way-delay,单向时延）低于150Ms时人感觉不到，当端到端的时延超过150Ms且小于450Ms时人能感受到但能忍受不影响通话交流，当端到端的时延大于1000Ms时严重影响通话交流，用户体验很差。同时时延也是语音方案过认证的必选项，超过了规定值这个方案是过不了认证的。今天我们就讲讲时延是怎么产生的以及怎么样在通信终端...

上篇文章（语音通信中终端上的时延(latency)及减小方法）说从本篇开始会切入webRTC中的netEQ主题，netEQ是webRTC中音频技术方面的两大核心技术之一（另一核心技术是音频的前后处理，包括AEC、ANS、AGC等，俗称3A算法）。webRTC是Google收购GIPS重新包装后开源出来的，目前已是有巨大影响力的实时音视频通信解决方案。国内的互联网公司，要做实时音视频通信产品，绝大多...

上篇（webRTC中音频相关的netEQ（一）:概述）是netEQ的概述，知道了它主要是用于解决网络延时抖动丢包等问题提高语音质量的，也知道了它有两大单元MCU和DSP组成。MCU 主要是把从网络收到的语音RTP包放进packet buffer内，同时也会根据计算出来的网络延时和抖动缓冲延时以及DSP单元反馈过来的信息决定给DSP发什么控制命令（命令主要有正常播放、加速、减速、丢包补偿、融合等），...

上篇（webRTC中音频相关的netEQ（二）：数据结构）讲了netEQ里主要的数据结构，为理解netEQ的机制打好了基础。本篇主要讲MCU中从网络上收到的RTP包是怎么放进packet buffer和从packet buffer里取出来，以及网络延时值（optBufLevel）和抖动缓冲延时值（buffLevelFilt）的计算。先看RTP语音包是怎么放进packet buffer的。...

上篇（webRTC中音频相关的netEQ（三）：存取包和延时计算）讲了语音包的存取以及网络延时和抖动缓冲延时的计算，MCU也收到了DSP模块发来的反馈报告。本文讲MCU模块如何根据网络延时、抖动缓冲延时和反馈报告等决定发给DSP模块的控制命令， 好让DSP模块先对取出的语音包做解码处理（如果有的话）以及根据这些命令做信号处理。MCU模块给DSP模块发的控制命令主要有正常播放（normal...