這篇文章主要講解了“AudioTrack API怎么使用”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“AudioTrack API怎么使用”吧！

10年積累的網(wǎng)站建設(shè)、網(wǎng)站設(shè)計經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識你，你也不認(rèn)識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有扶綏免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

一 目的

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

分析的流程是：

l         先從API層對應(yīng)的某個類開始，用戶層先要有一個簡單的使用流程。

l         根據(jù)這個流程，一步步進(jìn)入到JNI，服務(wù)層。在此過程中，碰到不熟悉或者***次見到的類或者方法，都會解釋。也就是深度優(yōu)先的方法。

1.1 分析工具

分析工具很簡單，就是sourceinsight和android的API doc文檔。當(dāng)然還得有android的源代碼。我這里是基于froyo的源碼。

注意，froyo源碼太多了，不要一股腦的加入到sourceinsight中，只要把framwork目錄下的源碼加進(jìn)去就可以了，后續(xù)如要用的話，再加別的目錄。

二 Audio系統(tǒng)

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

l         AudioManager：這個主要是用來管理Audio系統(tǒng)的

l         AudioTrack：這個主要是用來播放聲音的

l         AudioRecord：這個主要是用來錄音的

其中AudioManager的理解需要考慮整個系統(tǒng)上聲音的策略問題，例如來電話鈴聲，短信鈴聲等，主要是策略上的問題。一般看來，最簡單的就是播放聲音了。所以我們打算從AudioTrack開始分析。

三 AudioTrack（JAVA層）

3.1 AudioTrack API的使用例子

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

//根據(jù)采樣率，采樣精度，單雙聲道來得到frame的大小。  int bufsize = AudioTrack.getMinBufferSize(8000,//每秒8K個點(diǎn)  AudioFormat.CHANNEL_CONFIGURATION_STEREO,//雙聲道  AudioFormat.ENCODING_PCM_16BIT);//一個采樣點(diǎn)16比特-2個字節(jié)  //注意，按照數(shù)字音頻的知識，這個算出來的是一秒鐘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();//釋放底層資源。

這里需要解釋下兩個東西：

1 AudioTrack.MODE_STREAM的意思：

AudioTrack中有MODE_STATIC和MODE_STREAM兩種分類。STREAM的意思是由用戶在應(yīng)用程序通過write方式把數(shù)據(jù)一次一次得寫到audiotrack中。這個和我們在socket中發(fā)送數(shù)據(jù)一樣，應(yīng)用層從某個地方獲取數(shù)據(jù)，例如通過編解碼得到PCM數(shù)據(jù)，然后write到audiotrack。

這種方式的壞處就是總是在JAVA層和Native層交互，效率損失較大。

而STATIC的意思是一開始創(chuàng)建的時候，就把音頻數(shù)據(jù)放到一個固定的buffer，然后直接傳給audiotrack，后續(xù)就不用一次次得write了。AudioTrack會自己播放這個buffer中的數(shù)據(jù)。

這種方法對于鈴聲等內(nèi)存占用較小，延時要求較高的聲音來說很適用。

2 StreamType

這個在構(gòu)造AudioTrack的***個參數(shù)中使用。這個參數(shù)和Android中的AudioManager有關(guān)系，涉及到手機(jī)上的音頻管理策略。

Android將系統(tǒng)的聲音分為以下幾類常見的（未寫全）：

l         STREAM_ALARM：警告聲

l         STREAM_MUSCI：音樂聲，例如music等

l         STREAM_RING：鈴聲

l         STREAM_SYSTEM：系統(tǒng)聲音

l         STREAM_VOCIE_CALL：電話聲音

為什么要分這么多呢？以前在臺式機(jī)上開發(fā)的時候很少知道有這么多的聲音類型，不過仔細(xì)思考下，發(fā)現(xiàn)這樣做是有道理的。例如你在聽music的時候接到電話，這個時候music播放肯定會停止，此時你只能聽到電話，如果你調(diào)節(jié)音量的話，這個調(diào)節(jié)肯定只對電話起作用。當(dāng)電話打完了，再回到music，你肯定不用再調(diào)節(jié)音量了。

其實系統(tǒng)將這幾種聲音的數(shù)據(jù)分開管理，所以，這個參數(shù)對AudioTrack來說，它的含義就是告訴系統(tǒng)，我現(xiàn)在想使用的是哪種類型的聲音，這樣系統(tǒng)就可以對應(yīng)管理他們了。

3.2 分析之getMinBufferSize

AudioTrack的例子就幾個函數(shù)。先看看***個函數(shù)：

