Android深入浅出之Audio第一部分AudioTrack分析(2)
2013-11-14 16:18 佚名 博客园 字号:T | T
本文的目的是通过从Audio系统来分析Android的代码,包括Android自定义的那套机制和一些常见类的使用,比如Thread,MemoryBase等。
AD:51CTO 网+ 第十二期沙龙:大话数据之美_如何用数据驱动用户体验
下面是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数据到音频设备中去。我们拭目以待。
【编辑推荐】
- MTP in Android详解
- Android Audio系统变化说明
- Android rom移植知识
- Android深入浅出之Audio第三部分Audio Policy
- Android深入浅出之AudioFlinger分析
【责任编辑:张叶青 TEL:(010)68476606】