第一部分 AudioTrack分析

一良价、目的

本文的目的是通過從Audio系統(tǒng)來(lái)分析Android的代碼吗讶，包括Android自定義的那套機(jī)制和一些常見類的使用，比如Thread吗铐，MemoryBase等材部。
分析的流程是：

• 先從API層對(duì)應(yīng)的某個(gè)類開始毫缆，用戶層先要有一個(gè)簡(jiǎn)單的使用流程。
• 根據(jù)這個(gè)流程乐导，一步步進(jìn)入到JNI苦丁，服務(wù)層。在此過程中兽叮，碰到不熟悉或者第一次見到的類或者方法芬骄，都會(huì)解釋。也就是深度優(yōu)先的方法鹦聪。

1.1 分析工具

分析工具很簡(jiǎn)單账阻，就是sourceinsight和android的API doc文檔。當(dāng)然還得有android的源代碼泽本。我這里是基于froyo的源碼淘太。
注意，froyo源碼太多了规丽，不要一股腦的加入到sourceinsight中蒲牧，只要把framwork目錄下的源碼加進(jìn)去就可以了，后續(xù)如要用的話赌莺，再加別的目錄冰抢。

二、Audio系統(tǒng)

先看看Audio里邊有哪些東西艘狭？通過Android的SDK文檔挎扰，發(fā)現(xiàn)主要有三個(gè)：

• AudioManager：這個(gè)主要是用來(lái)管理Audio系統(tǒng)的
• AudioTrack：這個(gè)主要是用來(lái)播放聲音的
• AudioRecord：這個(gè)主要是用來(lái)錄音的
  其中AudioManager的理解需要考慮整個(gè)系統(tǒng)上聲音的策略問題，例如來(lái)電話鈴聲巢音，短信鈴聲等遵倦，主要是策略上的問題。一般看來(lái)官撼，最簡(jiǎn)單的就是播放聲音了媒楼。所以我們打算從AudioTrack開始分析摧扇。

三、AudioTrack（JAVA層）

JAVA的AudioTrack類的代碼在：
framework/base/media/java/android/media/AudioTrack.java中。

3.1 AudioTrack API的使用例子

先看看使用例子独旷，然后跟進(jìn)去分析音榜。至于AudioTrack的其他使用方法和說(shuō)明肥矢，需要大家自己去看API文檔了邓夕。

//根據(jù)采樣率，采樣精度顷链，單雙聲道來(lái)得到frame的大小目代。
int bufsize = AudioTrack.getMinBufferSize(8000,//每秒8K個(gè)點(diǎn)
　　AudioFormat.CHANNEL_CONFIGURATION_STEREO,//雙聲道
AudioFormat.ENCODING_PCM_16BIT);//一個(gè)采樣點(diǎn)16比特-2個(gè)字節(jié)
//注意屈梁，按照數(shù)字音頻的知識(shí)，這個(gè)算出來(lái)的是一秒鐘buffer的大小榛了。
//創(chuàng)建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中寫數(shù)據(jù)
….
trackplayer.stop();//停止播放
trackplayer.release();//釋放底層資源在讶。

這里需要解釋下兩個(gè)東西：

1. AudioTrack.MODE_STREAM的意思：
   AudioTrack中有MODE_STATIC和MODE_STREAM兩種分類。STREAM的意思是由用戶在應(yīng)用程序通過write方式把數(shù)據(jù)一次一次得寫到audiotrack中霜大。這個(gè)和我們?cè)趕ocket中發(fā)送數(shù)據(jù)一樣构哺，應(yīng)用層從某個(gè)地方獲取數(shù)據(jù)，例如通過編解碼得到PCM數(shù)據(jù)战坤，然后write到audiotrack曙强。
   這種方式的壞處就是總是在JAVA層和Native層交互，效率損失較大途茫。
   而STATIC的意思是一開始創(chuàng)建的時(shí)候碟嘴，就把音頻數(shù)據(jù)放到一個(gè)固定的buffer，然后直接傳給audiotrack囊卜，后續(xù)就不用一次次得write了娜扇。AudioTrack會(huì)自己播放這個(gè)buffer中的數(shù)據(jù)。
   這種方法對(duì)于鈴聲等內(nèi)存占用較小栅组，延時(shí)要求較高的聲音來(lái)說(shuō)很適用雀瓢。