AudioTrack.getMinBufferSize(8000,//每秒8K個點(diǎn)  AudioFormat.CHANNEL_CONFIGURATION_STEREO,//雙聲道  AudioFormat.ENCODING_PCM_16BIT);  ----->AudioTrack.JAVA  //注意，這是個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ù)              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;          }         //調(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中實現(xiàn)。（不了解JNI的一定要學(xué)習(xí)下，否則只能在JAVA層搞，太狹隘了。）最終對應(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這個單位，什么意思？經(jīng)過多方查找，***還是在ALSA的wiki中  //找到解釋了。一個frame就是1個采樣點(diǎn)的字節(jié)數(shù)*聲道。為啥搞個frame出來？因為對于多//聲道的話，用1個采樣點(diǎn)的字節(jié)數(shù)表示不全，因為播放的時候肯定是多個聲道的數(shù)據(jù)都要播出來//才行。所以為了方便，就說1秒鐘有多少個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計算最小的buffersize     int minBuffSize = minFrameCount              * (audioFormat == javaAudioTrackFields.PCM16 ? 2 : 1)              * nbChannels;      return minBuffSize;  }

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

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

 AudioSystem::getOutputFrameCount(&afFrameCount, streamType)；     AudioSystem::getOutputSamplingRate(&afSampleRate, streamType)；        AudioSystem::isOutputChannel(channels)；      popCount是統(tǒng)計一個整數(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大小和一個Frame大小來計算幀數(shù)的。  // AudioTrackJniStorage，就是一個保存一些數(shù)據(jù)的地方，這  //里邊有一些有用的知識，下面再詳細(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對象      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ù)讀出來，所以需要一個共享內(nèi)存  //這里的共享內(nèi)存是指C++AudioTrack和AudioFlinger之間共享的內(nèi)容   //因為真正播放的工作是由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對象關(guān)聯(lián)起來了。      env->SetIntField(thiz, javaAudioTrackFields.nativeTrackInJavaObj, (int)lpTrack);      env->SetIntField(thiz, javaAudioTrackFields.jniData, (int)lpJniStorage);    }

1 AudioTrackJniStorage詳解

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

AudioTrackJniStorage的代碼很簡單。

struct audiotrack_callback_cookie {      jclass      audioTrack_class;      jobject     audioTrack_ref;   };  cookie其實就是把JAVA中的一些東西保存了下，沒什么特別的意義  class AudioTrackJniStorage {      public:          sp         mMemHeap;//這兩個Memory很重要          sp             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機(jī)制的對內(nèi)存操作的類。既然是Binder機(jī)制，那么肯定有一個服務(wù)端（Bnxxx），一個代理端Bpxxx?？纯碝emoryHeapBase定義：

class MemoryHeapBase : public virtual BnMemoryHeap

{

果然，從BnMemoryHeap派生，那就是Bn端。這樣就和Binder掛上鉤了

//Bp端調(diào)用的函數(shù)最終都會調(diào)到Bn這來

對Binder機(jī)制不了解的，可以參考：

http://blog.csdn.net/Innost/archive/2011/01/08/6124685.aspx

有好幾個構(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這個是系統(tǒng)提供的,可以不管它  //設(shè)備上打開的是/dev/ashmem設(shè)備，而Host上打開的是一個tmp文件  int fd = ashmem_create_region(name == NULL ? "MemoryHeapBase" : name, size);  mapfd(fd, size);//把剛才那個fd通過mmap方式得到一塊內(nèi)存  //不明白得去man mmap看看  mapfd完了后，mBase變量指向內(nèi)存的起始位置, mSize是分配的內(nèi)存大小，mFd是  ashmem_create_region返回的文件描述符     }

MemoryHeapBase提供了一下幾個函數(shù)，可以獲取共享內(nèi)存的大小和位置。

getBaseID()--->返回mFd，如果為負(fù)數(shù)，表明剛才創(chuàng)建共享內(nèi)存失敗了

getBase()->返回mBase，內(nèi)存位置

getSize()->返回mSize，內(nèi)存大小

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

唉，這個估計是一個在MemoryHeapBase上的方便類吧？因為我看見了offset

那么估計這個類就是一個能返回當(dāng)前Buffer中寫位置（就是offset）的方便類

這樣就不用用戶到處去計算讀寫位置了。

class MemoryBase : public BnMemory  {  public:      MemoryBase(const sp& heap, ssize_t offset, size_t size);      virtual sp getMemory(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，我們可以猜測下大概的使用方法了。

l         BnXXX端先分配BnMemoryHeapBase和BnMemoryBase，

l         然后把BnMemoryBase傳遞到BpXXX

l         BpXXX就可以使用BpMemoryBase得到BnXXX端分配的共享內(nèi)存了。

注意，既然是進(jìn)程間共享內(nèi)存，那么Bp端肯定使用memcpy之類的函數(shù)來操作內(nèi)存，這些函數(shù)是沒有同步保護(hù)的，而且Android也不可能在系統(tǒng)內(nèi)部為這種共享內(nèi)存去做增加同步保護(hù)。所以看來后續(xù)在操作這些共享內(nèi)存的時候，肯定存在一個跨進(jìn)程的同步保護(hù)機(jī)制。我們在后面講實際播放的時候會碰到。

另外，這里的SharedBuffer最終會在Bp端也就是AudioFlinger那用到。

3.4 分析之play和write

JAVA層到這一步后就是調(diào)用play和write了。JAVA層這兩個函數(shù)沒什么內(nèi)容，都是直接轉(zhuǎn)到native層干活了。

先看看play函數(shù)對應(yīng)的JNI函數(shù)

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

下面是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封裝了下，最終會調(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中  //還記得我們在native_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)然，這個共享內(nèi)存是pTrack的，是我們在set時候把AudioTrackJniStorage的  //共享設(shè)進(jìn)去的              memcpy(pTrack->sharedBuffer()->pointer(),  data + offsetInBytes, sizeInBytes);              written = sizeInBytes;          } else if (audioFormat == javaAudioTrackFields.PCM8) {             PCM8格式的要先轉(zhuǎn)換成PCM16                   }      return written;  }

到這里，似乎很簡單啊，JAVA層的AudioTrack，無非就是調(diào)用write函數(shù)，而實際由JNI層的C++ AudioTrack write數(shù)據(jù)。反正JNI這層是再看不出什么有意思的東西了。

四 AudioTrack（C++層）

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

l         new了一個AudioTrack

l         調(diào)用set函數(shù)，把AudioTrackJniStorage等信息傳進(jìn)去

l         調(diào)用了AudioTrack的start函數(shù)

l         調(diào)用AudioTrack的write函數(shù)

那么，我們就看看真正干活的的C++AudioTrack吧。

AudioTrack.cpp位于framework/base/libmedia/AudioTrack.cpp

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

JNI層調(diào)用的是最簡單的構(gòu)造函數(shù)：

AudioTrack::AudioTrack()      : mStatus(NO_INIT) //把狀態(tài)初始化成NO_INIT。Android大量使用了設(shè)計模式中的state。  {  }

接下來調(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中的一個回調(diào)函數(shù)  &(lpJniStorage->mCallbackData),//回調(diào)函數(shù)的參數(shù)              0,// 通知回調(diào)函數(shù)，表示AudioTrack需要數(shù)據(jù)，不過暫時沒用上              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& 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傳入的回調(diào)函數(shù)audioCallback       if (cbf != 0) { //看來，怎么著也要創(chuàng)建這個線程了！          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& sharedBuffer,          audio_io_handle_t output)  {  status_t status;  //啊，看來和audioFlinger掛上關(guān)系了呀。      const sp& audioFlinger = AudioSystem::get_audio_flinger();        //下面這個調(diào)用最終會在AudioFlinger中出現(xiàn)。暫時不管它。      sp track = audioFlinger->createTrack(getpid(),                                                        streamType,                                                        sampleRate,                                                        format,                                                        channelCount,                                                        frameCount,                                                        ((uint16_t)flags) << 16,                                                        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相關(guān)的了。注意我們這里的情況  //STREAM模式?jīng)]有傳入共享buffer，但是數(shù)據(jù)確實又需要buffer承載。  //反正AudioTrack是沒有創(chuàng)建buffer，那只能是剛才從AudioFlinger中得到  //的buffer了。          mCblk->buffers = (char*)mCblk + sizeof(audio_track_cblk_t);      }      return NO_ERROR;  }

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

那么我告訴大家，就在audio_track_cblk_t結(jié)構(gòu)中。它的頭文件在

framework/base/include/private/media/AudioTrackShared.h

實現(xiàn)文件就在AudioTrack.cpp中

audio_track_cblk_t::audio_track_cblk_t()  //看見下面的SHARED沒？都是表示跨進(jìn)程共享的意思。這個我就不跟進(jìn)去說了  //等以后介紹同步方面的知識時，再細(xì)說      : 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)該都有個大概的全景了。

l         AudioTrack得到AudioFlinger中的一個IAudioTrack對象，這里邊有一個很重要的數(shù)據(jù)結(jié)構(gòu)audio_track_cblk_t，它包括一塊緩沖區(qū)地址，包括一些進(jìn)程間同步的內(nèi)容，可能還有數(shù)據(jù)位置等內(nèi)容

l         AudioTrack啟動了一個線程，叫AudioTrackThread，這個線程干嘛的呢？還不知道

l         AudioTrack調(diào)用write函數(shù)，肯定是把數(shù)據(jù)寫到那塊共享緩沖了，然后IAudioTrack在另外一個進(jìn)程AudioFlinger中（其實AudioFlinger是一個服務(wù)，在mediaservice中運(yùn)行）接收數(shù)據(jù)，并最終寫到音頻設(shè)備中。

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

調(diào)用的語句是：

mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava);

AudioTrackThread從Thread中派生，這個內(nèi)容在深入淺出Binder機(jī)制講過了。

反正最終會調(diào)用AudioTrackAThread的threadLoop函數(shù)。

先看看構(gòu)造函數(shù)

AudioTrack::AudioTrackThread::AudioTrackThread(AudioTrack& receiver, bool bCanCallJava)      : Thread(bCanCallJava), mReceiver(receiver)  {  //mReceiver就是AudioTrack對象    // bCanCallJava為TRUE  }

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

void AudioTrack::start()  {    //start函數(shù)調(diào)用AudioTrackThread函數(shù)觸發(fā)產(chǎn)生一個新的線程，執(zhí)行mAudioTrackThread的  threadLoop      sp 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& 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ú)一個線程，而我們還有上層用戶在那不停  //地write呢，怎么會這樣？          mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer);           audioBuffer.size = writtenSize;           frames -= audioBuffer.frameCount;         releaseBuffer(&audioBuffer); //釋放buffer，和obtain相對應(yīng)，看來是LOCK和UNLOCK  操作了      }      while (frames);     return true;  }  難道真的有兩處在write數(shù)據(jù)？看來必須得到mCbf去看看了，傳的是EVENT_MORE_DATA標(biāo)志。  mCbf由set的時候傳入C++的AudioTrack，實際函數(shù)是：  static void audioCallback(int event, void* user, void *info) {      if (event == AudioTrack::EVENT_MORE_DATA) {           //哈哈，太好了，這個函數(shù)沒往里邊寫數(shù)據(jù)          AudioTrack::Buffer* pBuff = (AudioTrack::Buffer*)info;          pBuff->size = 0;        }

從代碼上看，本來google考慮是異步的回調(diào)方式來寫數(shù)據(jù)，可惜發(fā)現(xiàn)這種方式會比較復(fù)雜，尤其是對用戶開放的JAVA AudioTrack會很不好處理，所以嘛，偷偷摸摸得給繞過去了。

太好了，看來就只有用戶的write會真正的寫數(shù)據(jù)了，這個AudioTrackThread除了通知一下，也沒什么實際有意義的操作了。

讓我們看看write吧。

4.2 write

ssize_t AudioTrack::write(const void* buffer, size_t userSize)

{

夠簡單，就是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)，比如是否退出了之類的，難道  //沒有一個好的方法來集中處理這種事情嗎？        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中會某一次進(jìn)去lock，再某一次進(jìn)去可能就是unlock了。沒看到obtainBuffer中到處有l(wèi)ock,unlock,wait等同步操作嗎。一定是這個道理。難怪寫這么復(fù)雜。還使用了少用的goto語句。

唉，有必要這樣嗎！

五 AudioTrack總結(jié)

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

l         AudioTrack的工作原理，尤其是數(shù)據(jù)的傳遞這一塊，做了比較細(xì)致的分析，包括共享內(nèi)存，跨進(jìn)程的同步等，也能解釋不少疑惑了。

l         看起來，最重要的工作是在AudioFlinger中做的。通過AudioTrack的介紹，我們給后續(xù)深入分析AudioFlinger提供了一個切入點(diǎn)

工作原理和流程嘛，再說一次好了，JAVA層就看最前面那個例子吧，實在沒什么說的。

l         AudioTrack被new出來，然后set了一堆信息，同時會通過Binder機(jī)制調(diào)用另外一端的AudioFlinger，得到IAudioTrack對象，通過它和AudioFlinger交互。

l         調(diào)用start函數(shù)后，會啟動一個線程專門做回調(diào)處理，代碼里邊也會有那種數(shù)據(jù)拷貝的回調(diào)，但是JNI層的回調(diào)函數(shù)實際并沒有往里邊寫數(shù)據(jù)，大家只要看write就可以了

l         用戶一次次得write，那AudioTrack無非就是把數(shù)據(jù)memcpy到共享buffer中咯

感謝各位的閱讀，以上就是“AudioTrack API怎么使用”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對AudioTrack API怎么使用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！