Android教程網 >> Android技術 >> Android開發實例 >> Android深入淺出之Audio 第一部分 AudioTrack分析

Android深入淺出之Audio 第一部分 AudioTrack分析

編輯：Android開發實例

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層搞，太狹隘了。）最終對應到函數

static jint android_media_AudioTrack_get_min_buff_size(JNIEnv *env, jobject thiz,

jint sampleRateInHertz, 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 least audio hardware latency

uint32_t minBufCount = afLatency / ((1000 * afFrameCount)/afSamplingRate);

if (minBufCount < 2) minBufCount = 2;

uint32_t minFrameCount =

(afFrameCount*sampleRateInHertz*minBufCount)/afSamplingRate;

//下面根據最小的framecount計算最小的buffersize

int minBuffSize = minFrameCount

* (audioFormat == javaAudioTrackFields.PCM16 ? 2 : 1)

* nbChannels;

return minBuffSize;

}

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下面的函數

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;

下面又要調用一堆東西，煩不煩吶？具體干什麼用的，以後分析到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 = 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;

//創建真正的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 since not 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 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;

}

//又來這一招，把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的代碼很簡單。

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函數觸發。

void AudioTrack::start()

{

//start函數調用AudioTrackThread函數觸發產生一個新的線程，執行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()

{

//太惡心了，又調用AudioTrack的processAudioBuffer函數

return mReceiver.processAudioBuffer(this);

}

bool AudioTrack::processAudioBuffer(const sp<AudioTrackThread>& 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 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數據到音頻設備中去。我們拭目以待。

上一頁:Android深入淺出之Audio 第二部分 AudioFlinger分析
下一頁:Android深入淺出之Binder機制

Android開發實例

Android編程入門 Android技術基礎 Android資訊關於Android編程 Android開發 Android開發環境 Android開發實例

相關文章