自由手記

引言

Android Framework的音訊子系統中，每一個音訊流對應著一個AudioTrack類的一個實例，每個AudioTrack會在創建時註冊到 AudioFlinger中，由AudioFlinger把所有的AudioTrack進行混合（Mixer），然後輸送到AudioHardware中 進行播放，目前Android的Froyo版本設定了同時最多可以創建32個音訊流，也就是說，Mixer最多會同時處理32個AudioTrack的數 據流。

 

如何使用AudioTrack

AudioTrack的主要代碼位於 frameworks\base\media\libmedia\audiotrack.cpp中。現在先通過一個例子來瞭解一下如何使用 AudioTrack，ToneGenerator是android中產生電話撥號聲和其他音調波形的一個實現，我們就以它為例子：

 

ToneGenerator的初始化函數：

 

1.bool ToneGenerator::initAudioTrack() {

2. // Open audio track in mono, PCM 16bit, default sampling rate, default buffer size

3. mpAudioTrack = new AudioTrack();

4. mpAudioTrack->set(mStreamType,

5. 0,

6. AudioSystem::PCM_16_BIT,

7. AudioSystem::CHANNEL_OUT_MONO,

8. 0,

9. 0,

10. audioCallback,

11. this,

12. 0,

13. 0,

14. mThreadCanCallJava);

15. if (mpAudioTrack->initCheck() != NO_ERROR) {

16. LOGE("AudioTrack->initCheck failed");

17. goto initAudioTrack_exit;

18. }

19. mpAudioTrack->setVolume(mVolume, mVolume);

20. mState = TONE_INIT;

21. ......

22. }

 

 

可見，創建步驟很簡單，先new一個AudioTrack的實例，然後調用set成員函數完成參數的設置並註冊到AudioFlinger中，然後 可以調用其他諸如設置音量等函數進一步設置音訊參數。其中，一個重要的參數是audioCallback，audioCallback是一個回呼函數，負 責回應AudioTrack的通知，例如填充資料、迴圈播放、播放位置觸發等等。回呼函數的寫法通常像這樣：

 

1.void ToneGenerator::audioCallback(int event, void* user, void *info) {

2. if (event != AudioTrack::EVENT_MORE_DATA) return;

3. AudioTrack::Buffer *buffer = static_cast<AudioTrack::Buffer *>(info);

4. ToneGenerator *lpToneGen = static_cast<ToneGenerator *>(user);

5. short *lpOut = buffer->i16;

6. unsigned int lNumSmp = buffer->size/sizeof(short);

7. const ToneDescriptor *lpToneDesc = lpToneGen->mpToneDesc;

8. if (buffer->size == 0) return;

9.

10. // Clear output buffer: WaveGenerator accumulates into lpOut buffer

11. memset(lpOut, 0, buffer->size);

12. ......

13. // 以下是產生音調資料的代碼，略....

14.}

 

 

該函數首先判斷事件的類型是否是EVENT_MORE_DATA，如果是，則後續的代碼會填充相應的音訊資料後返回，當然你可以處理其他事件，以下是可用的事件類型：

 

1.enum event_type {

2. EVENT_MORE_DATA = 0, // Request to write more data to PCM buffer.

3. EVENT_UNDERRUN = 1, // PCM buffer underrun occured.

4. EVENT_LOOP_END = 2, // Sample loop end was reached; playback restarted from loop start if loop count was not 0.

5. EVENT_MARKER = 3, // Playback head is at the specified marker position (See setMarkerPosition()).

6. EVENT_NEW_POS = 4, // Playback head is at a new position (See setPositionUpdatePeriod()).

7. EVENT_BUFFER_END = 5 // Playback head is at the end of the buffer.

8. };

 

 

開始播放：

 

1.mpAudioTrack->start();

 

 

停止播放：

 

 

1.mpAudioTrack->stop();

 

 

只要簡單地調用成員函數start()和stop()即可。

 

AudioTrack和AudioFlinger的通信機制

通常，AudioTrack和AudioFlinger並不在同一個進程中，它們通過android中的binder機制建立聯繫。

 

AudioFlinger是android中的一個service，在android啟動時就已經被載入。下麵這張圖展示了他們兩個的關係：

  

 

 

 

 

圖一 AudioTrack和AudioFlinger的關係

我們可以這樣理解這張圖的含義：

 

•audio_track_cblk_t實現了一個環形FIFO；

•AudioTrack是FIFO的資料生產者；

•AudioFlinger是FIFO的資料消費者。

建立聯繫的過程

下麵的序列圖展示了AudioTrack和AudioFlinger建立聯繫的過程：

  

 

 

 

 

圖二 AudioTrack和AudioFlinger建立聯繫

解釋一下過程：

 

•Framework或者Java層通過JNI，new AudioTrack();

•根據StreamType等參數，通過一系列的調用getOutput();

•如有必要，AudioFlinger根據StreamType打開不同硬體設備;

•AudioFlinger為該輸出設備創建混音執行緒： MixerThread()，並把該執行緒的id作為getOutput()的返回值返回給AudioTrack;

•AudioTrack通過binder機制調用AudioFlinger的createTrack();

•AudioFlinger註冊該AudioTrack到MixerThread中；

•AudioFlinger創建一個用於控制的TrackHandle，並以IAudioTrack這一介面作為createTrack()的返回值；

•AudioTrack通過IAudioTrack介面，得到在AudioFlinger中創建的FIFO(audio_track_cblk_t);

•AudioTrack創建自己的監控執行緒：AudioTrackThread；

自此，AudioTrack建立了和AudioFlinger的全部聯繫工作，接下來，AudioTrack可以：

 

•通過IAudioTrack介面控制該音軌的狀態，例如start,stop,pause等等；