2. StreamType
   這個(gè)在構(gòu)造AudioTrack的第一個(gè)參數(shù)中使用。這個(gè)參數(shù)和Android中的AudioManager有關(guān)系玉掸，涉及到手機(jī)上的音頻管理策略刃麸。
   Android將系統(tǒng)的聲音分為以下幾類常見的（未寫全）：

• STREAM_ALARM：警告聲
• STREAM_MUSCI：音樂聲，例如music等
• STREAM_RING：鈴聲
• STREAM_SYSTEM：系統(tǒng)聲音
• STREAM_VOCIE_CALL：電話聲音

為什么要分這么多呢司浪？以前在臺(tái)式機(jī)上開發(fā)的時(shí)候很少知道有這么多的聲音類型泊业，不過仔細(xì)思考下，發(fā)現(xiàn)這樣做是有道理的断傲。例如你在聽music的時(shí)候接到電話脱吱，這個(gè)時(shí)候music播放肯定會(huì)停止智政，此時(shí)你只能聽到電話认罩，如果你調(diào)節(jié)音量的話，這個(gè)調(diào)節(jié)肯定只對(duì)電話起作用续捂。當(dāng)電話打完了垦垂，再回到music，你肯定不用再調(diào)節(jié)音量了牙瓢。

其實(shí)系統(tǒng)將這幾種聲音的數(shù)據(jù)分開管理劫拗，所以，這個(gè)參數(shù)對(duì)AudioTrack來(lái)說(shuō)矾克，它的含義就是告訴系統(tǒng)页慷，我現(xiàn)在想使用的是哪種類型的聲音，這樣系統(tǒng)就可以對(duì)應(yīng)管理他們了。

3.2 分析之getMinBufferSize

AudioTrack的例子就幾個(gè)函數(shù)酒繁。先看看第一個(gè)函數(shù)：

AudioTrack.getMinBufferSize(8000,//每秒8K個(gè)點(diǎn)
　　AudioFormat.CHANNEL_CONFIGURATION_STEREO,//雙聲道
AudioFormat.ENCODING_PCM_16BIT);
----->AudioTrack.JAVA
//注意滓彰，這是個(gè)static函數(shù)
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;--->看到了吧，外面名字搞得這么酷州袒，其實(shí)就是指聲道數(shù)
            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揭绑，對(duì)采樣頻率也有要求，太低或太高都不行郎哭，人耳分辨率在20HZ到40KHZ之間
        if ( (sampleRateInHz < 4000) || (sampleRateInHz > 48000) ) {
            loge("getMinBufferSize(): " + sampleRateInHz +"Hz is not a supported sample rate.");
            return AudioTrack.ERROR_BAD_VALUE;
        }
       //調(diào)用native函數(shù)他匪，夠煩的，什么事情都搞到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中實(shí)現(xiàn)邦蜜。（不了解JNI的一定要學(xué)習(xí)下，否則只能在JAVA層搞亥至，太狹隘了畦徘。）最終對(duì)應(yīng)到函數(shù)
static jint android_media_AudioTrack_get_min_buff_size(JNIEnv *env, jobject thiz,
jint sampleRateInHertz, jint nbChannels, jint audioFormat)
{//注意我們傳入的參數(shù)是：
//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這個(gè)單位，什么意思溶握？經(jīng)過多方查找杯缺，最后還是在ALSA的wiki中
//找到解釋了。一個(gè)frame就是1個(gè)采樣點(diǎn)的字節(jié)數(shù)*聲道睡榆。為啥搞個(gè)frame出來(lái)萍肆？因?yàn)閷?duì)于多//聲道的話，用1個(gè)采樣點(diǎn)的字節(jié)數(shù)表示不全胀屿，因?yàn)椴シ诺臅r(shí)候肯定是多個(gè)聲道的數(shù)據(jù)都要播出來(lái)//才行塘揣。所以為了方便，就說(shuō)1秒鐘有多少個(gè)frame宿崭，這樣就能拋開聲道數(shù)亲铡，把意思表示全了。
    // Ensure that buffer depth covers at least audio hardware latency
    uint32_t minBufCount = afLatency / ((1000 * afFrameCount)/afSamplingRate);
    if (minBufCount < 2) minBufCount = 2;
uint32_t minFrameCount =
 (afFrameCount*sampleRateInHertz*minBufCount)/afSamplingRate;
//下面根據(jù)最小的framecount計(jì)算最小的buffersize   
int minBuffSize = minFrameCount
            * (audioFormat == javaAudioTrackFields.PCM16 ? 2 : 1)
            * nbChannels;
    return minBuffSize;
}

