通過AudioRecord程序詳解Android Audio系統

從Android API AudioRecorder構造程序開始：

建構式呼叫了native_setup native函式，在android_media_AudioRecorder.cpp jni檔案中，基本的API介面都對應了native介面，

    private native final int native_setup(Object audiorecord_this,
            Object /*AudioAttributes*/ attributes,
            int[] sampleRate, int channelMask, int channelIndexMask, int audioFormat,
            int buffSizeInBytes, int[] sessionId, String opPackageName,
            long nativeRecordInJavaObj);

    private native final int native_start(int syncEvent, int sessionId);

    private native final int native_read_in_byte_array(byte[] audioData,
            int offsetInBytes, int sizeInBytes, boolean isBlocking);

android_media_AudioRecord_setup

lpRecorder = new AudioRecord(String16(opPackageNameStr.c_str()));

lpRecorder->set，呼叫了openRecord_l，并且訪問AF openRecord拿到IAudioRecord，

sp<IAudioRecord> AudioFlinger::openRecord

recordingAllowed(opPackageName, tid, clientUid) 根據包名等檢查權限；

RecordThread *thread = checkRecordThread_l(input) 根據audio_io_handle從mRecordThreads中拿到recordthread

client = registerPid(pid) 創建了一個AudioFlinger::Client物件，clinet主要包含一塊1024*1024的記憶體，將client加入mClients.add(pid, client);

AudioFlinger::RecordThread::createRecordTrack_l 使用recordthread創建track

recordHandle = new RecordHandle(recordTrack); 利用recordtrack生成recordHandle

return recordHandle ; RecordHandle繼承自BnAudioRecord，回傳型別為sp<IAudioRecord>的bindler物件，回傳給AudioRecorder中使用

IAudioFlinger中是AudioFlinger的Bindler呼叫介面，client層也就是AudioRecorder.cpp運行的層，通過AudioSystem提供的介面拿到AF的bindler物件，實際程序是通過ServiceManager查找Bindler服務得到bindler物件，同時在AudioSystem保存了靜態值，

sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger()

AF的bindler物件執行openRcorder的操作,是一個標準的Bindler呼叫，洗掉了很多代碼僅保留Bindler呼叫，data和reply分別是呼叫的序列化和回傳的序列化，執行remote()->transact進行Bindler呼叫，回傳了IAudioRecord Bindler物件，

