Android深入淺出之Audio
第一部分 AudioTrack分析
一 目的
本文的目的是通過從Audio系統來分析Android的代碼，包括Android自定義的那套機制和一些常見類的使用，比如Thread，MemoryBase等。
分析的流程是：
l 先從API層對應的某個類開始，用戶層先要有一個簡單的使用流程。
l 根據這個流程，一步步進入到JNI，服務層。在此過程中，碰到不熟悉或者第一次見到的類或者方法，都會解釋。也就是深度優先的方法。
1.1 分析工具
分析工具很簡單，就是sourceinsight和android的API doc文檔。當然還得有android的源代碼。我這里是基於froyo的源碼。
注意，froyo源碼太多了，不要一股腦的加入到sourceinsight中，只要把framwork目錄下的源碼加進去就可以了，后續如要用的話，再加別的目錄。
二 Audio系統
先看看Audio里邊有哪些東西？通過Android的SDK文檔，發現主要有三個：
l AudioManager：這個主要是用來管理Audio系統的
l AudioTrack：這個主要是用來播放聲音的
l AudioRecord：這個主要是用來錄音的
其中AudioManager的理解需要考慮整個系統上聲音的策略問題，例如來電話鈴聲，短信鈴聲等，主要是策略上的問題。一般看來，最簡單的就是播放聲音了。所以我們打算從AudioTrack開始分析。
三 AudioTrack（JAVA層）
JAVA的AudioTrack類的代碼在：
framework\base\media\java\android\media\AudioTrack.java中。
3.1 AudioTrack API的使用例子
先看看使用例子，然后跟進去分析。至於AudioTrack的其他使用方法和說明，需要大家自己去看API文檔了。
//根據采樣率，采樣精度，單雙聲道來得到frame的大小。 int bufsize = AudioTrack.getMinBufferSize(8000,//每秒8K個點 AudioFormat.CHANNEL_CONFIGURATION_STEREO,//雙聲道 AudioFormat.ENCODING_PCM_16BIT);//一個采樣點16比特-2個字節 //注意，按照數字音頻的知識，這個算出來的是一秒鍾buffer的大小。 //創建AudioTrack AudioTrack trackplayer = new AudioTrack(AudioManager.STREAM_MUSIC, 8000, AudioFormat.CHANNEL_CONFIGURATION_ STEREO, AudioFormat.ENCODING_PCM_16BIT, bufsize, AudioTrack.MODE_STREAM);// trackplayer.play() ;//開始 trackplayer.write(bytes_pkg, 0, bytes_pkg.length) ;//往track中寫數據 …. trackplayer.stop();//停止播放 trackplayer.release();//釋放底層資源。
這里需要解釋下兩個東西：
1 AudioTrack.MODE_STREAM的意思：
AudioTrack中有MODE_STATIC和MODE_STREAM兩種分類。STREAM的意思是由用戶在應用程序通過write方式把數據一次一次得寫到audiotrack中。這個和我們在socket中發送數據一樣，應用層從某個地方獲取數據，例如通過編解碼得到PCM數據，然后write到audiotrack。
這種方式的壞處就是總是在JAVA層和Native層交互，效率損失較大。
而STATIC的意思是一開始創建的時候，就把音頻數據放到一個固定的buffer，然后直接傳給audiotrack，后續就不用一次次得write了。AudioTrack會自己播放這個buffer中的數據。
這種方法對於鈴聲等內存占用較小，延時要求較高的聲音來說很適用。
2 StreamType
這個在構造AudioTrack的第一個參數中使用。這個參數和Android中的AudioManager有關系，涉及到手機上的音頻管理策略。
Android將系統的聲音分為以下幾類常見的（未寫全）：
l STREAM_ALARM：警告聲
l STREAM_MUSCI：音樂聲，例如music等
l STREAM_RING：鈴聲
l STREAM_SYSTEM：系統聲音
l STREAM_VOCIE_CALL：電話聲音
為什么要分這么多呢？以前在台式機上開發的時候很少知道有這么多的聲音類型，不過仔細思考下，發現這樣做是有道理的。例如你在聽music的時候接到電話，這個時候music播放肯定會停止，此時你只能聽到電話，如果你調節音量的話，這個調節肯定只對電話起作用。當電話打完了，再回到music，你肯定不用再調節音量了。
其實系統將這幾種聲音的數據分開管理，所以，這個參數對AudioTrack來說，它的含義就是告訴系統，我現在想使用的是哪種類型的聲音，這樣系統就可以對應管理他們了。
3.2 分析之getMinBufferSize
AudioTrack的例子就幾個函數。先看看第一個函數：
AudioTrack.getMinBufferSize(8000,//每秒8K個點 AudioFormat.CHANNEL_CONFIGURATION_STEREO,//雙聲道 AudioFormat.ENCODING_PCM_16BIT); ----->AudioTrack.JAVA
//注意，這是個static函數
static public int getMinBufferSize(int sampleRateInHz, int channelConfig, int audioFormat) { int channelCount = 0; switch(channelConfig) { case AudioFormat.CHANNEL_OUT_MONO: case AudioFormat.CHANNEL_CONFIGURATION_MONO: channelCount = 1; break; case AudioFormat.CHANNEL_OUT_STEREO: case AudioFormat.CHANNEL_CONFIGURATION_STEREO: channelCount = 2;--->看到了吧，外面名字搞得這么酷，其實就是指聲道數 break; default: loge("getMinBufferSize(): Invalid channel configuration."); return AudioTrack.ERROR_BAD_VALUE; } //目前只支持PCM8和PCM16精度的音頻 if ((audioFormat != AudioFormat.ENCODING_PCM_16BIT) && (audioFormat != AudioFormat.ENCODING_PCM_8BIT)) { loge("getMinBufferSize(): Invalid audio format."); return AudioTrack.ERROR_BAD_VALUE; } //ft，對采樣頻率也有要求，太低或太高都不行，人耳分辨率在20HZ到40KHZ之間 if ( (sampleRateInHz < 4000) || (sampleRateInHz > 48000) ) { loge("getMinBufferSize(): " + sampleRateInHz +"Hz is not a supported sample rate."); return AudioTrack.ERROR_BAD_VALUE; } //調用native函數，夠煩的，什么事情都搞到JNI層去。 int size = native_get_min_buff_size(sampleRateInHz, channelCount, audioFormat); if ((size == -1) || (size == 0)) { loge("getMinBufferSize(): error querying hardware"); return AudioTrack.ERROR; } else { return size; }
native_get_min_buff_size--->在framework/base/core/jni/android_media_track.cpp中實現。（不了解JNI的一定要學習下，否則只能在JAVA層搞，太狹隘了。）最終對應到函數
1 static jint android_media_AudioTrack_get_min_buff_size(JNIEnv *env, jobject thiz, 2 3 jint sampleRateInHertz, jint nbChannels, jint audioFormat) 4 5 {//注意我們傳入的參數是： 6 7 //sampleRateInHertz = 8000 8 9 //nbChannels = 2； 10 11 //audioFormat = AudioFormat.ENCODING_PCM_16BIT 12 13 int afSamplingRate; 14 15 int afFrameCount; 16 17 uint32_t afLatency; 18 19 //下面涉及到AudioSystem，這里先不解釋了， 20 21 //反正知道從AudioSystem那查詢了一些信息 22 23 if (AudioSystem::getOutputSamplingRate(&afSamplingRate) != NO_ERROR) { 24 25 return -1; 26 27 } 28 29 if (AudioSystem::getOutputFrameCount(&afFrameCount) != NO_ERROR) { 30 31 return -1; 32 33 } 34 35 36 37 if (AudioSystem::getOutputLatency(&afLatency) != NO_ERROR) { 38 39 return -1; 40 41 } 42 43 //音頻中最常見的是frame這個單位，什么意思？經過多方查找，最后還是在ALSA的wiki中 44 45 //找到解釋了。一個frame就是1個采樣點的字節數*聲道。為啥搞個frame出來？因為對於多//聲道的話，用1個采樣點的字節數表示不全，因為播放的時候肯定是多個聲道的數據都要播出來//才行。所以為了方便，就說1秒鍾有多少個frame，這樣就能拋開聲道數，把意思表示全了。 46 47 // Ensure that buffer depth covers at least audio hardware latency 48 49 uint32_t minBufCount = afLatency / ((1000 * afFrameCount)/afSamplingRate); 50 51 if (minBufCount < 2) minBufCount = 2; 52 53 uint32_t minFrameCount = 54 55 (afFrameCount*sampleRateInHertz*minBufCount)/afSamplingRate; 56 57 //下面根據最小的framecount計算最小的buffersize 58 59 int minBuffSize = minFrameCount 60 61 * (audioFormat == javaAudioTrackFields.PCM16 ? 2 : 1) 62 63 * nbChannels; 64 65 return minBuffSize; 66 67 }
getMinBufSize函數完了后，我們得到一個滿足最小要求的緩沖區大小。這樣用戶分配緩沖區就有了依據。下面就需要創建AudioTrack對象了
3.3 分析之new AudioTrack
先看看調用函數：
AudioTrack trackplayer = new AudioTrack( AudioManager.STREAM_MUSIC, 8000, AudioFormat.CHANNEL_CONFIGURATION_ STEREO, AudioFormat.ENCODING_PCM_16BIT, bufsize, AudioTrack.MODE_STREAM);
其實現代碼在AudioTrack.java中。
public AudioTrack(int streamType, int sampleRateInHz, int channelConfig, int audioFormat, int bufferSizeInBytes, int mode) throws IllegalArgumentException { mState = STATE_UNINITIALIZED; // 獲得主線程的Looper，這個在MediaScanner分析中已經講過了 if ((mInitializationLooper = Looper.myLooper()) == null) { mInitializationLooper = Looper.getMainLooper(); } //檢查參數是否合法之類的，可以不管它 audioParamCheck(streamType, sampleRateInHz, channelConfig, audioFormat, mode); //我是用getMinBufsize得到的大小，總不會出錯吧？ audioBuffSizeCheck(bufferSizeInBytes); // 調用native層的native_setup，把自己的WeakReference傳進去了 //不了解JAVA WeakReference的可以上網自己查一下，很簡單的 int initResult = native_setup(new WeakReference<AudioTrack>(this), mStreamType, 這個值是AudioManager.STREAM_MUSIC mSampleRate, 這個值是8000 mChannels, 這個值是2 mAudioFormat,這個值是AudioFormat.ENCODING_PCM_16BIT mNativeBufferSizeInBytes, //這個是剛才getMinBufSize得到的 mDataLoadMode);DataLoadMode是MODE_STREAM .... }
上面函數調用最終進入了JNI層android_media_AudioTrack.cpp下面的函數
1 static int 2 3 android_media_AudioTrack_native_setup(JNIEnv *env, jobject thiz, jobject weak_this, 4 5 jint streamType, jint sampleRateInHertz, jint channels, 6 7 jint audioFormat, jint buffSizeInBytes, jint memoryMode) 8 9 { 10 11 int afSampleRate; 12 13 int afFrameCount; 14 15 下面又要調用一堆東西，煩不煩吶？具體干什么用的，以后分析到AudioSystem再說。 16 17 AudioSystem::getOutputFrameCount(&afFrameCount, streamType)； 18 19 AudioSystem::getOutputSamplingRate(&afSampleRate, streamType)； 20 21 22 23 AudioSystem::isOutputChannel(channels)； 24 25 popCount是統計一個整數中有多少位為1的算法 26 27 int nbChannels = AudioSystem::popCount(channels); 28 29 30 31 if (streamType == javaAudioTrackFields.STREAM_MUSIC) { 32 33 atStreamType = AudioSystem::MUSIC; 34 35 } 36 37 int bytesPerSample = audioFormat == javaAudioTrackFields.PCM16 ? 2 : 1; 38 39 int format = audioFormat == javaAudioTrackFields.PCM16 ? 40 41 AudioSystem::PCM_16_BIT : AudioSystem::PCM_8_BIT; 42 43 int frameCount = buffSizeInBytes / (nbChannels * bytesPerSample); 44 45 //上面是根據Buffer大小和一個Frame大小來計算幀數的。 46 47 // AudioTrackJniStorage，就是一個保存一些數據的地方，這 48 49 //里邊有一些有用的知識，下面再詳細解釋 50 51 AudioTrackJniStorage* lpJniStorage = new AudioTrackJniStorage(); 52 53 54 55 jclass clazz = env->GetObjectClass(thiz); 56 57 lpJniStorage->mCallbackData.audioTrack_class = (jclass)env->NewGlobalRef(clazz); 58 59 lpJniStorage->mCallbackData.audioTrack_ref = env->NewGlobalRef(weak_this); 60 61 lpJniStorage->mStreamType = atStreamType; 62 63 64 65 //創建真正的AudioTrack對象 66 67 AudioTrack* lpTrack = new AudioTrack(); 68 69 if (memoryMode == javaAudioTrackFields.MODE_STREAM) { 70 71 //如果是STREAM流方式的話，把剛才那些參數設進去 72 73 lpTrack->set( 74 75 atStreamType,// stream type 76 77 sampleRateInHertz, 78 79 format,// word length, PCM 80 81 channels, 82 83 frameCount, 84 85 0,// flags 86 87 audioCallback, 88 89 &(lpJniStorage->mCallbackData),//callback, callback data (user) 90 91 0,// notificationFrames == 0 since not using EVENT_MORE_DATA to feed the AudioTrack 92 93 0,// 共享內存，STREAM模式需要用戶一次次寫，所以就不用共享內存了 94 95 true);// thread can call Java 96 97 98 99 } else if (memoryMode == javaAudioTrackFields.MODE_STATIC) { 100 101 //如果是static模式，需要用戶一次性把數據寫進去，然后 102 103 //再由audioTrack自己去把數據讀出來，所以需要一個共享內存 104 105 //這里的共享內存是指C++AudioTrack和AudioFlinger之間共享的內容 106 107 //因為真正播放的工作是由AudioFlinger來完成的。 108 109 lpJniStorage->allocSharedMem(buffSizeInBytes); 110 111 lpTrack->set( 112 113 atStreamType,// stream type 114 115 sampleRateInHertz, 116 117 format,// word length, PCM 118 119 channels, 120 121 frameCount, 122 123 0,// flags 124 125 audioCallback, 126 127 &(lpJniStorage->mCallbackData),//callback, callback data (user)); 128 129 0,// notificationFrames == 0 since not using EVENT_MORE_DATA to feed the AudioTrack 130 131 lpJniStorage->mMemBase,// shared mem 132 133 true);// thread can call Java 134 135 } 136 137 138 139 if (lpTrack->initCheck() != NO_ERROR) { 140 141 LOGE("Error initializing AudioTrack"); 142 143 goto native_init_failure; 144 145 } 146 147 //又來這一招，把C++AudioTrack對象指針保存到JAVA對象的一個變量中 148 149 //這樣，Native層的AudioTrack對象就和JAVA層的AudioTrack對象關聯起來了。 150 151 env->SetIntField(thiz, javaAudioTrackFields.nativeTrackInJavaObj, (int)lpTrack); 152 153 env->SetIntField(thiz, javaAudioTrackFields.jniData, (int)lpJniStorage); 154 155 }
1 AudioTrackJniStorage詳解
這個類其實就是一個輔助類，但是里邊有一些知識很重要，尤其是Android封裝的一套共享內存的機制。這里一並講解，把這塊搞清楚了，我們就能輕松得在兩個進程間進行內存的拷貝。
AudioTrackJniStorage的代碼很簡單。
struct audiotrack_callback_cookie {
jclass audioTrack_class;
jobject audioTrack_ref;
};
cookie其實就是把JAVA中的一些東西保存了下，沒什么特別的意義
class AudioTrackJniStorage { public: sp<MemoryHeapBase> mMemHeap;//這兩個Memory很重要 sp<MemoryBase> mMemBase; audiotrack_callback_cookie mCallbackData; int mStreamType; bool allocSharedMem(int sizeInBytes) { mMemHeap = new MemoryHeapBase(sizeInBytes, 0, "AudioTrack Heap Base"); mMemBase = new MemoryBase(mMemHeap, 0, sizeInBytes); //注意用法，先弄一個HeapBase，再把HeapBase傳入到MemoryBase中去。 return true; } };
2 MemoryHeapBase
MemroyHeapBase也是Android搞的一套基於Binder機制的對內存操作的類。既然是Binder機制，那么肯定有一個服務端（Bnxxx），一個代理端Bpxxx。看看MemoryHeapBase定義：
class MemoryHeapBase : public virtual BnMemoryHeap
{
果然，從BnMemoryHeap派生，那就是Bn端。這樣就和Binder掛上鈎了
//Bp端調用的函數最終都會調到Bn這來
對Binder機制不了解的，可以參考：
http://blog.csdn.net/Innost/archive/2011/01/08/6124685.aspx
有好幾個構造函數，我們看看我們使用的：
MemoryHeapBase::MemoryHeapBase(size_t size, uint32_t flags, char const * name) : mFD(-1), mSize(0), mBase(MAP_FAILED), mFlags(flags), mDevice(0), mNeedUnmap(false) { const size_t pagesize = getpagesize(); size = ((size + pagesize-1) & ~(pagesize-1)); //創建共享內存，ashmem_create_region這個是系統提供的,可以不管它 //設備上打開的是/dev/ashmem設備，而Host上打開的是一個tmp文件 int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" : name, size); mapfd(fd, size);//把剛才那個fd通過mmap方式得到一塊內存 //不明白得去man mmap看看
mapfd完了后，mBase變量指向內存的起始位置, mSize是分配的內存大小，mFd是
ashmem_create_region返回的文件描述符
}
MemoryHeapBase提供了一下幾個函數，可以獲取共享內存的大小和位置。
getBaseID()--->返回mFd，如果為負數，表明剛才創建共享內存失敗了
getBase()->返回mBase，內存位置
getSize()->返回mSize，內存大小
有了MemoryHeapBase，又搞了一個MemoryBase，這又是一個和Binder機制掛鈎的類。
唉，這個估計是一個在MemoryHeapBase上的方便類吧？因為我看見了offset
那么估計這個類就是一個能返回當前Buffer中寫位置（就是offset）的方便類
這樣就不用用戶到處去計算讀寫位置了。
class MemoryBase : public BnMemory { public: MemoryBase(const sp<IMemoryHeap>& heap, ssize_t offset, size_t size); virtual sp<IMemoryHeap> getMemory(ssize_t* offset, size_t* size) const; protected: size_t getSize() const { return mSize; } ssize_t getOffset() const { return mOffset; } const sp<IMemoryHeap>& getHeap() const { return mHeap; } };
好了，明白上面兩個MemoryXXX，我們可以猜測下大概的使用方法了。
l BnXXX端先分配BnMemoryHeapBase和BnMemoryBase，
l 然后把BnMemoryBase傳遞到BpXXX
l BpXXX就可以使用BpMemoryBase得到BnXXX端分配的共享內存了。
注意，既然是進程間共享內存，那么Bp端肯定使用memcpy之類的函數來操作內存，這些函數是沒有同步保護的，而且Android也不可能在系統內部為這種共享內存去做增加同步保護。所以看來后續在操作這些共享內存的時候，肯定存在一個跨進程的同步保護機制。我們在后面講實際播放的時候會碰到。
另外，這里的SharedBuffer最終會在Bp端也就是AudioFlinger那用到。
3.4 分析之play和write
JAVA層到這一步后就是調用play和write了。JAVA層這兩個函數沒什么內容，都是直接轉到native層干活了。
先看看play函數對應的JNI函數
static void android_media_AudioTrack_start(JNIEnv *env, jobject thiz) { //看見沒，從JAVA那個AudioTrack對象獲取保存的C++層的AudioTrack對象指針 //從int類型直接轉換成指針。要是以后ARM變成64位平台了，看google怎么改！ AudioTrack *lpTrack = (AudioTrack *)env->GetIntField( thiz, javaAudioTrackFields.nativeTrackInJavaObj); lpTrack->start(); //這個以后再說 }
下面是write。我們寫的是short數組，
static jint android_media_AudioTrack_native_write_short(JNIEnv *env, jobject thiz, jshortArray javaAudioData, jint offsetInShorts, jint sizeInShorts, jint javaAudioFormat) { return (android_media_AudioTrack_native_write(env, thiz, (jbyteArray) javaAudioData, offsetInShorts*2, sizeInShorts*2, javaAudioFormat) / 2); }
煩人，又根據Byte還是Short封裝了下，最終會調到重要函數writeToTrack去
jint writeToTrack(AudioTrack* pTrack, jint audioFormat, jbyte* data, jint offsetInBytes, jint sizeInBytes) { ssize_t written = 0; // regular write() or copy the data to the AudioTrack's shared memory? if (pTrack->sharedBuffer() == 0) { //創建的是流的方式，所以沒有共享內存在track中 //還記得我們在native_setup中調用的set嗎？流模式下AudioTrackJniStorage可沒創建 //共享內存 written = pTrack->write(data + offsetInBytes, sizeInBytes); } else { if (audioFormat == javaAudioTrackFields.PCM16) { // writing to shared memory, check for capacity if ((size_t)sizeInBytes > pTrack->sharedBuffer()->size()) { sizeInBytes = pTrack->sharedBuffer()->size(); } //看見沒？STATIC模式的，就直接把數據拷貝到共享內存里 //當然，這個共享內存是pTrack的，是我們在set時候把AudioTrackJniStorage的 //共享設進去的 memcpy(pTrack->sharedBuffer()->pointer(), data + offsetInBytes, sizeInBytes); written = sizeInBytes; } else if (audioFormat == javaAudioTrackFields.PCM8) { PCM8格式的要先轉換成PCM16 } return written; }
到這里，似乎很簡單啊，JAVA層的AudioTrack，無非就是調用write函數，而實際由JNI層的C++ AudioTrack write數據。反正JNI這層是再看不出什么有意思的東西了。
四 AudioTrack（C++層）
接上面的內容，我們知道在JNI層，有以下幾個步驟：
l new了一個AudioTrack
l 調用set函數，把AudioTrackJniStorage等信息傳進去
l 調用了AudioTrack的start函數
l 調用AudioTrack的write函數
那么，我們就看看真正干活的的C++AudioTrack吧。
AudioTrack.cpp位於framework\base\libmedia\AudioTrack.cpp
4.1 new AudioTrack()和set調用
JNI層調用的是最簡單的構造函數：
AudioTrack::AudioTrack() : mStatus(NO_INIT) //把狀態初始化成NO_INIT。Android大量使用了設計模式中的state。 { }
接下來調用set。我們看看JNI那set了什么
lpTrack->set( atStreamType, //應該是Music吧 sampleRateInHertz,//8000 format,// 應該是PCM_16吧 channels,//立體聲=2 frameCount,// 0,// flags audioCallback, //JNI中的一個回調函數 &(lpJniStorage->mCallbackData),//回調函數的參數 0,// 通知回調函數，表示AudioTrack需要數據，不過暫時沒用上 0,//共享buffer地址，stream模式沒有 true);//回調線程可以調JAVA的東西
那我們看看set函數把。
status_t AudioTrack::set( int streamType, uint32_t sampleRate, int format, int channels, int frameCount, uint32_t flags, callback_t cbf, void* user, int notificationFrames, const sp<IMemory>& sharedBuffer, bool threadCanCallJava) {
...前面一堆的判斷，等以后講AudioSystem再說
audio_io_handle_t output = AudioSystem::getOutput((AudioSystem::stream_type)streamType, sampleRate, format, channels, (AudioSystem::output_flags)flags); //createTrack？看來這是真正干活的 status_t status = createTrack(streamType, sampleRate, format, channelCount, frameCount, flags, sharedBuffer, output); //cbf是JNI傳入的回調函數audioCallback if (cbf != 0) { //看來，怎么着也要創建這個線程了！ mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava); } return NO_ERROR; }
看看真正干活的createTrack
status_t AudioTrack::createTrack( int streamType, uint32_t sampleRate, int format, int channelCount, int frameCount, uint32_t flags, const sp<IMemory>& sharedBuffer, audio_io_handle_t output) { status_t status; //啊，看來和audioFlinger掛上關系了呀。 const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger(); //下面這個調用最終會在AudioFlinger中出現。暫時不管它。 sp<IAudioTrack> track = audioFlinger->createTrack(getpid(), streamType, sampleRate, format, channelCount, frameCount, ((uint16_t)flags) << 16, sharedBuffer, output, &status); //看見沒，從track也就是AudioFlinger那邊得到一個IMemory接口 //這個看來就是最終write寫入的地方 sp<IMemory> cblk = track->getCblk(); mAudioTrack.clear(); mAudioTrack = track; mCblkMemory.clear();//sp<XXX>的clear，就看着做是delete XXX吧 mCblkMemory = cblk; mCblk = static_cast<audio_track_cblk_t*>(cblk->pointer()); mCblk->out = 1; mFrameCount = mCblk->frameCount; if (sharedBuffer == 0) { //終於看到buffer相關的了。注意我們這里的情況 //STREAM模式沒有傳入共享buffer，但是數據確實又需要buffer承載。 //反正AudioTrack是沒有創建buffer，那只能是剛才從AudioFlinger中得到 //的buffer了。 mCblk->buffers = (char*)mCblk + sizeof(audio_track_cblk_t); } return NO_ERROR; }
還記得我們說MemoryXXX沒有同步機制，所以這里應該有一個東西能體現同步的，
那么我告訴大家，就在audio_track_cblk_t結構中。它的頭文件在
framework/base/include/private/media/AudioTrackShared.h
實現文件就在AudioTrack.cpp中
audio_track_cblk_t::audio_track_cblk_t() //看見下面的SHARED沒？都是表示跨進程共享的意思。這個我就不跟進去說了 //等以后介紹同步方面的知識時，再細說 : lock(Mutex::SHARED), cv(Condition::SHARED), user(0), server(0), userBase(0), serverBase(0), buffers(0), frameCount(0), loopStart(UINT_MAX), loopEnd(UINT_MAX), loopCount(0), volumeLR(0), flowControlFlag(1), forceReady(0) { }
到這里，大家應該都有個大概的全景了。
l AudioTrack得到AudioFlinger中的一個IAudioTrack對象，這里邊有一個很重要的數據結構audio_track_cblk_t，它包括一塊緩沖區地址，包括一些進程間同步的內容，可能還有數據位置等內容
l AudioTrack啟動了一個線程，叫AudioTrackThread，這個線程干嘛的呢？還不知道
l AudioTrack調用write函數，肯定是把數據寫到那塊共享緩沖了，然后IAudioTrack在另外一個進程AudioFlinger中（其實AudioFlinger是一個服務，在mediaservice中運行）接收數據，並最終寫到音頻設備中。
那我們先看看AudioTrackThread干什么了。
調用的語句是：
mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava);
AudioTrackThread從Thread中派生，這個內容在深入淺出Binder機制講過了。
反正最終會調用AudioTrackAThread的threadLoop函數。
先看看構造函數
AudioTrack::AudioTrackThread::AudioTrackThread(AudioTrack& receiver, bool bCanCallJava) : Thread(bCanCallJava), mReceiver(receiver) { //mReceiver就是AudioTrack對象 // bCanCallJava為TRUE }
這個線程的啟動由AudioTrack的start函數觸發。
1 void AudioTrack::start() 2 3 { 4 5 //start函數調用AudioTrackThread函數觸發產生一個新的線程，執行mAudioTrackThread的 6 7 threadLoop 8 9 sp<AudioTrackThread> t = mAudioTrackThread; 10 11 t->run("AudioTrackThread", THREAD_PRIORITY_AUDIO_CLIENT); 12 13 //讓AudioFlinger中的track也start 14 15 status_t status = mAudioTrack->start(); 16 17 } 18 19 bool AudioTrack::AudioTrackThread::threadLoop() 20 21 { 22 23 //太惡心了，又調用AudioTrack的processAudioBuffer函數 24 25 return mReceiver.processAudioBuffer(this); 26 27 } 28 29 bool AudioTrack::processAudioBuffer(const sp<AudioTrackThread>& thread) 30 31 { 32 33 Buffer audioBuffer; 34 35 uint32_t frames; 36 37 size_t writtenSize; 38 39 ...回調1 40 41 mCbf(EVENT_UNDERRUN, mUserData, 0); 42 43 ...回調2 都是傳遞一些信息到JNI里邊 44 45 mCbf(EVENT_BUFFER_END, mUserData, 0); 46 47 // Manage loop end callback 48 49 while (mLoopCount > mCblk->loopCount) { 50 51 mCbf(EVENT_LOOP_END, mUserData, (void *)&loopCount); 52 53 } 54 55 //下面好像有寫數據的東西 56 57 do { 58 59 audioBuffer.frameCount = frames; 60 61 //獲得buffer， 62 63 status_t err = obtainBuffer(&audioBuffer, 1); 64 65 size_t reqSize = audioBuffer.size; 66 67 //把buffer回調到JNI那去，這是單獨一個線程，而我們還有上層用戶在那不停 68 69 //地write呢，怎么會這樣？ 70 71 mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer); 72 73 audioBuffer.size = writtenSize; 74 75 frames -= audioBuffer.frameCount; 76 77 releaseBuffer(&audioBuffer); //釋放buffer，和obtain相對應，看來是LOCK和UNLOCK操作了 78 79 } 80 81 while (frames); 82 83 return true; 84 85 } 難道真的有兩處在write數據？看來必須得到mCbf去看看了，傳的是EVENT_MORE_DATA標志。 mCbf由set的時候傳入C++的Audi
oTrack，實際函數是：
static void audioCallback(int event, void* user, void *info) { if (event == AudioTrack::EVENT_MORE_DATA) { //哈哈，太好了，這個函數沒往里邊寫數據 AudioTrack::Buffer* pBuff = (AudioTrack::Buffer*)info; pBuff->size = 0; }
從代碼上看，本來google考慮是異步的回調方式來寫數據，可惜發現這種方式會比較復雜，尤其是對用戶開放的JAVA AudioTrack會很不好處理，所以嘛，偷偷摸摸得給繞過去了。
太好了，看來就只有用戶的write會真正的寫數據了，這個AudioTrackThread除了通知一下，也沒什么實際有意義的操作了。
讓我們看看write吧。
4.2 write
ssize_t AudioTrack::write(const void* buffer, size_t userSize) { 夠簡單，就是obtainBuffer，memcpy數據，然后releasBuffer 眯着眼睛都能想到，obtainBuffer一定是Lock住內存了，releaseBuffer一定是unlock內存了 do { audioBuffer.frameCount = userSize/frameSize(); status_t err = obtainBuffer(&audioBuffer, -1); size_t toWrite; toWrite = audioBuffer.size; memcpy(audioBuffer.i8, src, toWrite); src += toWrite; } userSize -= toWrite; written += toWrite; releaseBuffer(&audioBuffer); } while (userSize); return written; } obtainBuffer太復雜了，不過大家知道其大概工作方式就可以了 status_t AudioTrack::obtainBuffer(Buffer* audioBuffer, int32_t waitCount) { //恕我中間省略太多，大部分都是和當前數據位置相關， uint32_t framesAvail = cblk->framesAvailable(); cblk->lock.lock();//看見沒，lock了 result = cblk->cv.waitRelative(cblk->lock, milliseconds(waitTimeMs)); //我發現很多地方都要判斷遠端的AudioFlinger的狀態，比如是否退出了之類的，難道 //沒有一個好的方法來集中處理這種事情嗎？ if (result == DEAD_OBJECT) { result = createTrack(mStreamType, cblk->sampleRate, mFormat, mChannelCount, mFrameCount, mFlags, mSharedBuffer,getOutput()); } //得到buffer audioBuffer->raw = (int8_t *)cblk->buffer(u); return active ? status_t(NO_ERROR) : status_t(STOPPED); } 在看看releaseBuffer void AudioTrack::releaseBuffer(Buffer* audioBuffer) { audio_track_cblk_t* cblk = mCblk; cblk->stepUser(audioBuffer->frameCount); } uint32_t audio_track_cblk_t::stepUser(uint32_t frameCount) { uint32_t u = this->user; u += frameCount; if (out) { if (bufferTimeoutMs == MAX_STARTUP_TIMEOUT_MS-1) { bufferTimeoutMs = MAX_RUN_TIMEOUT_MS; } } else if (u > this->server) { u = this->server; } if (u >= userBase + this->frameCount) { userBase += this->frameCount; } this->user = u; flowControlFlag = 0; return u; }
奇怪了，releaseBuffer沒有unlock操作啊？難道我失誤了？
再去看看obtainBuffer?為何寫得這么晦澀難懂？
原來在obtainBuffer中會某一次進去lock，再某一次進去可能就是unlock了。沒看到obtainBuffer中到處有lock,unlock,wait等同步操作嗎。一定是這個道理。難怪寫這么復雜。還使用了少用的goto語句。
唉，有必要這樣嗎！
五 AudioTrack總結
通過這一次的分析，我自己覺得有以下幾個點：
l AudioTrack的工作原理，尤其是數據的傳遞這一塊，做了比較細致的分析，包括共享內存，跨進程的同步等，也能解釋不少疑惑了。
l 看起來，最重要的工作是在AudioFlinger中做的。通過AudioTrack的介紹，我們給后續深入分析AudioFlinger提供了一個切入點
工作原理和流程嘛，再說一次好了，JAVA層就看最前面那個例子吧，實在沒什么說的。
l AudioTrack被new出來，然后set了一堆信息，同時會通過Binder機制調用另外一端的AudioFlinger，得到IAudioTrack對象，通過它和AudioFlinger交互。
l 調用start函數后，會啟動一個線程專門做回調處理，代碼里邊也會有那種數據拷貝的回調，但是JNI層的回調函數實際並沒有往里邊寫數據，大家只要看write就可以了
l 用戶一次次得write，那AudioTrack無非就是把數據memcpy到共享buffer中咯
l 可想而知，AudioFlinger那一定有一個線程在memcpy數據到音頻設備中去。我們拭目以待。