getMinBufSize函數(shù)完了后葡兑，我們得到一個(gè)滿足最小要求的緩沖區(qū)大小奖蔓。這樣用戶分配緩沖區(qū)就有了依據(jù)。下面就需要?jiǎng)?chuàng)建AudioTrack對(duì)象了

3.3 分析之new AudioTrack

先看看調(diào)用函數(shù)：

AudioTrack trackplayer = new AudioTrack(
AudioManager.STREAM_MUSIC,
8000,
　　AudioFormat.CHANNEL_CONFIGURATION_ STEREO,
　　AudioFormat.ENCODING_PCM_16BIT,
　　bufsize,
AudioTrack.MODE_STREAM);//
其實(shí)現(xiàn)代碼在AudioTrack.java中讹堤。
public AudioTrack(int streamType, int sampleRateInHz, int channelConfig, int audioFormat,
            int bufferSizeInBytes, int mode)
    throws IllegalArgumentException {
        mState = STATE_UNINITIALIZED;
       
        // 獲得主線程的Looper吆鹤，這個(gè)在MediaScanner分析中已經(jīng)講過了
        if ((mInitializationLooper = Looper.myLooper()) == null) {
            mInitializationLooper = Looper.getMainLooper();
        }
    //檢查參數(shù)是否合法之類的，可以不管它
        audioParamCheck(streamType, sampleRateInHz, channelConfig, audioFormat, mode);
   //我是用getMinBufsize得到的大小洲守，總不會(huì)出錯(cuò)吧疑务？
        audioBuffSizeCheck(bufferSizeInBytes);
 
        // 調(diào)用native層的native_setup沾凄，把自己的WeakReference傳進(jìn)去了
     //不了解JAVA WeakReference的可以上網(wǎng)自己查一下，很簡(jiǎn)單的
        int initResult = native_setup(new WeakReference<AudioTrack>(this),
                mStreamType, 這個(gè)值是AudioManager.STREAM_MUSIC
 mSampleRate, 這個(gè)值是8000
mChannels, 這個(gè)值是2
mAudioFormat,這個(gè)值是AudioFormat.ENCODING_PCM_16BIT
                mNativeBufferSizeInBytes, //這個(gè)是剛才getMinBufSize得到的
mDataLoadMode);DataLoadMode是MODE_STREAM
         ....
}

上面函數(shù)調(diào)用最終進(jìn)入了JNI層android_media_AudioTrack.cpp下面的函數(shù)

static int
android_media_AudioTrack_native_setup(JNIEnv *env, jobject thiz, jobject weak_this,
        jint streamType, jint sampleRateInHertz, jint channels,
        jint audioFormat, jint buffSizeInBytes, jint memoryMode)
{
    int afSampleRate;
    int afFrameCount;
   下面又要調(diào)用一堆東西知允，煩不煩吶搭独？具體干什么用的，以后分析到AudioSystem再說(shuō)廊镜。
    AudioSystem::getOutputFrameCount(&afFrameCount, streamType)牙肝；
   AudioSystem::getOutputSamplingRate(&afSampleRate, streamType)；
 
   AudioSystem::isOutputChannel(channels)嗤朴；
    popCount是統(tǒng)計(jì)一個(gè)整數(shù)中有多少位為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);
//上面是根據(jù)Buffer大小和一個(gè)Frame大小來(lái)計(jì)算幀數(shù)的配椭。
// AudioTrackJniStorage，就是一個(gè)保存一些數(shù)據(jù)的地方雹姊，這
//里邊有一些有用的知識(shí)股缸，下面再詳細(xì)解釋
    AudioTrackJniStorage* lpJniStorage = new AudioTrackJniStorage();
   
     jclass clazz = env->GetObjectClass(thiz);
      lpJniStorage->mCallbackData.audioTrack_class = (jclass)env->NewGlobalRef(clazz);
     lpJniStorage->mCallbackData.audioTrack_ref = env->NewGlobalRef(weak_this);
     lpJniStorage->mStreamType = atStreamType;
     
