Android 音视频开发（一）：PCM 格式音频的播放与采集

什么是 PCM 格式

声音从模拟信号转化为数字信号的技术，经过采样、量化、编码三个过程将模拟信号数字化。

采样

顾名思义，对模拟信号采集样本，该过程是从时间上对信号进行数字化，例如每秒采集 44100 次，即采样频率 44.1 khz
量化

既然是将音频数字化，那就需要使用二进制来表示声音的每一个样本。例如每个样本使用 16 位长度来表示，即音频的位深度为 16 位
编码

编码就是按照一定的格式记录采样和量化后的数据，比如顺序存储或压缩存储等

编码后经由不同的算法，音频被保存为不同的格式，例如 MP3、AAC 等，而 PCM 就是最为原始的一种格式，PCM 数据是音频的裸数据格式，不经过任何压缩。

从零到一：使用 AudioTrack 支持 PCM 格式音频的播放

AudioTrack 只支持播放 PCM 编码格式的音频流，平时使用的 MediaPlayer 支持 MP3、AAC 等多种音频格式，其内部也是将 MP3 格式文件使用 framework 层创建的解码器解码为 PCM 裸数据，再经由 AudioTrack 播放的。封装过的 Mediaplayer 的 API 是简单好用，但许多细节我们却无法掌控，而使用 AudioTrack，除了播放之外，我们还可以对数据源做许多有意思的操作，二者各有优劣之处。

先通过构造函数来了解 AudioTrack（版本为API26）：

public AudioTrack(AudioAttributes attributes, AudioFormat format, int bufferSizeInBytes, int mode, int sessionId) {...
}

几个参数介绍一下：

AudioAttributes

定义音频的类型，包括音乐、通知、闹钟等，调节音量时也会根据不同的类型进行调节
AudioFormat

定义音频的格式，可配置声道数（单通道、多通道）、编码格式（每个采样数据位深度，8bit、16bit等）、采样率
bufferSizeInBytes

AudioTrack 内部的音频缓冲区的大小，该缓冲区的值不能低于一帧“音频帧”（Frame）的大小，即：采样率 x 位深 x 采样时间 x 通道数，采样时间一般取 2.5ms~120ms 之间，AudioTrack 类提供了 getMinBufferSize() 方法来计算该值
mode

AudioTrack 的两种播放模式，MODE_STATIC 和 MODE_STREAM，前者直接将数据加载进内存，后者是按照一定的间隔不断地写入数据

API26 下原有的两个构造函数已经被标为废弃，建议使用 Builder 来构造 AudioTrack 对象：

private fun createAudioTrack(): AudioTrack {val format = AudioFormat.Builder().setChannelMask(AudioFormat.CHANNEL_OUT_STEREO).setSampleRate(44100).setEncoding(AudioFormat.ENCODING_PCM_16BIT).build()return AudioTrack.Builder().setAudioFormat(format).build()
}

网上介绍 AudioTrack 时常见的如何构造 bufferSizeInBytes也不用关心了，Builder 类会替我们默认生成。

构造出对象后，在调用 play() 函数开启播放后，只要开启一个线程不断地从源文件中读取数据并调用 AudioTrack 的 write() 函数向手机端音频输出设备传输数据，即可播放 PCM 音频。

使用 ffmpeg 将 MP3 转为 PCM

Mac 下安装 ffmpeg：brew install ffmpeg

使用 ffmpeg 将 mp3 转换为 pcm：ffmpeg -i xxx.mp3 -f s16le -ar 44100 -ac 2 -acodec pcm_s16le xxx.pcm

-i 制定输入文件
-f 指定输出编码格式为16byte小端格式
-ar 指定输出采样率
-ac 指定输出通道数
acodec 指定解码格式
xxx.pcm 为输出文件

这里也提供一下我使用的 PCM 文件：hurt-johnny cash.pcm 44.1khz 双通道 16位深

PCM 录制：AudioRecord

MediaRecorder 录制集成了编码、压缩等功能，AudioRecord 录制的是 PCM 格式的音频文件。

同样的，先从构造函数来认识 AudioRecord：

public AudioRecord(AudioAttributes attributes, AudioFormat format, int bufferSizeInBytes, int sessionId) {...
}

接触过 AudioTrack，对 AudioRecord 一定不会感到陌生，其构造函数参数与 AudioTrack 几乎如出一辙，这里就不多说了。

AudioRecord 的 API 与 AudioTrack 也是遥相呼应的，在调用函数 startRecording() 开启录制后，只要开启一个后台线程不断地调用 read() 函数从手机端的音频输入设备（麦克风等）读取音频数据，并写入本地文件，即可实现音频的录制。

