AudioTrack学习笔记

1.AudioTrackThread

  threadLoop函数里会调用
   nsecs_t ns = mReceiver.processAudioBuffer();
 mReceiver就是一个AudioTrack,接收者?天知道为嘛这么叫。
 咱们先不说这个很重要的函数 processAudioBuffer,先来看看AudioTrackThread是在哪使用的。

2.AudioTrack类成员变量:

sp    mAudioTrackThread;

  在AudioTrack::set()函数中:

    if (cbf != NULL) {
        mAudioTrackThread = new AudioTrackThread(*this, threadCanCallJava);
        mAudioTrackThread->run("AudioTrack", ANDROID_PRIORITY_AUDIO, 0 /*stack*/);
        // thread begins in paused state, and will not reference us until start()
    }

  callback存在的话,就new它,然后run之。但是注释都说了,start()之后,这个AudioTrackThread才会真正run起来,
因为:

sp<AudioTrackThread> t = mAudioTrackThread;
    if (t != 0) {
        if (previousState == STATE_STOPPING) {
            mProxy->interrupt();
        } else {
            t->resume();
        }
    }

3.综上,也就是说AudioTrack::start的时候会有 mAudioTrackThread运行起来,不断调用 processAudioBuffer()方法。

4. processAudioBuffer()方法:

  里头循环调用了
   status_t err = obtainBuffer(&audioBuffer, requested, NULL, &nonContig);
  然后
   mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer);
  即获得buffer,然后,谁创建了AudioTrack,并且设置了回调(在AudioTrack构造函数中传入参数,构造函数会调用set进行赋值),就和谁要数据。比如说nuplayer。要数据的时候就把经过解码的pcm数据传下来。

5. obtainBuffer()

  真正干活的也不是这。干活的是:
    status = proxy->obtainBuffer(&buffer, requested, elapsed);
  实现在AudioTrackShare.cpp里头。
  (某一种情况)这个地方取到buffer的地址,然后通过
   mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer);
举个MediaPlayer中的例子啊:
/frameworks/av/media/libmediaplayerservice/MediaPlayerService.cpp中

