Audio Unit录音（播放伴奏+耳返）
前言
相关文章：
使用VideoToolbox硬编码H.264
使用VideoToolbox硬解码H.264
使用AudioToolbox编码AAC
使用AudioToolbox播放AAC
HLS点播实现（H.264和AAC码流）
HLS推流的实现（iOS和OS X系统）
iOS在线音频流播放
Audio Unit播放PCM文件
前文介绍了如何用Audio Unit播放PCM文件，这次在原来的基础上添加录音的功能，并且把录制的声音再次播放出来实现耳返的效果。
核心思路
仍旧使用Remote I/O Unit，这次开启播放和录制两个功能，播放功能用于伴奏播放，录制功能用于录制人声。
耳返功能的实现在于把实时录音的人声播放出来。
Demo中使用的录制输入单声道，播放输出双声道的形式，把录制进来的人声数据放在左声道，把读取的伴奏音频数据放在右声道。
具体细节
1、初始化AudioUnit，类似Audio Unit播放PCM文件，不过这次要设置AVAudioSession的Category为AVAudioSessionCategoryPlayAndRecord，同时要开启AudioUnit的Record功能，同时要设置RecordCallback函数；
2、加载并打开伴奏文件，在PlayCallback的回调中，读取伴奏数据并塞给AudioUnit；
3、在RecordCallback函数中调用AudioUnitRender加载录音数据到bufferList，并在PlayCallback的回调中，把bufferList的数据copy给AudioUnit；
4、处理好PlayCallback中左右声道数据的对齐后，回调给AudioUnit；
遇到的问题
1、内存分配方式
在给双声道的AudioBufferList分配内存的时候，尝试对buffList.mBuffers[1]分配内存，发现并不可行，因为AudioBufferList默认是只有1个buffer，mBuffers[1]的属性是未初始化的。
最后终于用一种方式解决：
buffList = (AudioBufferList *)malloc(sizeof(AudioBufferList) + (numberBuffers - 1) * sizeof(AudioBuffer));
这种特殊的内存分配在c体系里应该比较常见，但在平时遇见也不太在意。
2、AudioUnitInitialize失败，返回1718449215
在把audioFileFormat设置成双声道的时候，发现AudioUnitInitialize返回1718449215。
在分析了AudioFileFormat的格式和AudioBufferList的结构后猜测，可能是双声道数据格式设置问题。
最后在Format Flags属性添加kAudioFormatFlagIsNonInterleaved后解决。
3、伴奏慢放
在把伴奏添加到右声道播放后，伴奏能播放，但是速度慢了很多。
在仔细对比了输入和输出的数据格式后发现，伴奏的原始格式是这样：
File format:
Sample Rate: 44100
Format ID: lpcm
Format Flags: C
Bytes per Packet: 4
Frames per Packet: 1
Bytes per Frame: 4
Channels per Frame: 2
Bits per Channel: 16
但是在demo中，我是以单声道的方式播放，这样每次就拿到一半时间的数据（左/右声道），播放速度只有原来的一半。
解决方案是每次多读一倍的声音数据，然后取一半，这样就能以正常的速度播放声音。
4、伴奏播放结束后Crash
在伴奏播放完毕后，会产生一个crash，来自系统的AudioConvert。
思考一番，觉得应该是左右声道的数据不一致导致，左声道因为录制人声一直有数据，右声道因为伴奏播放结束没有数据，在转码的时候出现一些异常。
解决方案是把左声道和右声道的数据长度对齐，在伴奏播放结束后，同时调整播放的人声数据。
思考题
怎么把左唱右伴的声音改成混合（每个声道都有伴奏和耳返效果）的方式？
总结
Demo地址
在学习一段时间后，发现AudioUnit的API非常清晰，在出现问题后都能较快定位，值得学习这种API设计。
音频这一块的知识，深入学习后还有更多的坑要踩，做音频播放器的同事说到苹果的底层有很多黑盒实现，经常需要逆向苹果的代码进行分析问题。
在写demo过程中，对AudioUnit有了更好的认知，下一篇介绍AudioConvert和AudioUnit的配合使用，播放aac、mp3、m4a等音频文件。
