本文轉載自大神的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文檔，發現主要有三個：
lAudioManager：這個主要是用來管理Audio系統的
lAudioTrack：這個主要是用來播放聲音的
lAudioRecord：這個主要是用來錄音的
其中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
AudioTracktrackplayer = 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将系統的聲音分為以下幾類常見的（未寫全）：
lSTREAM_ALARM：警告聲
lSTREAM_MUSCI：音樂聲，例如music等
lSTREAM_RING：鈴聲
lSTREAM_SYSTEM：系統聲音
lSTREAM_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 intgetMinBufferSize(int sampleRateInHz, int channelConfig, int audioFormat) {
int channelCount = 0;
switch(channelConfig) {
case AudioFormat.CHANNEL_OUT_MONO:
caseAudioFormat.CHANNEL_CONFIGURATION_MONO:
channelCount = 1;
break;
case AudioFormat.CHANNEL_OUT_STEREO:
caseAudioFormat.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層搞，太狹隘了。）最終對應到函數
static jintandroid_media_AudioTrack_get_min_buff_size(JNIEnv *env,jobject thiz,
jintsampleRateInHertz, jint nbChannels, jint audioFormat)
{//注意我們傳入的參數是：
//sampleRateInHertz= 8000
//nbChannels= 2；
//audioFormat= AudioFormat.ENCODING_PCM_16BIT
int afSamplingRate;
int afFrameCount;
uint32_t afLatency;
//下面涉及到AudioSystem，這裡先不解釋了，
//反正知道從AudioSystem那查詢了一些資訊
if(AudioSystem::getOutputSamplingRate(&afSamplingRate) != NO_ERROR) {
return -1;
}
if(AudioSystem::getOutputFrameCount(&afFrameCount) != NO_ERROR) {
return -1;
}
if (AudioSystem::getOutputLatency(&afLatency)!= NO_ERROR) {
return -1;
}
//音頻中最常見的是frame這個機關，什麼意思？經過多方查找，最後還是在ALSA的wiki中
//找到解釋了。一個frame就是1個采樣點的位元組數*聲道。為啥搞個frame出來？因為對于多//聲道的話，用1個采樣點的位元組數表示不全，因為播放的時候肯定是多個聲道的資料都要播出來//才行。是以為了友善，就說1秒鐘有多少個frame，這樣就能抛開聲道數，把意思表示全了。
// Ensure that buffer depth covers at leastaudio hardware latency
uint32_t minBufCount = afLatency / ((1000 *afFrameCount)/afSamplingRate);
if (minBufCount < 2 minBufCount ="2;
uint32_tminFrameCount =
(afFrameCount*sampleRateInHertz*minBufCount)/afSamplingRate;
//下面根據最小的framecount計算最小的buffersize
int minBuffSize =minFrameCount
* (audioFormat ==javaAudioTrackFields.PCM16 ? 2 : 1)
* nbChannels;
return minBuffSize;
}
getMinBufSize函數完了後，我們得到一個滿足最小要求的緩沖區大小。這樣使用者配置設定緩沖區就有了依據。下面就需要建立AudioTrack對象了
3.3 分析之new AudioTrack
先看看調用函數：
AudioTracktrackplayer = new AudioTrack(
AudioManager.STREAM_MUSIC,
8000,
AudioFormat.CHANNEL_CONFIGURATION_STEREO,
AudioFormat.ENCODING_PCM_16BIT,
bufsize,
AudioTrack.MODE_STREAM);//
其實作代碼在AudioTrack.java中。
publicAudioTrack(int streamType, int sampleRateInHz, int channelConfig, intaudioFormat,
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傳進去了
//不了解JAVAWeakReference的可以上網自己查一下，很簡單的
int initResult = native_setup(newWeakReference(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下面的函數
static int
android_media_AudioTrack_native_setup(JNIEnv*env, jobject thiz, jobject weak_this,
jint streamType, jintsampleRateInHertz, jint channels,
jint audioFormat, jint buffSizeInBytes,jint memoryMode)
{
int afSampleRate;
int afFrameCount;
下面又要調用一堆東西，煩不煩呐？具體幹什麼用的，以後分析到AudioSystem再說。
AudioSystem::getOutputFrameCount(&afFrameCount, streamType)；
AudioSystem::getOutputSamplingRate(&afSampleRate, streamType)；
AudioSystem::isOutputChannel(channels)；
popCount是統計一個整數中有多少位為1的算法
int nbChannels = AudioSystem::popCount(channels);
if (streamType ==javaAudioTrackFields.STREAM_MUSIC) {
atStreamType = AudioSystem::MUSIC;
}
int bytesPerSample = audioFormat ==javaAudioTrackFields.PCM16 ? 2 : 1;
int format = audioFormat ==javaAudioTrackFields.PCM16 ?
AudioSystem::PCM_16_BIT :AudioSystem::PCM_8_BIT;
int frameCount = buffSizeInBytes /(nbChannels * bytesPerSample);
//上面是根據Buffer大小和一個Frame大小來計算幀數的。
//AudioTrackJniStorage，就是一個儲存一些資料的地方，這
//裡邊有一些有用的知識，下面再詳細解釋
AudioTrackJniStorage* lpJniStorage = newAudioTrackJniStorage();
jclass clazz =env-<GetObjectClass(thiz);
lpJniStorage-<mCallbackData.audioTrack_class= (jclass)env-<NewGlobalRef(clazz);
lpJniStorage-<mCallbackData.audioTrack_ref =env-<NewGlobalRef(weak_this);
lpJniStorage-<mStreamType =atStreamType;
//建立真正的AudioTrack對象
AudioTrack* lpTrack = new AudioTrack();
if (memoryMode ==javaAudioTrackFields.MODE_STREAM) {
//如果是STREAM流方式的話，把剛才那些參數設進去
lpTrack-<set(
atStreamType,// stream type
sampleRateInHertz,
format,// word length, PCM
channels,
frameCount,
0,// flags
audioCallback,
&(lpJniStorage-<mCallbackData),//callback,callback data (user)
0,// notificationFrames == 0 sincenot using EVENT_MORE_DATA to feed the AudioTrack
0,// 共享記憶體，STREAM模式需要使用者一次次寫，是以就不用共享記憶體了
true);// thread can call Java
} else if (memoryMode ==javaAudioTrackFields.MODE_STATIC) {
//如果是static模式，需要使用者一次性把資料寫進去，然後
//再由audioTrack自己去把資料讀出來，是以需要一個共享記憶體
//這裡的共享記憶體是指C++AudioTrack和AudioFlinger之間共享的内容
//因為真正播放的工作是由AudioFlinger來完成的。
lpJniStorage-<allocSharedMem(buffSizeInBytes);
lpTrack-<set(
atStreamType,// stream type
sampleRateInHertz,
format,// word length, PCM
channels,
frameCount,
0,// flags
audioCallback,
&(lpJniStorage-<mCallbackData),//callback,callback data (user));
0,// notificationFrames == 0 sincenot using EVENT_MORE_DATA to feed the AudioTrack
lpJniStorage-<mMemBase,// sharedmem
true);// thread can call Java
}
if (lpTrack-<initCheck() != NO_ERROR) {
LOGE("Error initializingAudioTrack");
goto native_init_failure;
}
//又來這一招，把C++AudioTrack對象指針儲存到JAVA對象的一個變量中
//這樣，Native層的AudioTrack對象就和JAVA層的AudioTrack對象關聯起來了。
env-<SetIntField(thiz,javaAudioTrackFields.nativeTrackInJavaObj, (int)lpTrack);
env-<SetIntField(thiz,javaAudioTrackFields.jniData, (int)lpJniStorage);
}
1 AudioTrackJniStorage詳解
這個類其實就是一個輔助類，但是裡邊有一些知識很重要，尤其是Android封裝的一套共享記憶體的機制。這裡一并講解，把這塊搞清楚了，我們就能輕松得在兩個程序間進行記憶體的拷貝。
AudioTrackJniStorage的代碼很簡單。
structaudiotrack_callback_cookie {
jclassaudioTrack_class;
jobjectaudioTrack_ref;
};cookie其實就是把JAVA中的一些東西儲存了下，沒什麼特别的意義
classAudioTrackJniStorage {
public:
spmMemHeap;//這兩個Memory很重要
spmMemBase;
audiotrack_callback_cookiemCallbackData;
intmStreamType;
bool allocSharedMem(int sizeInBytes) {
mMemHeap = newMemoryHeapBase(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_tsize, 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檔案
intfd = 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&heap, ssize_t offset, size_t size);
virtual spgetMemory(ssize_t* offset, size_t* size) const;
protected:
size_t getSize() const { return mSize; }
ssize_t getOffset() const { return mOffset;}
const sp& getHeap()const { return mHeap; }
};
好了，明白上面兩個MemoryXXX，我們可以猜測下大概的使用方法了。
lBnXXX端先配置設定BnMemoryHeapBase和BnMemoryBase，
l然後把BnMemoryBase傳遞到BpXXX
lBpXXX就可以使用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,
jintjavaAudioFormat) {
return(android_media_AudioTrack_native_write(env, thiz,
(jbyteArray) javaAudioData,
offsetInShorts*2, sizeInShorts*2,
javaAudioFormat)
/ 2);
}
煩人，又根據Byte還是Short封裝了下，最終會調到重要函數writeToTrack去
jintwriteToTrack(AudioTrack* pTrack, jint audioFormat, jbyte* data,
jint offsetInBytes, jintsizeInBytes) {
ssize_t written = 0;
// regular write() or copy the data to theAudioTrack'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, checkfor 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層，有以下幾個步驟：
lnew了一個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_tAudioTrack::set(
int streamType,
uint32_t sampleRate,
int format,
int channels,
int frameCount,
uint32_t flags,
callback_t cbf,
void* user,
int notificationFrames,
const sp&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 = newAudioTrackThread(*this, threadCanCallJava);
}
return NO_ERROR;
}
看看真正幹活的createTrack
status_tAudioTrack::createTrack(
int streamType,
uint32_t sampleRate,
int format,
int channelCount,
int frameCount,
uint32_t flags,
const sp&sharedBuffer,
audio_io_handle_t output)
{
status_tstatus;
//啊，看來和audioFlinger挂上關系了呀。
const sp&audioFlinger = AudioSystem::get_audio_flinger();
//下面這個調用最終會在AudioFlinger中出現。暫時不管它。
sp track =audioFlinger-<createTrack(getpid(),
streamType,
sampleRate,
format,
channelCount,
frameCount,
((uint16_t)flags) < span>
sharedBuffer,
output,
&status);
//看見沒，從track也就是AudioFlinger那邊得到一個IMemory接口
//這個看來就是最終write寫入的地方
sp cblk =track-<getCblk();
mAudioTrack.clear();
mAudioTrack = track;
mCblkMemory.clear();//sp的clear，就看着做是delete XXX吧
mCblkMemory = cblk;
mCblk =static_cast(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)
{
}
到這裡，大家應該都有個大概的全景了。
lAudioTrack得到AudioFlinger中的一個IAudioTrack對象，這裡邊有一個很重要的資料結構audio_track_cblk_t，它包括一塊緩沖區位址，包括一些程序間同步的内容，可能還有資料位置等内容
lAudioTrack啟動了一個線程，叫AudioTrackThread，這個線程幹嘛的呢？還不知道
lAudioTrack調用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函數觸發。
voidAudioTrack::start()
{
//start函數調用AudioTrackThread函數觸發産生一個新的線程，執行mAudioTrackThread的
threadLoop
sp t =mAudioTrackThread;
t-<run("AudioTrackThread",THREAD_PRIORITY_AUDIO_CLIENT);
//讓AudioFlinger中的track也start
status_t status = mAudioTrack-<start();
}
boolAudioTrack::AudioTrackThread::threadLoop()
{
//太惡心了，又調用AudioTrack的processAudioBuffer函數
return mReceiver.processAudioBuffer(this);
}
bool AudioTrack::processAudioBuffer(constsp& thread)
{
Buffer audioBuffer;
uint32_t frames;
size_t writtenSize;
...回調1
mCbf(EVENT_UNDERRUN, mUserData, 0);
...回調2 都是傳遞一些資訊到JNI裡邊
mCbf(EVENT_BUFFER_END, mUserData, 0);
// Manage loop end callback
while (mLoopCount < mCblk-<loopCount){
mCbf(EVENT_LOOP_END, mUserData, (void*)&loopCount);
}
//下面好像有寫資料的東西
do {
audioBuffer.frameCount = frames;
//獲得buffer，
status_t err = obtainBuffer(&audioBuffer,1);
size_t reqSize = audioBuffer.size;
//把buffer回調到JNI那去，這是單獨一個線程，而我們還有上層使用者在那不停
//地write呢，怎麼會這樣？
mCbf(EVENT_MORE_DATA, mUserData,&audioBuffer);
audioBuffer.size = writtenSize;
frames -= audioBuffer.frameCount;
releaseBuffer(&audioBuffer); //釋放buffer，和obtain相對應，看來是LOCK和UNLOCK
操作了
}
while (frames);
return true;
}
難道真的有兩處在write資料？看來必須得到mCbf去看看了，傳的是EVENT_MORE_DATA标志。
mCbf由set的時候傳入C++的AudioTrack，實際函數是：
static voidaudioCallback(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_tAudioTrack::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_tAudioTrack::obtainBuffer(Buffer* audioBuffer, int32_t waitCount)
{
//恕我中間省略太多，大部分都是和目前資料位置相關，
uint32_tframesAvail = 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
voidAudioTrack::releaseBuffer(Buffer* audioBuffer)
{
audio_track_cblk_t* cblk = mCblk;
cblk-<stepUser(audioBuffer-<frameCount);
}
uint32_t audio_track_cblk_t::stepUser(uint32_tframeCount)
{
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總結
通過這一次的分析，我自己覺得有以下幾個點：
lAudioTrack的工作原理，尤其是資料的傳遞這一塊，做了比較細緻的分析，包括共享記憶體，跨程序的同步等，也能解釋不少疑惑了。
l看起來，最重要的工作是在AudioFlinger中做的。通過AudioTrack的介紹，我們給後續深入分析AudioFlinger提供了一個切入點
工作原理和流程嘛，再說一次好了，JAVA層就看最前面那個例子吧，實在沒什麼說的。
lAudioTrack被new出來，然後set了一堆資訊，同時會通過Binder機制調用另外一端的AudioFlinger，得到IAudioTrack對象，通過它和AudioFlinger互動。
l調用start函數後，會啟動一個線程專門做回調處理，代碼裡邊也會有那種資料拷貝的回調，但是JNI層的回調函數實際并沒有往裡邊寫資料，大家隻要看write就可以了
l使用者一次次得write，那AudioTrack無非就是把資料memcpy到共享buffer中咯
l可想而知，AudioFlinger那一定有一個線程在memcpy資料到音頻裝置中去。我們拭目以待。
轉載自：“http://www.cnblogs.com/innost/archive/2011/01/09/1931457.html”
推薦閱讀另外一篇相關文檔：Android P2P語音通話實作
![與專家面對面：Android開發入門問與答[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)