扩展支持的音频格式： WAV

最开始提到过音频会被编码成不同的格式，而常见的压缩编码格式 WAV 格式可能是与 PCM 数据最为接近的一种格式。WAV 编码不会进行压缩操作，它只在 PCM 数据格式前加上 44 字节（并不一定严格是 44 字节）来描述音频的基本信息，例如采样率、声道数、数据格式等。来看看 WAV 文件头的格式：

WAV 文件头格式

长度（字节）	内容
4	"RIFF" 字符串
4	从下个地址开始到文件尾的总字节数（音频 data 数据长度 + 44 -8）
4	"WAVE"
4	"fmt "（最后有一个空格）
4	过渡字节（一般为00000010H），若为00000012H则说明数据头携带附加信息（见“附加信息”）
2	格式种类，1 表示为PCM形式的声音数据
2	通道数，单声道为1，双声道为2
4	采样率
4	波形音频数据传送速率，其值为通道数×每秒数据位数×每样本的数据位数／8。播放软件利用此值可以估计缓冲区的大小。
2	每个采样需要的字节数，其值为通道数×位深度／8。播放软件需要一次处理多个该值大小的字节数据，以便将其值用于缓冲区的调整。
2	位深度
4	"data"
4	DATA数据长度

了解了 WAV 文件头的格式，我们可以尝试自己写一个解析 WAV 文件头的方法，结合上文的 AudioTrack 播放 PCM 的内容来看，只要获取到音频的采样率、位深度与声道数就可以播放该音频。自然也就可以播放内容是 PCM 格式的 WAV 文件。

在此之前需要一个 WAV 文件用作测试，可以使用 ffmpeg 将之前转换的 PCM 格式音频转码成 WAV 格式。

使用 ffmpeg 将 PCM 转为 WAV

ffmpeg -i xxx.pcm -f s16le -ar 44100 -ac 2 xxx.wav

也分享一下我使用的 WAV 文件：hurt-johnny cash.wav 44.1khz 双通道 16位深

解析 WAV 文件头

根据上面提到的 WAV 文件头格式，定义一个类用于存放文件头数据：

public class WaveHeader {private String riff; // "RIFF"private int totalLength; //音频 data 数据长度 + 44 -8private String wave; // "WAVE"private String fmt; // "fmt "private int transition; //过渡字节，一般为0x00000010private short type; // PCM：1private short channelMask; // 单声道：1，双声道：2private int sampleRate; //采样率private int rate;  // 波形音频数据传送速率，其值为通道数×每秒数据位数×每样本的数据位数／8private short sampleLength; // 每个采样需要的字节数，其值为通道数×位深度／8private short deepness; //位深度private String data; // "data"private int dataLength; //data数据长度...
}

定义好文件头后，我们使用 BufferedInputStream 从本地文件输入流中挨个字节读取数据即可。

byte 字节转字符串

private static String readString(InputStream inputStream, int length) {byte[] bytes = new byte[length];try {inputStream.read(bytes);return new String(bytes);} catch (IOException e) {e.printStackTrace();return null;}
}

byte 字节转 short、int

需要注意的是 WAV 头中的字节数组是经过反转的，例如表示单通道的字节数组为{1, 0}，其中 1 为低位字节，即原始的字节为 [0, 1]，转换为二进制为 0000 0000 0000 0001，即十进制的 1，代表单通道。