注意Bindler呼叫的code為OPEN_RECORD，可根據code在服務端區分呼叫；

    virtual sp<IAudioRecord> openRecord(
                                audio_io_handle_t input,
                                uint32_t sampleRate,
                                audio_format_t format,...)
    {
        Parcel data, reply;
        sp<IAudioRecord> record;

        data.writeInt32((int32_t) input);      
        data.writeInt32(format);
      
        status_t lStatus = remote()->transact(OPEN_RECORD, data, &reply);
        if (lStatus != NO_ERROR) {
            ALOGE("openRecord error: %s", strerror(-lStatus));
        } else {
            
            size_t lNotificationFrames = (size_t) reply.readInt64();
  
            lStatus = reply.readInt32();
            record = interface_cast<IAudioRecord>(reply.readStrongBinder());
            cblk = interface_cast<IMemory>(reply.readStrongBinder());

            buffers = interface_cast<IMemory>(reply.readStrongBinder())
}

在Android系統中代碼設計時，通常Bindler Server接收的實作和Client呼叫的實作在一個檔案中，這里在IAudioFlinger中，BnAudioFlinger表示server端的介面，onTransact收到Bindler呼叫；

下面代碼僅保留Bindler呼叫部分，這里因為BnAudioFlinger是AudioFlinger的父類，呼叫openRecord是AudioFlinger中成員，這樣就一個呼叫執行到了音頻服務AudioFlinger中，并且回傳也序列化處理了，包含Bindler物件，

status_t BnAudioFlinger::onTransact(
    uint32_t code, const Parcel& data, Parcel* reply, uint32_t flags)
{
        case OPEN_RECORD: {
            CHECK_INTERFACE(IAudioFlinger, data, reply);
            audio_io_handle_t input = (audio_io_handle_t) data.readInt32();
            
            sp<IAudioRecord> record = openRecord(input,
                    sampleRate, format, channelMask, opPackageName, &frameCount, &flags,
                    pid, tid, clientUid, &sessionId, &notificationFrames, cblk, buffers,
                    &status);
        
            reply->writeInt32(status);
            reply->writeStrongBinder(IInterface::asBinder(record));
            reply->writeStrongBinder(IInterface::asBinder(cblk));
            reply->writeStrongBinder(IInterface::asBinder(buffers));

AudioFlinger::RecordThread::createRecordTrack_l 使用recordthread創建track

track = new RecordTrack(this, client, sampleRate,

format, channelMask, frameCount, NULL, sessionId, uid,

*flags, TrackBase::TYPE_DEFAULT); 里面包含了RecordBufferConverter AudioRecordServerProxy ResamplerBufferProvider

mTracks.add(track); mTracks是一個vector

return一個 sp<RecordTrack>物件

AudioRecorder在Client端拿到了可以訪問AF的Bindler物件IAudioRecord，賦值給mAudioRecord，這里還涉及一個共享記憶體的使用，非常重要；

到此Recorder的初始化就完成了，

API

startRecording 對應的程序如下

native_start 呼叫native的start

android_media_AudioRecord_start jni函式start

sp<AudioRecord> lpRecorder = getAudioRecord(env, thiz); 拿到AudioRecorder物件，之前將這個物件創建好后保存在了java層；

lpRecorder->start((AudioSystem::sync_event_t)event, (audio_session_t) triggerSession) 呼叫了AudioRecorder的start， triggerSession在java API傳過來，默認為0

status_t AudioRecord::start

status = mAudioRecord->start(event, triggerSession); 呼叫前面從AF拿到的IAudioRecorder Bindler物件mAudioRecord，這個里面只有兩個介面可呼叫， transact的code代表Bindler呼叫的type；

enum {
    UNUSED_WAS_GET_CBLK = IBinder::FIRST_CALL_TRANSACTION,
    START,
    STOP
};

status_t BnAudioRecord::onTransact中執行server端的start，RecordHandle繼承自BnAudioRecord，因此在BnAudioRecorder中呼叫start是 AudioFlinger::RecordHandle::start成員函式；

在audioflinger/Tracks.cpp中實作 AudioFlinger::RecordHandle

mRecordTrack->start((AudioSystem::sync_event_t)event, triggerSession); 實呼叫際執行track的方法；RecordHandle應該是對RecordTrack的Bindler封裝；

status_t AudioFlinger::RecordThread::RecordTrack::start RecordTrack和RecordThread關聯很密切；

track的定義在RecordTrack.h中，實作在Tracks.cpp, 都在audioflinger目錄下；

recordThread->start(this, event, triggerSession); 對RecordThread呼叫start, 將當前track物件this傳入了RecordThread, event使用SYNC_EVENT_NONE（java傳入，通過AudioSystem映射）

AudioFlinger::RecordThread::start

mActiveTracks.add(recordTrack); 加入active佇列

mActiveTracksGen++; active計數增加

recordTrack->mResamplerBufferProvider->reset(); 重置一些...

// clear any converter state as new data will be discontinuous

recordTrack->mRecordBufferConverter->reset();

recordTrack->mState = TrackBase::STARTING_2; starting狀態

// signal thread to start

mWaitWorkCV.broadcast(); 通知執行緒start

下面應該看如何使用這個mActiveTracks和里面的track的；

AudioFlinger::RecordThread::threadLoop() AudioFlinger和AudioPolicyService啟動階段創建的Recorder執行緒執行體；

for (;;) { thread loop

size_t size = mActiveTracks.size();

mWaitWorkCV.wait(mLock); active的track為0時，利用CV wait，當recorder start時將創建的track加入佇列，CV信號通知這里開始作業；

for (size_t i = 0; i < size; ) { 遍歷每個recordtrack

activeTrack = mActiveTracks[i];

switch判斷track狀態， 在mActiveTracks中的也有可能處在未active狀態： PAUSING STARTING_1 STARTING_2 ACTIVE IDLE

activeTracks.add(activeTrack); 將active狀態的加入區域佇列；

在record的threadloop中還有一個核心的操作，從hw中讀取音頻資料到快取；

threadloop從hw中讀取音頻資料到快取；mRsmpInBuffer是快取buffer，mRsmpInRear 是buffer寫資料偏移，

        // Read from HAL to keep up with fastest client if multiple active tracks, not slowest one.
        // Only the client(s) that are too slow will overrun. But if even the fastest client is too
        // slow, then this RecordThread will overrun by not calling HAL read often enough.
        // If destination is non-contiguous, first read past the nominal end of buffer, then
        // copy to the right place.  Permitted because mRsmpInBuffer was over-allocated.

        int32_t rear = mRsmpInRear & (mRsmpInFramesP2 - 1);
        ssize_t framesRead;

        // If an NBAIO source is present, use it to read the normal capture's data
        if (mPipeSource != 0) {
            size_t framesToRead = mBufferSize / mFrameSize;
            framesRead = mPipeSource->read((uint8_t*)mRsmpInBuffer + rear * mFrameSize,
                    framesToRead);
            if (framesRead == 0) {
                // since pipe is non-blocking, simulate blocking input
                sleepUs = (framesToRead * 1000000LL) / mSampleRate;
            }
        // otherwise use the HAL / AudioStreamIn directly
        } else {
            ATRACE_BEGIN("read");
            ssize_t bytesRead = mInput->stream->read(mInput->stream,
                    (uint8_t*)mRsmpInBuffer + rear * mFrameSize, mBufferSize);
            ATRACE_END();
            if (bytesRead < 0) {
                framesRead = bytesRead;
            } else {
                framesRead = bytesRead / mFrameSize;
            }
        }

record threadloop中對真正active的track區域佇列遍歷

size = activeTracks.size();

// loop over each active track

for (size_t i = 0; i < size; i++) {

activeTrack = activeTracks[i];

針對每個track回圈更新buffer

track更新buffer程序，

activeTrack->mResamplerBufferProvider->sync(&framesIn, &hasOverrun);

mResamplerBufferProvider這個是track的一個成員物件，track創建時創建了它，并且將track的this參考傳入，因此mResamplerBufferProvider擁有了track的參考，track擁有RecordThread的應用，在sync中能拿到recordThread的參考；

thread中保存有音頻buffer的狀態，將這些狀態更新到mResamplerBufferProvider

const int32_t rear = recordThread->mRsmpInRear;

const int32_t front = mRsmpInFront;

const ssize_t filled = rear - front;

---

// process frames from the RecordThread buffer provider to the RecordTrack buffer

framesOut = activeTrack->mRecordBufferConverter->convert(activeTrack->mSink.raw, activeTrack->mResamplerBufferProvider, framesOut);

---

// update frame information and push timestamp out

activeTrack->updateTrackFrameInfo(activeTrack->mServerProxy->framesReleased(),

mTimestamp.mPosition[ExtendedTimestamp::LOCATION_SERVER],

mSampleRate, mTimestamp);

ResamplerBufferProvider和RecordBufferConverter的實作都在AudioFlinger.cpp中；這兩類的物件都屬于一個track，輔助track實作音頻capture的程序；

RecorderBufferConverter在構建時，創建了一個mResampler = AudioResampler::create 用于重采樣；

RecordBufferConverter::conver程序就是用mResampler重采樣，并將輸入拷貝到activeTrack->mSink.raw

API read對應的程序如下

native_read_in_byte_array jni實作

lpRecorder->read 呼叫AudioRecorder native read

ssize_t AudioRecord::read(void* buffer, size_t userSize, bool blocking)

status_t err = obtainBuffer(&audioBuffer,

blocking ? &ClientProxy::kForever : &ClientProxy::kNonBlocking); 回圈呼叫獲取音頻數到audioBuffer

obtainBuffer執行程序用到了在openRecord階段創建的AudioRecordClientProxy，

mProxy = new AudioRecordClientProxy(cblk, buffers, mFrameCount, mFrameSize);

buffers = bufferMem->pointer(); buffers共享記憶體中緩沖區的起始地址，

bufferMem是AF openRecord程序生成的共享記憶體；

cblk指向iMem，是緩沖區控制塊；

sp<IMemory> iMem; // for cblk

sp<IMemory> bufferMem;

sp<IAudioRecord> record = audioFlinger->openRecord(input,

mSampleRate,

mFormat,

mChannelMask,

opPackageName,

&temp,

&flags,

mClientPid,

tid,

mClientUid,

&mSessionId,

&notificationFrames,

iMem,

bufferMem,

&status);

class AudioRecordClientProxy : public ClientProxy 繼承自ClientProxy, 在AudioTrackShared.h中定義，還有AudioTrack也有一樣的實作；主要是為client和server之間跨行程記憶體共享資料傳輸；

obtainBuffer是父類ClientProxy的成員，obtainBuffer是計算共享記憶體讀取的位置，將指標指向該點；

buffer->mFrameCount = part1;

buffer->mRaw = part1 > 0 ?

&((char *) mBuffers)[(mIsOut ? rear : front) * mFrameSize] : NULL; mBuffers是創建Porxy時傳入的共享記憶體物件；

obtainBuffer是一個阻塞式呼叫，通過for(;;)回圈獲取AF服務中產生的音頻資料，在打斷或拿到資料后回傳；

通過上面提到的控制塊中資料判斷是否有可用資料，write to rear, read from front

        int32_t front;
        int32_t rear;
        if (mIsOut) {
            // The barrier following the read of mFront is probably redundant.
            // We're about to perform a conditional branch based on 'filled',
            // which will force the processor to observe the read of mFront
            // prior to allowing data writes starting at mRaw.
            // However, the processor may support speculative execution,
            // and be unable to undo speculative writes into shared memory.
            // The barrier will prevent such speculative execution.
            front = android_atomic_acquire_load(&cblk->u.mStreaming.mFront);
            rear = cblk->u.mStreaming.mRear;
        } else {
            // On the other hand, this barrier is required.
            rear = android_atomic_acquire_load(&cblk->u.mStreaming.mRear);
            front = cblk->u.mStreaming.mFront;
        }
        // write to rear, read from front
        ssize_t filled = rear - front;

AudioRecord::read呼叫obtainBuffer獲得共享記憶體的讀取地址后，拷貝資料到用戶buffer，完成一次資料read，obtainBuffer程序只獲取一幀資料，read可回圈的呼叫obtainBuffer獲取多幀資料到用戶buffer；

size_t bytesRead = audioBuffer.size;

memcpy(buffer, audioBuffer.i8, bytesRead);

AudioRecord在client端呼叫AudioFlinger server端時傳入IMemory型別的兩個共享記憶體物件；

iMem應用控制，bufferMem是共享記憶體buffer；

    sp<IMemory> iMem;           // for cblk
    sp<IMemory> bufferMem;
    sp<IAudioRecord> record = audioFlinger->openRecord(input,
                                                       mSampleRate,
                                                       mFormat,
                                                       mChannelMask,
                                                       opPackageName,
                                                       &temp,
                                                       &flags,
                                                       mClientPid,
                                                       tid,
                                                       mClientUid,
                                                       &mSessionId,
                                                       &notificationFrames,
                                                       iMem,
                                                       bufferMem,
                                                       &status);

sp<IAudioRecord> AudioFlinger::openRecord 共享記憶體實作；利用recorderTrack的方法獲得；一個client呼叫一次openRecord對應一個track，因此每個client和server之間唯一一個共享記憶體用于音頻傳遞；

cblk = recordTrack->getCblk();

buffers = recordTrack->getBuffers();

recordTrack包裝成Bindler物件IAudioRecord回傳給client，實際每個client呼叫server都是通過對應的IAudioRecord；

recordHandle = new RecordHandle(recordTrack);

return recordHandle; 回傳值是sp<IAudioRecord>， RecordHandle繼承自BnAudioRecord;

AudioFlinger openRecord程序創建了RecordTrack，這里涉及兩個佇列：

mTracks和mActiveTracks

mTracks：剛創建的加入這個佇列；

mActiveTracks：start后的加入這個佇列；

RecordTrack繼承自TrackBase，并且參考一個AudioFlinger::Client物件，clinet主要包含一塊1024*1024的記憶體；client是在RecordTrack構建之前創建，構建時傳給RecordTrack，代表了一個client在server中的實體；

TrackBase的構建程序創建了共享記憶體；

mCblkMemory和mBufferMemory對應控制塊和共享記憶體，在下面呼叫中回傳：

cblk = recordTrack->getCblk();

buffers = recordTrack->getBuffers();

上面程序是讀共享記憶體的程序，還有些共享記憶體的程序，在RecodThread的threadloop中；

status_t status = activeTrack->getNextBuffer(&activeTrack->mSink);

status_t status = mServerProxy->obtainBuffer(&buf) 實際執行ServerProxy的obtainBuffer， 和ClientProxy的原理一樣；