jackzhouyu的专栏

可以理解为设置播放相关的参数，如设置播放速度为2，快速播放，后续就会按照这个速度去对音频数据做处理，看看AudioPlaybackRate里有什么?/*播放频率结构他*///播放速度//基音周期//拉伸模式算法//上一个参数表示的算法失效时，如何处理？mSpeed:速度好理解，大于1.0，快速播放，小于1.0减速播放，等于1.0正常播放mPitch:基音或者交音高周期，没有音频专业方面的知识可能不太懂是啥？

ReformatBufferProvider就是用于转换输入和输出的数据format不一致，比如输入是float、输出是int32_t；ClampFloatBufferProvider则是将float类型的音频数据其能量限制在[-3dB，3dB]中。

adjust Channels更新是为了满足dst的channels配置，强行进行映射和填充，没有去确认dst和src的通道是不是对应，举个其实现的例子就明白了：|1|2|1|2| ===>>> |1|2|3|4|1|2|3|4| 3、4通道填充0|1|2|3|4| ==>>> |1|2|1|2|…|3|4|3|4|，多余的3、4通道拼接到数据末尾。

Remix顾名思义，在音乐作品中代指重新编排歌曲，这里将对音频数据进行重新编排，也就是其数据的组合位置等，与上一边文章DownmixerBufferProvider区别的是，支持mix后的channel是多通道，而不仅限于channel_left和channel_right。

看完后是不是觉得很简单，复杂的是如何和effect的downmix库建立连接，真正做downmix的也就是按照几个策略来做，DOWNMIX_TYPE_STRIP和DOWNMIX_TYPE_FOLD；找出音频数据源中，每个channel位置的数据，按照mix的策略进行加法即可。

从Source源端出来的数据，通常是来自于应用层，但没有与应用层直接连接，通过MonoPipe相关类连接，其SourceAudioBufferProvider和MonoPipe相关类的包含关系图如下：如上图，SourceAudioBufferProvider持有MonoPipeReader，依次持有audio_utils_reader，而audio_utils_fifo是一个队列fifo的管理类，应用侧逻辑通过audio_utils_writer往fifo队列写数据，而audio_utils_reader

顾名思义，Audio音频数据缓冲提供，就是提供音频数据的缓冲类，而且这个AudioBufferProvider派生出许多子类，每个子类有不同的用途，至关重要；那它在Android哪个地方使用呢？在PlaybackTread中，接收应用层传递而来的数据，那为什么要专门用这么多Provider类来处理呢？而不只是简单的转发，将应用层的数据转发到PlaybackThread就行了；No、No、No！