case AudioTrack::EVENT_MORE_DATA: {
        size_t actualSize = (*me->mCallback)(
                me, buffer->raw, buffer->size, me->mCallbackCookie,
                CB_EVENT_FILL_BUFFER);
...
case MediaPlayerBase::AudioSink::CB_EVENT_FILL_BUFFER:
        {
            return me->fillAudioBuffer(buffer, size);
            break;
        }

MediaPlayer中fillAudioBuffer的源头.
  把数据取回来,由于取到的这个buffer,audioFlinger那边也能访问,所以。。。

6.还是说说set函数吧(上面说过了,在构造函数中会调用)

  这里头有一个很重要的调用:createTrack_l(),这个函数在凡平老师的书里也说到了。AudioTrack和 AudioFlinger的联系啊简直是。
  这里头又调用了以前经常见到的一个函数AudioSystem::getOutputForAttr,这个函数一路下调到apm里头,现在暂且略过不表。
  createTrack_l()函数中经过了很复杂的流程,以及获取,设置了好多参数之后(其实是没看懂,一笔带过),调用了

  sp track = audioFlinger->createTrack(streamType,
 mSampleRate,mFormat,mChannelMask,&temp,&trackFlags,mSharedBuffer,output,tid,&mSessionId,(mClientPid << 16) |mClientUid,&status);

  通过AudioFlinger的createTrack函数,返回了一个 sp,我记得这个东西对应
  的就是TrackHandle类(AudioFlinger里头一个小小的内部类)。
再之后,贯穿AudioTrack类其中的mAudioTrack变量就是从这来的。
mAudioTrack = track;
很多AudioTrack的操作,都是调用TrackHandle类。最终由playbackThread的track类完成实际工作。
这还涉及到了共享内存,共享buffer等内容。略过先。
还是先继续瞅瞅createTrack函数吧。

7.AudioFlinger::createTrack()

    track = thread->createTrack_l(client, streamType, sampleRate, format,channelMask,
         frameCount,sharedBuffer, lSessionId, flags, tid, clientUid, &lStatus);
         //妈蛋的,你瞅瞅,还要接着往下走,这个地方返回的track类型是啥呢?
        sp  track;
        // return handle to client
        trackHandle = new TrackHandle(track);
  最终AudioFlinger的createTrack函数是这么返回的:
  用PlaybackThread::createTrack_l()函数返回一个PlaybackThread::Track对象,然后用这个对象作为参数,构造一个TrackHandle对象,然后返回。
  言归正传,接下来
            if (!isTimed) {
              track = new Track(this, client, streamType, sampleRate, format,
                channelMask, frameCount, NULL, sharedBuffer,sessionId, uid, *flags,
                    TrackBase::TYPE_DEFAULT);
            } else {
              track = TimedTrack::create(this, client, streamType, sampleRate, format,
              channelMask, frameCount, sharedBuffer, sessionId, uid);
        }
          TimedTrack是什么鬼,说普通的吧:

8.AudioFlinger::PlaybackThread::Track::Track()

  PlaybackThread内部类Track又是什么鬼?
  这他妈应该是真正干活的了吧,再往下好像还有proxy.我要吐了。看到这边audioflinger,才发现,audiotrack的内容实在是太少了。

9.现在咱们又绕回去说说AudioTrackThread调用 processAudioBuffer()的那个地方

  nsecs_t ns = mReceiver.processAudioBuffer();
  这个函数返回纳秒,而函数内部return的地方,多是调用了

  framesToNanoseconds()
  static inline nsecs_t framesToNanoseconds(ssize_t frames, uint32_t sampleRate, float speed){
      return ((double)frames * 1000000000) / ((double)sampleRate * speed);
}

  函数的实现也很简单。虽然不是很懂,到应该是s转换成了ns(纳秒)。难道是每次拿到的数据所持续的播放时间?

10.现在回去说说obtainBuffer吧。上面说到,它走到了AudioTrackShare.cpp里。这个文件里头有这么几个类:

  //基类:Proxy
  //Client系列:
   - ClientProxy
   - AudioTrackClientProxy
   - StaticAudioTrackClientProxy
   - AudioRecordClientProxy
  //Server系列:
   - AudioTrackServerProxy
   - StaticAudioTrackServerProxy
   - AudioRecordServerProxy
  继承关系一目了然,从名字大概能猜出来。

  代码的文件名中Share基本能说明,这些类应该和AudioFlinger,或者说给AudioTrack提供数据的一方关系很大。当然AudioTrack肯定是有关系的了。AudioTrack对应Client,AudioFlinger对应server。这两者之间还有一个生产者,消费者的关系(别人说的)。
  话说AudioTrack类的obtainBuffer调用了
   status_t ClientProxy::obtainBuffer
  这里边有个函数
   StaticAudioTrackServerProxy::pollPosition()
  也同样被调用到,然后呢?没看懂呢,先不继续了。。。
  // Proxy used by AudioFlinger server
   class ServerProxy : public Proxy {

  看着没?头文件都说了,AudioFlinger用的!
  费了半天劲,在AudioFlinger找到了一个变量mServerProxy,sourceinsight无法跳转,grep搜索发现,定义在了TrackBase.h里了
  void AudioFlinger::ThreadBase::TrackBase,子类的子类呀!

让我们看看真正的证据吧:
AudioFlinger::PlaybackThread::Track::Track()构造函数里调用了

    if (sharedBuffer == 0) {
    mAudioTrackServerProxy = new AudioTrackServerProxy(mCblk, mBuffer, frameCount,
                mFrameSize, !isExternalTrack(), sampleRate);
    } else {
        mAudioTrackServerProxy = new StaticAudioTrackServerProxy(mCblk, mBuffer, frameCount,
                mFrameSize);
    }
  没错,和我们想的一样,就是用的ServerProxy.
  上面的参数,mCblk,mBuffer,等参数在sourceInsight上是黑色的,没法跳转,根据经验,定义在基类里,即TrackBase.h文件里。比如说mBuffers(Track类的)从 StaticAudioTrackServerProxy()构造函数一路传了上去,最终,传到了前面说的Proxy类的mBuffers。
  而这个mBuffers基本上就是obtainBuffer取数据的源泉啊。
  mBuffers在AudioFlinger构造serverProxy的时候一步步传进来。然后在AudioTrack调用ClientProxy的obtainBuffer(write方式或者是processAudioBuffer方式都会调用)的时候通过参数返回。AudioTrack拿到共有缓冲区的地址之后,就可以往里放数据了也就是说,AudioFlinger和AudioTrack在通过这个mBuffers传递数据呀!这个地方还有一点需要说一下。就是
  这个地方为什么有两个类,有一个前面多了一个static.使用场景不一样!static的那个是用在ShareBuffer给定(AudioTrack()那个参数不为空)的情况下,一直去里头取数据即可。所以说是static的。

11.AudioTrack::write函数:

ssize_t AudioTrack::write(const void* buffer, size_t userSize, bool blocking)
上层应用调用这个函数,然后不断往下写经过解码的数据。这里边的buffer就是数据了。
 while (userSize >= mFrameSize) {
        //。。。
        status_t err = obtainBuffer(&audioBuffer,
                blocking ? &ClientProxy::kForever : &ClientProxy::kNonBlocking);
      // 。。。
        memcpy(audioBuffer.i8, buffer, toWrite);
    //。。。
        releaseBuffer(&audioBuffer);
    }

  其中的这个while循环不断做的事情就是通过obtainBuffer获得和AudioFlinger共享的buffer。然后往里头memcpy上层write的数据。最后releaseBuffer。

12.回调方式

  如果构造AudioTrack的时候,选用的构造函数是带callback_t cbf的那个,并且传入了存在的一个值,在AudioTrack的构造函数里就会调用set函数,把这个cbf传递给AudioTrack的mCbf这个成员变量。只要
  ``mCbf(EVENT_MORE_DATA, mUserData, &audioBuffer);``

类似这样的调用方式,就会回调到在构造函数里传入的那个地址。比如SoundPool就把process函数作为了回调函数传给了AudioTrack。
  从字面意思看就是,我需要数据,快给我数据!不过soundPool一般是不会回调 EVENT_MORE_DATA的。因为一般数据量都很少,一次就可以搞定。soundPool一般都是回调EVENT_BUFFER_END。通知上层,数据没了。

你可能感兴趣的:(安卓,Audio)