//創(chuàng)建真正的AudioTrack對(duì)象
    AudioTrack* lpTrack = new AudioTrack();
       if (memoryMode == javaAudioTrackFields.MODE_STREAM) {
 //如果是STREAM流方式的話，把剛才那些參數(shù)設(shè)進(jìn)去
       lpTrack->set(
            atStreamType,// stream type
            sampleRateInHertz,
            format,// word length, PCM
            channels,
            frameCount,
            0,// flags
            audioCallback,
&(lpJniStorage->mCallbackData),//callback, callback data (user)
            0,// notificationFrames == 0 since not using EVENT_MORE_DATA to feed the AudioTrack
            0,// 共享內(nèi)存吱雏，STREAM模式需要用戶一次次寫敦姻，所以就不用共享內(nèi)存了
            true);// thread can call Java
           
    } else if (memoryMode == javaAudioTrackFields.MODE_STATIC) {
         //如果是static模式，需要用戶一次性把數(shù)據(jù)寫進(jìn)去歧杏，然后
       //再由audioTrack自己去把數(shù)據(jù)讀出來(lái)镰惦，所以需要一個(gè)共享內(nèi)存
//這里的共享內(nèi)存是指C++AudioTrack和AudioFlinger之間共享的內(nèi)容
 //因?yàn)檎嬲シ诺墓ぷ魇怯葾udioFlinger來(lái)完成的。
          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 since not using EVENT_MORE_DATA to feed the AudioTrack
            lpJniStorage->mMemBase,// shared mem
            true);// thread can call Java
    }
 
    if (lpTrack->initCheck() != NO_ERROR) {
        LOGE("Error initializing AudioTrack");
        goto native_init_failure;
    }
//又來(lái)這一招犬绒，把C++AudioTrack對(duì)象指針保存到JAVA對(duì)象的一個(gè)變量中
//這樣旺入，Native層的AudioTrack對(duì)象就和JAVA層的AudioTrack對(duì)象關(guān)聯(lián)起來(lái)了。
    env->SetIntField(thiz, javaAudioTrackFields.nativeTrackInJavaObj, (int)lpTrack);
    env->SetIntField(thiz, javaAudioTrackFields.jniData, (int)lpJniStorage);
 }

1凯力、AudioTrackJniStorage詳解

這個(gè)類其實(shí)就是一個(gè)輔助類茵瘾，但是里邊有一些知識(shí)很重要，尤其是Android封裝的一套共享內(nèi)存的機(jī)制咐鹤。這里一并講解拗秘，把這塊搞清楚了，我們就能輕松得在兩個(gè)進(jìn)程間進(jìn)行內(nèi)存的拷貝祈惶。

AudioTrackJniStorage的代碼很簡(jiǎn)單雕旨。

struct audiotrack_callback_cookie {
    jclass      audioTrack_class;
    jobject     audioTrack_ref;
 }; cookie其實(shí)就是把JAVA中的一些東西保存了下，沒什么特別的意義
class AudioTrackJniStorage {
    public:
        sp<MemoryHeapBase>         mMemHeap;//這兩個(gè)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);
//注意用法行瑞，先弄一個(gè)HeapBase奸腺，再把HeapBase傳入到MemoryBase中去餐禁。
        return true;
    }
};

2血久、MemoryHeapBase

MemroyHeapBase也是Android搞的一套基于Binder機(jī)制的對(duì)內(nèi)存操作的類。既然是Binder機(jī)制帮非，那么肯定有一個(gè)服務(wù)端（Bnxxx）氧吐，一個(gè)代理端Bpxxx讹蘑。看看MemoryHeapBase定義：

class MemoryHeapBase : public virtual BnMemoryHeap
{
 果然筑舅，從BnMemoryHeap派生座慰，那就是Bn端。這樣就和Binder掛上鉤了
//Bp端調(diào)用的函數(shù)最終都會(huì)調(diào)到Bn這來(lái)
對(duì)Binder機(jī)制不了解的翠拣，可以參考：
http://blog.csdn.net/Innost/archive/2011/01/08/6124685.aspx
 有好幾個(gè)構(gòu)造函數(shù)版仔，我們看看我們使用的：
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));
//創(chuàng)建共享內(nèi)存，ashmem_create_region這個(gè)是系統(tǒng)提供的,可以不管它
//設(shè)備上打開的是/dev/ashmem設(shè)備误墓，而Host上打開的是一個(gè)tmp文件
int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" : name, size);
mapfd(fd, size);//把剛才那個(gè)fd通過mmap方式得到一塊內(nèi)存
//不明白得去man mmap看看
mapfd完了后蛮粮，mBase變量指向內(nèi)存的起始位置, mSize是分配的內(nèi)存大小，mFd是
ashmem_create_region返回的文件描述符
 
}
MemoryHeapBase提供了一下幾個(gè)函數(shù)谜慌，可以獲取共享內(nèi)存的大小和位置然想。
getBaseID()--->返回mFd，如果為負(fù)數(shù)欣范，表明剛才創(chuàng)建共享內(nèi)存失敗了
getBase()->返回mBase变泄，內(nèi)存位置
 getSize()->返回mSize，內(nèi)存大小

