[Android 特效] Android 通过流播放声音（一）

转载自http://www.eoeandroid.com/thread-96443-1-1.html

  AudioRecord和AudioTrack类是Android获取和播放音频流的重要类，放置在android.media包中。与该包中的MediaRecorder和MediaPlayer类不同，AudioRecord和AudioTrack类在获取和播放音频数据流时无需通过文件保存和文件读取，可以动态地直接获取和播放音频流，在实时处理音频数据流时非常有用。

       当然，如果用户只想录音后写入文件或从文件中取得音频流进行播放，那么直接使用MediaRecorder和MediaPlayer类是首选方案，因为这两个类使用非常方便，而且成功率很高。而AudioRecord和AudioTrack类的使用却比较复杂，我们发现很多人都不能成功地使用这两个类，甚至认为Android的这两个类是不能工作的。

       其实，AudioRecord和AudioTrack类的使用虽然比较复杂，但是可以工作，我们不仅可以很好地使用了这两个类，而且还通过套接字（Socket）实现了音频数据的网络传输，做到了一端使用AudioRecord获取音频流然后通过套接字传输出去，而另一端通过套接字接收后使用AudioTrack类播放。

       下面是我们对AudioRecord和AudioTrack类在使用方面的经验总结：

        （1）创建AudioRecord和AudioTrack类对象：创建这两个类的对象比较复杂，通过对文档的反复和仔细理解，并通过多次失败的尝试，并在北理工的某个Android大牛的网上的文章启发下，我们也最终成功地创建了这两个类的对象。创建AudioRecord和AudioTrack类对象的代码如下：

       AudioRecord类：

java代码：
m_in_buf_size =AudioRecord.getMinBufferSize(8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT);



m_in_rec = new AudioRecord(MediaRecorder.AudioSource.MIC,8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT,

m_in_buf_size) ;
复制代码
       AudioTrack类：

java代码：
m_out_buf_size = android.media.AudioTrack.getMinBufferSize(8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,

AudioFormat.ENCODING_PCM_16BIT);



m_out_trk = new AudioTrack(AudioManager.STREAM_MUSIC, 8000,

AudioFormat.CHANNEL_CONFIGURATION_MONO,AudioFormat.ENCODING_PCM_16BIT,

m_out_buf_size,

AudioTrack.MODE_STREAM);
复制代码
       （2）关于AudioRecord和AudioTrack类的监听函数，不用也行。

       （3）调试方面，包括初始化后看logcat信息，以确定类的工作状态，初始化是否成功等。

       编写好代码，没有语法错误，调用模拟器运行、调试代码时，logcat发挥了很好的功用。刚调试时，经常会出现模拟器显示出现异常，这时我们可以在代码的一些关键语句后添加如Log.d(“test1″,”OK”)；这样的语句进行标识，出现异常时我们就可以在logcat窗口观察代码执行到哪里出现异常，然后进行相应的修改、调试。模拟器不会出现异常时，又遇到了录放音的问题。录音方面，刚开始选择将语音编码数据存放在多个固定大小的文件中进行传送，但是这种情况下会出现声音断续的现象，而且要反复的建立文件，比较麻烦，后来想到要进行网上传输，直接将语音编码数据以数据流的形式传送，经过验证，这种方法可行并且使代码更加简洁。放音方面，将接收到的数据流存放在一个数组中，然后将数组中数据写到AudioTrack中。刚开始只是“嘟”几声，经过检查发现只是把数据写一次，加入循环，让数据反复写到AudioTrack中，就可以听到正常的语音了。接下来的工作主要是改善话音质量与话音延迟，在进行通话的过程中，观察logcat窗口，发现向数组中写数据时会出现Bufferflow的情况，于是把重心转移到数组大小的影响上，经过试验，发现 AudioRecord一次会读640个数据，然后就对录音和放音中有数组的地方进行实验修改。AudioRecord和AudioTrack进行实例化时，参数中各有一个数组大小，经过试验这个数组大小和AudioRecord和AudioTrack能正常实例化所需的最小Buffer大小（即上面实例化时的m_in_buf_size和m_out_buf_size参数）相等且服务器方进行缓存数据的数组尺寸是上述数值的2倍时，语音质量最好。由于录音和放音的速度不一致，受到北理工大牛的启发，在录音方面，将存放录音数据的数组放到LinkedList中,当LinkedList中数组个数达到2（这个也是经过试验验证话音质量最好时的数据）时，将先录好的数组中数据传送出去。经过上述反复试验和修改，最终使双方通话质量较好，且延时较短。