锐客网

  1. 首页 > 睿知 > it技术 > >

Android音频系统之AudioFlinger

IT知识android

实践是知识的母亲，知识是生活的明灯。这篇文章主要讲述Android音频系统之AudioFlinger相关的知识，希望能为你提供帮助。
http://blog.csdn.net/xuesen_lin/article/details/8805068
1.1 AudioFlinger在上面的框架图中，我们可以看到AudioFlinger(下面简称AF)是整个音频系统的核心与难点。作为Android系统中的音频中枢，它同时也是一个系统服务，启到承上(为上层提供访问接口)启下(通过HAL来管理音频设备)的作用。只有理解了AudioFlinger，才能以此为基础更好地深入到其它模块，因而我们把它放在前面进行分析。
 
1.1.1 AudioFlinger服务的启动和运行
我们知道，android中的系统服务分为两类，分别是Java层和Native层的System Services。其中AudioFlinger和SurfaceFlinger一样，都属于后者。java层服务通常在SystemServer.java中启动，比如后面会看到的Audioservice就是这种情况。而Native层服务则通常是各服务方按照自己的特定部署来决定何时启动、如何启动。例如AudioFlinger就是利用一个Linux程序来间接创建的，如下所示：
/*frameworks/av/media/mediaserver/Main_mediaserver.cpp*/
int main(int argc, char** argv)
{
      sp< ProcessState> proc(ProcessState::self());
      sp< IServiceManager> sm = defaultServiceManager();
      ALOGI("ServiceManager: %p", sm.get());
      AudioFlinger::instantiate();
      MediaPlayerService::instantiate();
      CameraService::instantiate();
      AudioPolicyService::instantiate();
      ProcessState::self()-> startThreadPool();
      IPCThreadState::self()-> joinThreadPool();
}
这个mediaserver的目录下只有一个文件，它的任务很简单，就是把所有媒体相关的native层服务(包括AudioFlinger,MediaPlayerService,CameraService和AudioPolicyService)启动起来，可以参考其Android.mk:
LOCAL_SRC_FILES:= \
                              main_mediaserver.cpp
 
LOCAL_SHARED_LIBRARIES := \
                              libaudioflinger\
                              libcameraservice\
                              libmediaplayerservice\
                              libutils \
                              libbinder
…
LOCAL_MODULE:= mediaserver
根据前面的分析，AudioFlinger的源码实现是放在libaudioflinger库中的，因而在编译mediaserver时要引用这个库，其它服务也是一样的做法。编译生成的mediaserver将被烧录到设备的/system/bin/mediaserver路径中，然后由系统启动时的init进程启动，其在Init.rc中的配置是：
service media /system/bin/mediaserver
      class main
      user media
      group audio camera inetnet_bt net_bt_admin net_bw_acct drmrpc
      ioprio rt 4
值得一提的是，这个AudioFlinger::instantiate()并不是AudioFlinger内部的静态类，而是BinderService类的一个实现。包括AudioFlinger、AudioPolicyService等在内的几个服务都继承自这个统一的Binder服务类，比如：
class AudioFlinger :
      public  BinderService< AudioFlinger> ,
      public BnAudioFlinger…
从名称上看，BinderService应该是实现了binder跨进程通信相关的功能，它是一个模板类，其中的函数instantiate将把模板指定的服务创建出来，并添加到ServiceManager中：
    /*frameworks/native/include/binder/BinderService.h*/
      template< typename SERVICE> …
      static status_t   publish(bool allowIsolated = false) {
              sp< IServiceManager> sm(defaultServiceManager());
              returnsm-> addService(String16(SERVICE::getServiceName()), new SERVICE(),allowIsolated);
      }
      static void instantiate(){ publish(); } //调用publish
回头看下AudioFlinger的构造函数，发现它只是简单地为内部一些变量做了初始化，除此之外就没有任何代码了：
【Android音频系统之AudioFlinger】AudioFlinger::AudioFlinger()
:BnAudioFlinger(),mPrimaryHardwareDev(NULL),
  mHardwareStatus(AUDIO_HW_IDLE), // see alsoonFirstRef()
          mMasterVolume(1.0f),mMasterVolumeSupportLvl(MVS_NONE), mMasterMute(false),
          mNextUniqueId(1),mMode(AUDIO_MODE_INVALID), mBtNrecIsOff(false)
{
}
大家可能会觉得疑惑，那么AudioFlinger在什么情况下会开始执行实际的工作呢？没错，是在onFirstRef()中。BnAudioFlinger是由RefBase层层继承而来的，并且IServiceManager::addService的第二个参数实际上是一个强指针引用(constsp< IBinder> & ),因而AudioFlinger具备了强指针被第一次引用时调用onFirstRef的程序逻辑。如果大家不是很清楚这些细节的话，可以参考下本书的强指针章节，这里不再赘述。
void AudioFlinger::onFirstRef()
{
      int rc = 0;
      Mutex::Autolock _l(mLock);
      charval_str[PROPERTY_VALUE_MAX] = { 0 };
      if(property_get("ro.audio.flinger_standbytime_ms", val_str, NULL) > =0) {
              uint32_t int_val;
              if (1 ==sscanf(val_str, "%u", & int_val)) {
                      mStandbyTimeInNsecs= milliseconds(int_val);
                      ALOGI("Using%u mSec as standby time.", int_val);
              } else {
                      mStandbyTimeInNsecs = kDefaultStandbyTimeInNsecs;
                      …
              }
}
mMode = AUDIO_MODE_NORMAL;
      mMasterVolumeSW = 1.0;
      mMasterVolume    = 1.0;
      mHardwareStatus =AUDIO_HW_IDLE;
}
属性ro.audio.flinger_standbytime_ms为用户调整standby时间提供了一个接口，早期版本中这个时间值是固定的。接下来初始化几个重要的内部变量，和构造函数的做法不同的是，这里赋予的都是有效的值了。
从这时开始，AudioFlinger就是一个“ 有意义” 的实体了，因为有人使用到了它。接下来其它进程可以通过ServiceManager来访问，并调用createTrack、openOutput等一系列接口来驱使AudioFlinger执行音频处理操作，我们在后面章节会陆续讲解到。

    推荐阅读


    上一篇：Android音频系统之AudioPolicyService

    下一篇：Android插件化开发之Hook StartActivity方法