有了MemoryHeapBase恼琼，又搞了一個(gè)MemoryBase妨蛹，這又是一個(gè)和Binder機(jī)制掛鉤的類。

唉晴竞，這個(gè)估計(jì)是一個(gè)在MemoryHeapBase上的方便類吧滑燃？因?yàn)槲铱匆娏薿ffset
那么估計(jì)這個(gè)類就是一個(gè)能返回當(dāng)前Buffer中寫位置（就是offset）的方便類
這樣就不用用戶到處去計(jì)算讀寫位置了。
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; }
};

好了颓鲜，明白上面兩個(gè)MemoryXXX表窘，我們可以猜測(cè)下大概的使用方法了。

• BnXXX端先分配BnMemoryHeapBase和BnMemoryBase甜滨，
• 然后把BnMemoryBase傳遞到BpXXX
• BpXXX就可以使用BpMemoryBase得到BnXXX端分配的共享內(nèi)存了乐严。

注意，既然是進(jìn)程間共享內(nèi)存衣摩，那么Bp端肯定使用memcpy之類的函數(shù)來(lái)操作內(nèi)存昂验，這些函數(shù)是沒有同步保護(hù)的，而且Android也不可能在系統(tǒng)內(nèi)部為這種共享內(nèi)存去做增加同步保護(hù)艾扮。所以看來(lái)后續(xù)在操作這些共享內(nèi)存的時(shí)候既琴，肯定存在一個(gè)跨進(jìn)程的同步保護(hù)機(jī)制。我們?cè)诤竺嬷v實(shí)際播放的時(shí)候會(huì)碰到泡嘴。
另外甫恩，這里的SharedBuffer最終會(huì)在Bp端也就是AudioFlinger那用到。

3.4 分析之play和write

JAVA層到這一步后就是調(diào)用play和write了酌予。JAVA層這兩個(gè)函數(shù)沒什么內(nèi)容磺箕，都是直接轉(zhuǎn)到native層干活了奖慌。
先看看play函數(shù)對(duì)應(yīng)的JNI函數(shù)

static void
android_media_AudioTrack_start(JNIEnv *env, jobject thiz)
{
//看見沒，從JAVA那個(gè)AudioTrack對(duì)象獲取保存的C++層的AudioTrack對(duì)象指針
//從int類型直接轉(zhuǎn)換成指針松靡。要是以后ARM變成64位平臺(tái)了简僧，看google怎么改！
    AudioTrack *lpTrack = (AudioTrack *)env->GetIntField(
        thiz, javaAudioTrackFields.nativeTrackInJavaObj);
    lpTrack->start(); //這個(gè)以后再說(shuō)
}

下面是write雕欺。我們寫的是short數(shù)組岛马，

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);
}
煩人，又根據(jù)Byte還是Short封裝了下屠列，最終會(huì)調(diào)到重要函數(shù)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) {
//創(chuàng)建的是流的方式蛛枚，所以沒有共享內(nèi)存在track中
//還記得我們?cè)趎ative_setup中調(diào)用的set嗎？流模式下AudioTrackJniStorage可沒創(chuàng)建
//共享內(nèi)存
        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模式的蹦浦，就直接把數(shù)據(jù)拷貝到共享內(nèi)存里
          //當(dāng)然，這個(gè)共享內(nèi)存是pTrack的撞蜂，是我們?cè)趕et時(shí)候把AudioTrackJniStorage的
//共享設(shè)進(jìn)去的
            memcpy(pTrack->sharedBuffer()->pointer(),
data + offsetInBytes, sizeInBytes);
            written = sizeInBytes;
        } else if (audioFormat == javaAudioTrackFields.PCM8) {
           PCM8格式的要先轉(zhuǎn)換成PCM16
           
    }
    return written;
}

到這里盲镶，似乎很簡(jiǎn)單啊，JAVA層的AudioTrack蝌诡，無(wú)非就是調(diào)用write函數(shù)溉贿，而實(shí)際由JNI層的C++ AudioTrack write數(shù)據(jù)。反正JNI這層是再看不出什么有意思的東西了浦旱。

