一. AudioTrack根本应用
AudioTrack类能够实现Android平台上音频数据的输入工作,AudioTrack有两种数据加载模式(MODE_STREAM和MODE_STATIC),对应的是数据加载模式和音频流类型,对应着两种齐全不同的应用场景。
MODE_STREAM:在这种模式下,通过write一次次把音频数据写到AudioTrack中。这和平时通过write零碎调用往文件中写数据相似,但这种工作形式每次都须要把数据从用户提供的Buffer中拷贝到AudioTrack外部的Buffer中,这肯定水平上会使引入延时,为了解决这一问题,AudioTrack就引入了第二组模式。
MODE_STATIC:这种模式下,在play之前只须要把所有数据通过一次write调用传递到AudioTrack中的外部缓冲区,后续就不用再传递数据了。这种模式实用于像铃声这种内存占用量较小,延时要求较高的文件。但它也有一个毛病,就是一次write的数据不能太多,否则零碎无奈调配足够的内存来存储全副数据。
1.1 MODE_STATIC模式
MODE_STATIC模式输入音频的形式如下(留神:应用STATIC模式须要先调用write写数据,而后再调用play。)
public class AudioTrackPlayerDemoActivity extends Activity implements OnClickListener{ private static final String TAG = "AudioTrackPlayerDemoActivity"; private Button button; private byte[] audioData; private AudioTrack audioTrack; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); super.setContentView(R.layout.main); this.button = (Button) super.findViewById(R.id.play); this.button.setOnClickListener(this); this.button.setEnabled(false); new AsyncTask<Void,Void,Void>(){ @Override protected Void doInBackground(Void... params){ try{ InputStream in = getResources().openRawResource(R.raw.ding); try{ ByteArrayOutputStream out = new ByteArrayOutputStream(264848); for(int b; (b = in.read())!=-1;){ out.write(b); } Log.d(TAG,"Got the data"); audioData = out.toByteArray(); }finally{ in.close(); } }catch(IOException e){ Log.wtf(TAG,"Failed to read",e); } return null; } @Override protected void onPostExecute(void v){ Log.d(TAG,"Createing track..."); button.setEnable(true); Log.d(TAG,"Enabled button"); } }.execute(); } public void onClick(View view) { this.button.setEnabled(false); this.releaseAudioTrack(); this.audioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, 44100, AudioFormat.CHANNEL_OUT_STEREO, AudioFormat.ENCODING_PCM_16BIT, audioData.length, AudioTrack.MODE_STATIC); Log.d(TAG, "Writing audio data..."); this.audioTrack.write(audioData, 0, audioData.length); Log.d(TAG, "Starting playback"); audioTrack.play(); Log.d(TAG, "Playing"); this.button.setEnabled(true); } private void releaseAudioTrack() { if (this.audioTrack != null) { Log.d(TAG, "Stopping"); audioTrack.stop(); Log.d(TAG, "Releasing"); audioTrack.release(); Log.d(TAG, "Nulling"); } } public void onPause() { super.onPause(); this.releaseAudioTrack(); }}
1.2 MODE_STREAM模式
MODE_STREAM模式输入音频的形式如下:
byte[] tempBuffer = new byte[bufferSize];int readCount = 0;while (dis.available() > 0) { readCount = dis.read(tempBuffer); if (readCount == AudioTrack.ERROR_INVALID_OPERATION || readCount == AudioTrack.ERROR_BAD_VALUE) { continue; } if (readCount != 0 && readCount != -1) { audioTrack.play(); audioTrack.write(tempBuffer, 0, readCount); }}
二. AudioTrack详解
2.1 音频流的类型
在AudioTrack构造函数中,会接触到AudioManager.STREAM_MUSIC这个函数,它的含意与Android系统对音频流的治理和分类无关。
Android将零碎的声音分为好几种流类型,上面是几个常见的:
——STREAM_ALARM:警告声
——STREAM_MUSIC:音乐声,例如music等
——STREAM_RING:铃声
——STREAM_SYSTEM:零碎声音,例如低电提示音,锁屏音等
——STREAM_VOCIE_CALL:通话声
留神:下面这些类型的划分和音频数据自身并没有关系。例如MUSIC和RING类型都能够是某首MP3歌曲。另外,声音流类型的抉择没有固定的规范,例如,铃声预览中的铃声能够设置为MUSIC类型。音频流类型的划分和Audio系统对音频的管理策略无关。
2.2 Buffer调配和Frame的概念
在计算Buffe调配的大小时,咱们常常用到的一个办法就是:getMinBufferSize。这个函数决定了应用层调配多大的数据Buffer。
AudioTrack.getMinBufferSize(8000/*每秒8k个采样点*/,AudioFormat.CHANNEL_CONFIGURATION_STEREO/*双声道*/,AudioFormat.ENCODEING_PCM_16BIT);
从AudioTrack.getMinBufferSize开始追溯代码,能够发现在底层的代码中有一个很重要的概念:Frame(帧)。Frame是一个单位,用来形容数据量的多少。1单位的Frame等于1个采样点的字节数x声道数(比方PCM16,双声道的1个Frame等于2x2=4字节)。1个采样点只针对一个声道,而实际上可能会有一或多个声道。因为不能用一个独立的单位来示意全副声道一次采样的数据量,也就引出了Frame的概念。在目前的声卡驱动程序中,其外部缓冲区也是采样Frame作为单位来调配和治理的。
上面是追溯到的native层的办法:
//minBufCount示意缓冲区的起码个数,它以Frame作为单位uint32_t minBufCount = afLatency / ((1000 * afFrameCount)/afSamplingRate);if(minBufCount < 2) minBufCount = 2; //至多要两个缓冲//计算最小帧个数uint32_tminFrameCount = (afFrameCount*sampleRateInHertz*minBufCount)/afSamplingRate;//依据最小的FrameCount计算最小的缓冲大小intminBufferSize = minFrameCount * (audioFormat = javaAudioTrackFields.PCM16?2:1) * nbChannels;return minBuffSize;
getMinBufSize会综合思考硬件的状况(诸如是否反对采样率,硬件自身的提早状况等)后,得出一个最小缓冲区的大小。个别咱们调配的缓冲大小会是它的整数倍。
2.3 AudioTrack结构过程
每一个音频流对应这一个AudioTrack类的一个实例,每个AudioTrack会在创立时注册到AudioFlinger中,由AudioFlinger把所有的AudioTrack进行混合(Mixer),而后输送到AudioHardware中进行播放,目前Android同时最多能够创立32个音频流,也就是说,Mixer最多会同时解决32个AudioTrack的数据流。
三. AudioTrack与MediaPlayer的比照
播放声音能够用MediaPlayer和AudioTrack,两者都提供了Java API供给用开发这应用。尽管都能够播放声音,但两者还是有很大区别的。
3.1 区别
其中最大的区别是MediaPlayer能够播放多种格局的声音文件,例如MP3、AAC、WAV、OGG、MIDI等。MediaPlayer会在framework层创立对应的音频解码器。而AudioTrack只能播放曾经解码的PCM流,如果比照反对的文件格式的话则是AudioTrack只反对wav格局的音频文件,因为wav格局的音频文件大部分都是PCM流。AudioTrack不创立解码器,所以只能播放不须要解码的wav文件。
3.2 分割
MediaPlayer在framework层还是会创立AudioTrack,把解码后的PCM数据流传递给AudioTrack,AudioTrack再传递给AudioFlinger进行混音,而后才传递给硬件播放,所以是MediaPlayer蕴含了AudioTrack。
3.3 SoundPool
在接触Android音频播放API的时候,发现SoundPool也能够用于播放音频。上面是三者的应用场景:MediaPlayer更加适宜在后盾长时间播放本地音乐文件或者在线的流式资源;SoundPool则适宜播放比拟短的音频片段,比方游戏声音、按键声、铃声片段等,它能够同时播放多个音频;而AudioTrack则更靠近底层,提供了十分弱小的控制能力,反对低提早播放,适宜流媒体和VolP语音电话等场景。
四. 源码
http://github.com/renhui/Audi...