//从输入流中读取 2 个字节并转换为 short
private static short readShort(InputStream inputStream) {byte[] bytes = new byte[2];try {inputStream.read(bytes);//{1, 0}return (short) ((bytes[0] & 0xff) | ((bytes[1] & 0xff) << 8));} catch (IOException e) {e.printStackTrace();return 0;}
}

//从输入流中读取 4 个字节并转换为 int
private static int readInt(InputStream inputStream) {byte[] bytes = new byte[4];try {inputStream.read(bytes);return (int) ((bytes[0] & 0xff) | ((bytes[1] & 0xff) << 8) | ((bytes[2] & 0xff) << 16) | ((bytes[3] & 0xff) << 24));} catch (IOException e) {e.printStackTrace();return 0;}
}

从代码中可以看到，字节转换为整型数据类型（short、int 等）时，需要先与 0xff 做与（&）操作，这是为什么呢？

类型转换时 byte & 0xff 的原因

要究其原因，首先需要搞清楚计算机中的原码、反码和补码，这个在之前的文章《Bitmap 图像灰度变换原理浅析》中计算 int 数据类型的值范围时也提到过。下面举个栗子来验证一下，类型转换前 & 0xff 到底有什么用：

假定有一个 byte 数组：[0, 0, -1, 0]，想求得这 4 个字节代表的 int 值得大小，重点看第三个字节，其值为 -1，byte 占一个字节 8 位，易得：

原码：1000 0001
反码：1111 1110
补码：1111 1111

显而易见，这个 byte 数组代表的 int 值的二进制值为：

0000 0000 0000 0000 1000 0001 0000 0000

只要对 -1 左移 8 位即可。so easy！

byte a = -1;
int b = a << 8; //结果是 -256

值为负数就说明以上转换必然是错的。因为我们想要的结果是 0000 0000 0000 0000 1000 0001 0000 0000，该二进制最高位符号位为 0，结果必然是一个正数。

我们知道计算机在运算时使用的是补码，则（byte）-1 << 8 运算时，计算机会对 -1 的补码 1111 1111 做位移操作，结果为 1111 1111 0000 0000，其原码为 1000 0001 0000 0000，先记作 16位原码A，当该值赋值给 int 类型的变量时，int 类型占 4 个字节 32 位，则需要对原因的 16 位值做位扩展，负数在位扩展时会对多出的高位补 1（正数补 0），则扩展后的值为 1111 1111 1111 1111 1111 1111 0000 0000，转为原码为 1000 0000 0000 0000 0000 0001 0000 0000，记作 32位原码B，与上面的 16 位原码做比较可以发现，二者最高位都是 1，低位的值也相同，两个二进制的值在十进制上是一致的，这就是负数补码高位补 1 的原因：为了保持十进制的一致性。不难理解这样做的原因，否则 short 类型强制为 int 类型后值就发生变化了，这明显是不可接受的。

回到我们的需求，我们这里并不需要保持十进制的一致性，所以要先与 0xff 做与运算，因为 0xff 是十六进制 32 位，二进制值为 32 个 1，-1 & 0xff 时，8 位与 32 位运算时，8 位的需要先在高位补 0 补齐到 32 位才会做运算，所以
-1 & 0xff 的结果为补码：1111 1111 前面带 24 个 0，最高位为正数，再对结果做位移操作，得到的二进制值补码为：0000 0000 0000 0000 1111 1111 0000 0000，因为是正数，原码与补码相同，该二进制值为 65280。可以验证下：

byte a = -1;
int c = (a & 0xff) << 8; //结果是 65280

概括一下就是：

类型转换时补码位扩展（例如 2 个字节转 4 个字节，即 short 转 int）的规则：正数高位补 0，负数高位补1，以此保持十进制的一致性
运算时，补码高位统一补 0

这里也附上将 byte 转二进制（补码）的方法：

public static String binary(byte bytes, int radix){byte[] bytes1 = new byte[1];bytes1[0] = bytes;return new BigInteger(1, bytes1).toString(radix);// 这里的1代表正数
}

顺序读取，构造 WavHeader

接着只要使用 InputStream 从目标音频中顺序读取各个参数的值并构造 WavHeader 即可，因为 Header 成员变量众多，所以考虑用建造者模式来构建 Header：

WaveHeader.Builder builder = new WaveHeader.Builder().setRiff(readString(dis, 4)).setTotalLength(readInt(dis)).setWave(readString(dis, 4)).setFmt(readString(dis, 4))...

另外上面提到过，并非所以 WAV 文件头都是标准的 44 个字节，例如我上面提供的 ffmpeg 转码后的 WAV 文件，其文件头的长度就是 78 个字节。对于文件头长度不一致的问题，我的解决方法是从 37 个字节开始，2 个 2 个字节地读取，直到读取到“da”和“ta”，之后再往后读取 4 个字节的 int 值作为 data 数据长度。读取到 header 后，后面播放的就不用说了，复用上面播放 PCM 的代码即可。

需要说明的是我只是从网上随机下载了几个 wav 格式音频测试了下是可以正常播放的，并没有经过广泛验证和对常见的 WAV 文件头格式的考证，所以可能还存在兼容问题。

经过这些以上的学习以及众多资料的查阅，对 Android 端音频开发有了一些小小的认识。后面还会学习一下使用 LAME 将 PCM 转码为 MP3，并实现一些真正意义上的音频播放器的基础功能等。再后面会学习一些视频方面的知识，包括 MediaExtractor、MediaMuxer 解析、封装 MP4 文件、OpenGL ES 渲染图像、MediaCodec 对音视频的硬编、硬解等，并使用一些流行的开源项目例如 ffmpeg 实现一些炫酷的视频处理功能，希望可以在 Android 音视频开发这一块能有所深入，学习过程中的一些收获和困惑也会坚持记录下来。

此路迢迢，与君共勉。

以上源码见 Github

作者：扬州慢_
链接：https://www.jianshu.com/p/a59e8f51d6f2
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。