四 AudioTrack（C++層）

接上面的內(nèi)容宇色，我們知道在JNI層，有以下幾個(gè)步驟：

• new了一個(gè)AudioTrack
• 調(diào)用set函數(shù)颁湖，把AudioTrackJniStorage等信息傳進(jìn)去
• 調(diào)用了AudioTrack的start函數(shù)
• 調(diào)用AudioTrack的write函數(shù)

那么宣蠕，我們就看看真正干活的的C++AudioTrack吧。
AudioTrack.cpp位于framework/base/libmedia/AudioTrack.cpp

4.1 new AudioTrack()和set調(diào)用

JNI層調(diào)用的是最簡(jiǎn)單的構(gòu)造函數(shù)：
AudioTrack::AudioTrack()
    : mStatus(NO_INIT) //把狀態(tài)初始化成NO_INIT甥捺。Android大量使用了設(shè)計(jì)模式中的state抢蚀。
{
}
接下來(lái)調(diào)用set。我們看看JNI那set了什么
 lpTrack->set(
            atStreamType, //應(yīng)該是Music吧
            sampleRateInHertz,//8000
            format,// 應(yīng)該是PCM_16吧
            channels,//立體聲=2
            frameCount,//
            0,// flags
            audioCallback, //JNI中的一個(gè)回調(diào)函數(shù)
&(lpJniStorage->mCallbackData),//回調(diào)函數(shù)的參數(shù)
            0,// 通知回調(diào)函數(shù)镰禾，表示AudioTrack需要數(shù)據(jù)皿曲，不過暫時(shí)沒用上
            0,//共享buffer地址，stream模式?jīng)]有
            true);//回調(diào)線程可以調(diào)JAVA的東西
那我們看看set函數(shù)把吴侦。
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再說(shuō)
audio_io_handle_t output =
AudioSystem::getOutput((AudioSystem::stream_type)streamType,
            sampleRate, format, channels, (AudioSystem::output_flags)flags);
  //createTrack？看來(lái)這是真正干活的
    status_t status = createTrack(streamType, sampleRate, format, channelCount,
                                  frameCount, flags, sharedBuffer, output);
 //cbf是JNI傳入的回調(diào)函數(shù)audioCallback
     if (cbf != 0) { //看來(lái)备韧，怎么著也要?jiǎng)?chuàng)建這個(gè)線程了劫樟！
        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;
//啊，看來(lái)和audioFlinger掛上關(guān)系了呀。
    const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger();
  
 //下面這個(gè)調(diào)用最終會(huì)在AudioFlinger中出現(xiàn)毅哗。暫時(shí)不管它听怕。
    sp<IAudioTrack> track = audioFlinger->createTrack(getpid(),
                                                      streamType,
                                                      sampleRate,
                                                      format,
                                                      channelCount,
                                                      frameCount,
                                                      ((uint16_t)flags) << 16,
                                                      sharedBuffer,
                                                      output,
                                                      &status);
 
   //看見沒捧挺，從track也就是AudioFlinger那邊得到一個(gè)IMemory接口
//這個(gè)看來(lái)就是最終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相關(guān)的了。注意我們這里的情況
//STREAM模式?jīng)]有傳入共享buffer闽烙，但是數(shù)據(jù)確實(shí)又需要buffer承載翅睛。
//反正AudioTrack是沒有創(chuàng)建buffer，那只能是剛才從AudioFlinger中得到
//的buffer了黑竞。
        mCblk->buffers = (char*)mCblk + sizeof(audio_track_cblk_t);
    }
    return NO_ERROR;
}

還記得我們說(shuō)MemoryXXX沒有同步機(jī)制捕发，所以這里應(yīng)該有一個(gè)東西能體現(xiàn)同步的，

那么我告訴大家很魂，就在audio_track_cblk_t結(jié)構(gòu)中扎酷。它的頭文件在
framework/base/include/private/media/AudioTrackShared.h
實(shí)現(xiàn)文件就在AudioTrack.cpp中

audio_track_cblk_t::audio_track_cblk_t()
//看見下面的SHARED沒？都是表示跨進(jìn)程共享的意思遏匆。這個(gè)我就不跟進(jìn)去說(shuō)了
//等以后介紹同步方面的知識(shí)時(shí)法挨，再細(xì)說(shuō)
    : 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)
{
}