•通過對FIFO的寫入，實現連續的音訊播放；

•監控執行緒監控事件的發生，並通過audioCallback回呼函數與使用者程式進行交互；

FIFO的管理

audio_track_cblk_t

audio_track_cblk_t這個結構是FIFO實現的關鍵，該結構是在createTrack的時候，由AudioFlinger申請相 應的記憶體，然後通過IMemory介面返回AudioTrack的，這樣AudioTrack和AudioFlinger管理著同一個 audio_track_cblk_t，通過它實現了環形FIFO，AudioTrack向FIFO中寫入音訊資料，AudioFlinger從FIFO 中讀取音訊資料，經Mixer後送給AudioHardware進行播放。

 

audio_track_cblk_t的主要資料成員：

 

user -- AudioTrack當前的寫位置的偏移

userBase -- AudioTrack寫偏移的基準位置，結合user的值方可確定真實的FIFO位址指標

server -- AudioFlinger當前的讀位置的偏移

serverBase -- AudioFlinger讀偏移的基準位置，結合server的值方可確定真實的FIFO位址指標

 

frameCount -- FIFO的大小，以音訊資料的幀為單位，16bit的音訊每幀的大小是2位元組

 

buffers -- 指向FIFO的起始位址

 

out -- 音訊流的方向，對於AudioTrack，out=1，對於AudioRecord，out=0

 

audio_track_cblk_t的主要成員函數：

 

framesAvailable_l()和framesAvailable()用於獲取FIFO中可寫的空閒空間的大小，只是加鎖和不加鎖的區別。

 

 

 

 

1.uint32_t audio_track_cblk_t::framesAvailable_l()

2.{

3. uint32_t u = this->user;

4. u += frameCount;

5. ......

6. if (u >= userBase + this->frameCount) {

7. userBase += this->frameCount;

8. }

9. this->user = u;

10. ......

11. return u;

12.}

 

 

1.bool audio_track_cblk_t::stepServer(uint32_t frameCount)

2.{

3. // the code below simulates lock-with-timeout

4. // we MUST do this to protect the AudioFlinger server

5. // as this lock is shared with the client.

6. status_t err;

7. err = lock.tryLock();

8. if (err == -EBUSY) { // just wait a bit

9. usleep(1000);

10. err = lock.tryLock();

11. }

12. if (err != NO_ERROR) {

13. // probably, the client just died.

14. return false;

15. }

16. uint32_t s = this->server;

17. s += frameCount;

18. // 省略部分代碼

19. // ......

20. if (s >= serverBase + this->frameCount) {

21. serverBase += this->frameCount;

22. }

23. this->server = s;

24. cv.signal();

25. lock.unlock();

26. return true;

27.}

 

 

1.void* audio_track_cblk_t::buffer(uint32_t offset) const

2.{

3. return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;

4.}

stepUser()和stepServer的作用是調整當前偏移的位置，可以看到，他們僅僅是把成員變數user或server的值加上需要移動 的數量，user和server的值並不考慮FIFO的邊界問題，隨著資料的不停寫入和讀出，user和server的值不斷增加，只要處理得 當，user總是出現在server的後面，因此frameAvalible()和frameReady()中的演算法才會一直成立。根據這種算 法，user和server的值都可能大於FIFO的大小：framCount，那麼，如何確定真正的寫指標的位置呢？這裡需要用到userBase這一 成員變數，在stepUser()中，每當user的值越過(userBase+frameCount)，userBase就會增加 frameCount，這樣，映射到FIFO中的偏移總是可以通過(user-userBase)獲得。因此，獲得當前FIFO的寫位址指標可以通過成員 函數buffer()返回：

 

p = mClbk->buffer(mclbk->user);

 

在AudioTrack中，封裝了兩個函數：obtainBuffer()和releaseBuffer()操作 FIFO，obtainBuffer()獲得當前可寫的數量和寫指標的位置，releaseBuffer()則在寫入資料後被調用，它其實就是簡單地調用 stepUser()來調整偏移的位置。

 

IMemory介面

在createTrack的過程中，AudioFlinger會根據傳入的frameCount參數，申請一塊記憶體，AudioTrack可以通過 IAudioTrack介面的getCblk()函數獲得指向該區塊的IMemory介面，然後AudioTrack通過該IMemory介面的 pointer()函數獲得指向該區塊的指標，這塊記憶體的開始部分就是audio_track_cblk_t結構，緊接著是大小為frameSize的 FIFO記憶體。

 

IMemory->pointer() ---->|_______________________________________________________

 

|__audio_track_cblk_t__|_______buffer of FIFO(size==frameCount)____|

 

看看AudioTrack的createTrack()的代碼就明白了：

 

1.sp<IAudioTrack> track = audioFlinger->createTrack(getpid(),

2. streamType,

3. sampleRate,

4. format,

5. channelCount,

6. frameCount,

7. ((uint16_t)flags) << 16,

8. sharedBuffer,

9. output,

10. &status);

11. // 得到IMemory介面

12. sp<IMemory> cblk = track->getCblk();

13. mAudioTrack.clear();

14. mAudioTrack = track;

15. mCblkMemory.clear();

16. mCblkMemory = cblk;

17. // 得到audio_track_cblk_t結構

18. mCblk = static_cast<audio_track_cblk_t*>(cblk->pointer());

19. // 該FIFO用於輸出

20. mCblk->out = 1;

21. // Update buffer size in case it has been limited by AudioFlinger during track creation

22. mFrameCount = mCblk->frameCount;

23. if (sharedBuffer == 0) {

24. // 給FIFO的起始位址賦值

25. mCblk->buffers = (char*)mCblk + sizeof(audio_track_cblk_t);

26. } else {

27. ..........

28. }