携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第31天，点击查看活动详情
一 概述 ：
Android平台应用层音频采集AAC编码发送是多屏互动项目中NDK化后开发的音频模块部分，此部分设计可满足系统级签名的或者非系统级签名的应用使用。
二 Android平台 音频采集 编码 流程****
2.1 音频 采集 编码 发送框架流程****
音频采集编码框架图：
1. 应用采集分为Submix类型（采集系统音频）和Mic类型（采集micphone），需要根据需要传入对应的Type。
2. 采集MIC和有系统签名的Submix时只需要在Androidmanifest.xml中配置CAPTURE_AUDIO_OUTPUT和RECORD_AUDIO权限即可。
3. 采集到的音频数据为原始的PCM数据，需要通过mediacodec编码pcm数据后得到AAC数据。
4. 编码后的AAC数据需要通过RTP封装成一包一包的rtp数据包后在网络上发送给对端。
三 音频 采集编码发送设计详细说明****
3.1 音频采集模块****
1）音频采集模块UML图
2）AudioRecord音频采集
Andorid自带的API audioRecord可以采集对应的音频数据，主要接口是startRecording,read,stop,release三个接口，构造方法主要设置采样率，通道模式，采样原始数据类型位深，缓冲区大小,采集开始后通过read方法读取采集到的音频原始数据即可。
3）TctAudioInterface音频采集
TctAudioInterface音频采集是为了解决音频流转，在framework层提供的音频采集服务，可以直接读取hal层音频数据，必须依赖对应的服务无法在其他android平台使用，采集参数默认是双声道，48K采样率。
3.2 音频 AAC 编码模块****
1）编码模块采用Android自带的硬编码器Mediacodc，编码器工作流程如下：
编码器编码工作流程：
主要的六个函数如下：
dequeueInputBuffer：获取可输入的编码器队列索引
getInputBuffer：获取输入编码的队列缓冲区
queueInputBuffer：向输入队列的缓冲区插入编码前数据
dequeueOutputBuffer：获取可输出的编码器队列索引
getOutputBuffer：获取输出编码队列的缓冲区
releaseOutputBuffer：释放输出编码队列的缓冲器，提供编码输入队列
2）编码后的数据主要为AAC数据，在发送前需要进行ADTS头封装，便于不同设备间可以随时播放音频流数据，有关ADTS介绍如下
ADTS全称是(Audio Data Transport Stream)，是AAC的一种十分常见的传输格式。一般的AAC解码器都需要把AAC的ES流打包成ADTS的格式，一般是在AAC ES流前添加7个字节的ADTS header。ADTS AAC DATA
ADTS内容及结构
ADTS 头中相对有用的信息 采样率、声道数、帧长度。每一个带ADTS头信息的AAC流会清晰的告送解码器他需要的这些信息。
一般情况下ADTS的头信息都是7个字节，分为2部分：
adts_fixed_header(); //ADTS 的固定头信息
adts_variable_header(); //ADTS的可变头信息
syncword ：同步头 总是0xFFF, all bits must be 1，代表着一个ADTS帧的开始
ID：MPEG Version: 0 for MPEG-4, 1 for MPEG-2
Layer：always: '00'
profile：表示使用哪个级别的AAC，有些芯片只支持AAC LC 。在MPEG-2 AAC中定义了3种：
sampling_frequency_index：表示使用的采样率下标，通过这个下标在 Sampling Frequencies[ ]数组中查找得知采样率的值。
There are 13 supported frequencies:
0: 96000 Hz
1: 88200 Hz
2: 64000 Hz
3: 48000 Hz
4: 44100 Hz
5: 32000 Hz
6: 24000 Hz
7: 22050 Hz
8: 16000 Hz
9: 12000 Hz
10: 11025 Hz
11: 8000 Hz
12: 7350 Hz
13: Reserved
14: Reserved
15: frequency is written explicitly
channel_configuration: 表示声道数
0: Defined in AOT Specifc Config
1: 1 channel: front-center
2: 2 channels: front-left, front-right
3: 3 channels: front-center, front-left, front-right
4: 4 channels: front-center, front-left, front-right, back-center
5: 5 channels: front-center, front-left, front-right, back-left, back-right
6:6 channels: front-center, front-left, front-right, back-left, back-right, LFE-channel
7: 8 channels: front-center, front-left, front-right, side-left, side-right, back-left, back-right, LFE-channel
8-15: Reserved
frame_length : 一个ADTS帧的长度包括ADTS头和AAC原始流.
adts_buffer_fullness：0x7FF 说明是码率可变的码流
我们在项目中使用的是固定的长度头，未使用adts_variable_header。
3.3 编码后 数据打包模块****
3.3.1音视频RTP打包
RTP 由 IETF（www.ietf.org/）定义在 RFC 3550和3551中。
RTP被定义为传输音频、视频、模拟数据等实时数据的传输协议，与传统的注的高可靠的数据传输的运输层协议相比，它更加侧重的数据传输的实时性，此协议提供的服务包括数据顺序号、时间标记、传输控制等。
1)、音频RTP打包：
介绍完视频打包后，音频打包相对就很简单，采用采样率48k,双通道，编码等级为AAC-LC每包数据大小在350byte左右，小于UDP通信中的MTU大小，在音视频的RTP打包中就不需要分包发送，每一帧音频数据加上RTP头就可以组成一包用来发送。
3.3.2 音视频私有协议打包：
私有协议打包采用对应的音视频帧编码出来的数据在数据的头加上特定长度的标识来组成一包数据采用tcp传输，具体协议为：
8个字节的时间戳+4个字节的数据长度+音视频单帧数据