到這里，大家應(yīng)該都有個(gè)大概的全景了幅聘。

• AudioTrack得到AudioFlinger中的一個(gè)IAudioTrack對(duì)象凡纳，這里邊有一個(gè)很重要的數(shù)據(jù)結(jié)構(gòu)audio_track_cblk_t，它包括一塊緩沖區(qū)地址帝蒿，包括一些進(jìn)程間同步的內(nèi)容荐糜，可能還有數(shù)據(jù)位置等內(nèi)容
• AudioTrack啟動(dòng)了一個(gè)線程，叫AudioTrackThread葛超，這個(gè)線程干嘛的呢暴氏？還不知道
• AudioTrack調(diào)用write函數(shù)，肯定是把數(shù)據(jù)寫到那塊共享緩沖了绣张，然后IAudioTrack在另外一個(gè)進(jìn)程AudioFlinger中（其實(shí)AudioFlinger是一個(gè)服務(wù)偏序，在mediaservice中運(yùn)行）接收數(shù)據(jù)，并最終寫到音頻設(shè)備中胖替。

那我們先看看AudioTrackThread干什么了研儒。

調(diào)用的語(yǔ)句是：
mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava);
AudioTrackThread從Thread中派生，這個(gè)內(nèi)容在深入淺出Binder機(jī)制講過了独令。
反正最終會(huì)調(diào)用AudioTrackAThread的threadLoop函數(shù)端朵。
先看看構(gòu)造函數(shù)
AudioTrack::AudioTrackThread::AudioTrackThread(AudioTrack& receiver, bool bCanCallJava)
    : Thread(bCanCallJava), mReceiver(receiver)
{ //mReceiver就是AudioTrack對(duì)象
 // bCanCallJava為TRUE
}

這個(gè)線程的啟動(dòng)由AudioTrack的start函數(shù)觸發(fā)。

void AudioTrack::start()
{
 //start函數(shù)調(diào)用AudioTrackThread函數(shù)觸發(fā)產(chǎn)生一個(gè)新的線程燃箭，執(zhí)行mAudioTrackThread的
threadLoop
    sp<AudioTrackThread> t = mAudioTrackThread;
t->run("AudioTrackThread", THREAD_PRIORITY_AUDIO_CLIENT);
//讓AudioFlinger中的track也start
    status_t status = mAudioTrack->start();
}
bool AudioTrack::AudioTrackThread::threadLoop()
{
 //太惡心了冲呢，又調(diào)用AudioTrack的processAudioBuffer函數(shù)
return mReceiver.processAudioBuffer(this);
}
bool AudioTrack::processAudioBuffer(const sp<AudioTrackThread>& thread)
{
Buffer audioBuffer;
    uint32_t frames;
    size_t writtenSize;
      ...回調(diào)1
         mCbf(EVENT_UNDERRUN, mUserData, 0);
...回調(diào)2 都是傳遞一些信息到JNI里邊
         mCbf(EVENT_BUFFER_END, mUserData, 0);
         // Manage loop end callback
    while (mLoopCount > mCblk->loopCount) {
        mCbf(EVENT_LOOP_END, mUserData, (void *)&loopCount);
    }
 //下面好像有寫數(shù)據(jù)的東西
      do {
       audioBuffer.frameCount = frames;
//獲得buffer，
       status_t err = obtainBuffer(&audioBuffer, 1);
        size_t reqSize = audioBuffer.size;
//把buffer回調(diào)到JNI那去招狸，這是單獨(dú)一個(gè)線程敬拓，而我們還有上層用戶在那不停
//地write呢邻薯，怎么會(huì)這樣？
        mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer);
         audioBuffer.size = writtenSize;
         frames -= audioBuffer.frameCount;
       releaseBuffer(&audioBuffer); //釋放buffer乘凸，和obtain相對(duì)應(yīng)厕诡，看來(lái)是LOCK和UNLOCK
操作了
    }
    while (frames);
   return true;
}

難道真的有兩處在write數(shù)據(jù)？看來(lái)必須得到mCbf去看看了营勤，傳的是EVENT_MORE_DATA標(biāo)志灵嫌。
mCbf由set的時(shí)候傳入C++的AudioTrack，實(shí)際函數(shù)是：

