以前的神经网络几乎都是部署在云端（服务器上），设备端采集到数据通过网络发送给服务器做inference（推理），结果再通过网络返回给设备端。如今越来越多的神经网络部署在嵌入式设备端上，即inference在设备端上做。嵌入式设备的特点是算力不强、memory小。可以通过对神经网络做量化来降load和省memory，但有时可能memory还吃紧，就需要对神经网络在memory使用上做进一步优化。本文

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

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

上篇（webRTC中音频相关的netEQ（四）：控制命令决策）讲了MCU模块是怎么根据网络延时、抖动缓冲延时和反馈报告等来决定给DSP模块发什么控制命令的。DSP模块根据收到的命令进行相关处理，处理简要流程图如下。从上图看出如果有语音包从packet buffer里取出来先要做解码得到PCM数据，没有就不用做解码了。编解码也是数字信号处理算法的一种，是个相当大的topic，不是本文所关注...

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里，实际上在命令里带上的是这块音频

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

以前的神经网络几乎都是部署在云端（服务器上），设备端采集到数据通过网络发送给服务器做inference（推理），结果再通过网络返回给设备端。如今越来越多的神经网络部署在嵌入式设备端上，即inference在设备端上做。嵌入式设备的特点是算力不强、memory小。可以通过对神经网络做量化来降load和省memory，但有时可能memory还吃紧，就需要对神经网络在memory使用上做进一步优化。本文

1，什么是量化2，为什么要量化3，神经网络模型的量化神经网络模型在训练时都是浮点运算的，得到的模型参数也是浮点的。通常模型参数较多，在inference时也有非常多的乘累加运算。如果处理器的算力有限，在inference时用浮点运算将导致CPU load很高，极大影响性能。而且通常一个参数用浮点数表示占四个字节，而如果用8比特量化的话，一个参数只占一个字节，memory得到了极大的节约，在memo

对于每个功能模块来说，通常都会有多种不同的实现算法，不同的算法在性能和运算复杂度上有优劣，因此先要去评估，选择最适合我们项目的算法。经过一段时间的学习和实践，有了一些输出，也写了关于这个算法理论和实践的几篇文章，具体见《讨论后觉得原因很可能是这个：模型是基于先前单声道的语料训练的，而现在识别时的语音是多声道语音经过前端各算法处理后得到的单声道语音，两者不匹配。就我自己而言，不仅学到了后端深度学习相

本文讲梯度下降（Gradient Descent）前先看看利用梯度下降法进行监督学习（例如分类、回归等）的一般步骤：1， 定义损失函数（Loss Function）2， 信息流forward propagation，直到输出端3， 误差信号back propagation。采用“链式法则”，求损失函数关于参数Θ的梯度4， 利用最优化方法（比如梯度下降法），进行参数更新5， 重复...