下面开始进入hal篇，
如图，是某平台的音频硬件架构图，下面开始解释一下：
在HAL层有一套软件解码和音效处理的code,在LPE中也就是硬件Dsp内部同样有一套 硬解码的逻辑，这种逻辑是专门为Auido的offload模式准备的，而上编文章 提到的其他的混音线程都是走软件解码的。
hal层 下面就是codec driver和 dsp(这里叫lpe)driver了，这里要说明一下，alsa为了 迎合Android的升级 ，Android M之后音频流进一步 细化，分为（fasttrack,deepbuffer,primary）,每一个音频流 都有自己独立的线程，因此在Alsa层 就要针对这几个音频流模拟出相对应的设备节点，对应上图 就是（media pcm, media compr,）等几个节点，这几个设备节点输入的音频流最终会在dsp(lpe)的driver中进行硬件的mixer(也就是图中的箭头“LPE Mixing”)
目前所有的内部带dsp的主流芯片基本都是这个流程 ，大家如果再看驱动代码的话可以参考我如上的分析流程。
下面开始说明Audio hal中我认为 应该重点关注的点：
Audio HAL由三部分构成，这三部分必须实现。
system/media/audio/include/system/audio.h 表征了一个audio device的主要方法
system/media/audio/include/system/audio_policy.h 表征音频策略管理，包括处理音频路由，音量控制等。
hardware/libhardware/include/hardware/audio_effect.h 表征适用于audio的音效，比如downmixing, echo或者noise suppression
除了实现HAL,你需要创建文件 device/company_name/device_name/audio/audio_policy.conf，这个文件用来声明在你设备上的audio device
Android 启动之后 Audioflinger会将audio_policy.conf 中的output,创建出对应的线程。 Dumpsys media.flinger 结果如下
这里 记录了framework中 创建线程的具体信息，大家有兴趣 的话可以 使用dumpsys,看下， audiofliger 和 audiopolicy这两个系统自带的service都做了什么。
好，hal篇就到这里，下篇开始进入kernel 篇~