static void audioCallback(int event, void* user, void *info) {
    if (event == AudioTrack::EVENT_MORE_DATA) {
         //哈哈葛作，太好了寿羞，這個(gè)函數(shù)沒往里邊寫數(shù)據(jù)
        AudioTrack::Buffer* pBuff = (AudioTrack::Buffer*)info;
        pBuff->size = 0; 
     }

從代碼上看，本來(lái)google考慮是異步的回調(diào)方式來(lái)寫數(shù)據(jù)赂蠢，可惜發(fā)現(xiàn)這種方式會(huì)比較復(fù)雜绪穆，尤其是對(duì)用戶開放的JAVA AudioTrack會(huì)很不好處理，所以嘛虱岂，偷偷摸摸得給繞過去了玖院。
太好了，看來(lái)就只有用戶的write會(huì)真正的寫數(shù)據(jù)了量瓜，這個(gè)AudioTrackThread除了通知一下司恳，也沒什么實(shí)際有意義的操作了。

讓我們看看write吧绍傲。

4.2 write

ssize_t AudioTrack::write(const void* buffer, size_t userSize)
{
 夠簡(jiǎn)單扔傅，就是obtainBuffer，memcpy數(shù)據(jù)烫饼，然后releasBuffer
瞇著眼睛都能想到猎塞，obtainBuffer一定是Lock住內(nèi)存了，releaseBuffer一定是unlock內(nèi)存了
     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太復(fù)雜了杠纵，不過大家知道其大概工作方式就可以了
status_t AudioTrack::obtainBuffer(Buffer* audioBuffer, int32_t waitCount)
{
   //恕我中間省略太多荠耽，大部分都是和當(dāng)前數(shù)據(jù)位置相關(guān)，
 uint32_t framesAvail = cblk->framesAvailable();
     cblk->lock.lock();//看見沒比藻，lock了
     result = cblk->cv.waitRelative(cblk->lock, milliseconds(waitTimeMs));
//我發(fā)現(xiàn)很多地方都要判斷遠(yuǎn)端的AudioFlinger的狀態(tài)铝量，比如是否退出了之類的，難道
//沒有一個(gè)好的方法來(lái)集中處理這種事情嗎银亲？
      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?為何寫得這么晦澀難懂？
原來(lái)在obtainBuffer中會(huì)某一次進(jìn)去lock，再某一次進(jìn)去可能就是unlock了轩拨。沒看到obtainBuffer中到處有l(wèi)ock,unlock,wait等同步操作嗎践瓷。一定是這個(gè)道理。難怪寫這么復(fù)雜亡蓉。還使用了少用的goto語(yǔ)句晕翠。
唉，有必要這樣嗎寸宵！

五 AudioTrack總結(jié)

通過這一次的分析崖面，我自己覺得有以下幾個(gè)點(diǎn)：

• AudioTrack的工作原理元咙，尤其是數(shù)據(jù)的傳遞這一塊梯影，做了比較細(xì)致的分析，包括共享內(nèi)存庶香，跨進(jìn)程的同步等甲棍，也能解釋不少疑惑了。
• 看起來(lái)赶掖，最重要的工作是在AudioFlinger中做的感猛。通過AudioTrack的介紹，我們給后續(xù)深入分析AudioFlinger提供了一個(gè)切入點(diǎn)
  工作原理和流程嘛奢赂，再說(shuō)一次好了陪白，JAVA層就看最前面那個(gè)例子吧，實(shí)在沒什么說(shuō)的膳灶。
• AudioTrack被new出來(lái)咱士，然后set了一堆信息，同時(shí)會(huì)通過Binder機(jī)制調(diào)用另外一端的AudioFlinger轧钓，得到IAudioTrack對(duì)象序厉，通過它和AudioFlinger交互。
• 調(diào)用start函數(shù)后毕箍，會(huì)啟動(dòng)一個(gè)線程專門做回調(diào)處理弛房，代碼里邊也會(huì)有那種數(shù)據(jù)拷貝的回調(diào)，但是JNI層的回調(diào)函數(shù)實(shí)際并沒有往里邊寫數(shù)據(jù)而柑，大家只要看write就可以了
• 用戶一次次得write文捶，那AudioTrack無(wú)非就是把數(shù)據(jù)memcpy到共享buffer中咯
• 可想而知，AudioFlinger那一定有一個(gè)線程在memcpy數(shù)據(jù)到音頻設(shè)備中去媒咳。我們拭目以待粹排。

本文轉(zhuǎn)自：http://www.blogjava.net/MEYE/articles/355564.html