從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, ¬ificationFrames, 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,
¬ificationFrames,
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, ¬ificationFrames, 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的原理一樣；
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/215565.html
標籤：其他