AudioFlinger学习笔记1

1.AudioFlinger启动流程

在init.rc中会定义mediaserver进程:
service media /system/bin/mediaserver
    class main
    user media
    group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm
    ioprio rt 4
当init进程启动后,会去启动mediaServer服务。MediaServer服务启动后,会call到main_mediaserver.cpp的main函数,main函数会去初始化各种service
 InitializeIcuOrDie();
        sp proc(ProcessState::self());
        sp sm = defaultServiceManager();
        ALOGI("ServiceManager: %p", sm.get());
        AudioFlinger::instantiate();
        MediaPlayerService::instantiate();
        ResourceManagerService::instantiate();
        CameraService::instantiate();
        AudioPolicyService::instantiate();
        SoundTriggerHwService::instantiate();
        RadioService::instantiate();
        registerExtensions();
        ProcessState::self()->startThreadPool();
        IPCThreadState::self()->joinThreadPool();
这里我们比较关心的是AudioFlinger和AudioPolicyService,在AudioFlinger.cpp和AudioPolicyService.cpp没有对应的instantiate()函数实现,而是直接call到BinderService.h的instantiate函数:
static void instantiate() { publish(); }
BinderService.h的publish函数,主要是将service注册到ServiceManager中:
 static status_t publish(bool allowIsolated = false) {
        sp sm(defaultServiceManager());
        return sm->addService(
                String16(SERVICE::getServiceName()),
                new SERVICE(), allowIsolated);
    }
2.AudioFlinger中Binder通讯流程
1)AudioFlingerClient和AudioPolicyServiceClient的定义
在AudioSystem.h中,有定义主要的两个Client,分别是AudioFlingerClient和AudioPolicyServiceClient。
根据AudioFlingerClient的定义:
 class AudioFlingerClient: public IBinder::DeathRecipient, public BnAudioFlingerClient
AudioFlingerClient是BnAudioFlingerClient的实现类,当用IAudioFlingerClient进行Binder通讯时,通过BpAudioFlingerClient,最终在Binder Server端会call到BnAudioFlingerClient即AudioFlingerClient。
根据AudioPolicyServiceClient的定义:
class AudioPolicyServiceClient: public IBinder::DeathRecipient,public BnAudioPolicyServiceClient
AudioPolicyServiceClient是BnAudioPolicyServiceClient的实现类,当用IAudioPolicyServiceClient进行Binder通讯时,通过BpAudioPolicyServiceClient,最终在Binder Server端会call到BnAudioPolicyServiceClient即AudioPolicyServiceClient。
2)AudioFlingerClient如何与AudioFlinger建立联系
在AudioSystem.cpp中,有如下函数:
// establish binder interface to AudioFlinger service
const sp AudioSystem::get_audio_flinger()
{
    sp af;
    sp afc;
    {
        Mutex::Autolock _l(gLock);
        if (gAudioFlinger == 0) {
            sp sm = defaultServiceManager();
            sp binder;
            do {
                binder = sm->getService(String16("media.audio_flinger"));
                if (binder != 0)
                    break;
                ALOGW("AudioFlinger not published, waiting...");
                usleep(500000); // 0.5 s
            } while (true);
            if (gAudioFlingerClient == NULL) {
                gAudioFlingerClient = new AudioFlingerClient();
            } else {
                if (gAudioErrorCallback) {
                    gAudioErrorCallback(NO_ERROR);
                }
            }
            binder->linkToDeath(gAudioFlingerClient);
            gAudioFlinger = interface_cast(binder);
            LOG_ALWAYS_FATAL_IF(gAudioFlinger == 0);
            afc = gAudioFlingerClient;
        }
        af = gAudioFlinger;
    }
    if (afc != 0) {
        af->registerClient(afc);
    }
    return af;
}
在上面的函数中可以看到通过ServiceManager拿到AudioFlinger的实例(Binder Client端)并作为函数返回值。AudioFlingerClient实例化以后,会注册到AudioFlinger中。
在AudioSystem.cpp中,会实现AudioFlingerClient的函数,在函数实现中,最终会call到AudioFlinger中:
status_t AudioSystem::AudioFlingerClient::getInputBufferSize(
                                                uint32_t sampleRate, audio_format_t format,
                                                audio_channel_mask_t channelMask, size_t* buffSize)
{
    const sp& af = AudioSystem::get_audio_flinger();
    if (af == 0) {
        return PERMISSION_DENIED;
    }
    Mutex::Autolock _l(mLock);
    // Do we have a stale mInBuffSize or are we requesting the input buffer size for new values
    if ((mInBuffSize == 0) || (sampleRate != mInSamplingRate) || (format != mInFormat)
        || (channelMask != mInChannelMask)) {
        size_t inBuffSize = af->getInputBufferSize(sampleRate, format, channelMask);
        if (inBuffSize == 0) {
            ALOGE("AudioSystem::getInputBufferSize failed sampleRate %d format %#x channelMask %x",
                    sampleRate, format, channelMask);
            return BAD_VALUE;
        }
        // A benign race is possible here: we could overwrite a fresher cache entry
        // save the request params
        mInSamplingRate = sampleRate;
        mInFormat = format;
        mInChannelMask = channelMask;

        mInBuffSize = inBuffSize;
    }

    *buffSize = mInBuffSize;

    return NO_ERROR;
}
但是在AudioSystem中不会直接call AudioFlinger的getInputBufferSize函数,而是先call AudioFlingerClient中的getInputBufferSize,再由AudioFlingerClient call到AudioFlinger。
这里应用程序和AudioFlinger进行交互时,都会有一个AudioFlingerClient与应用程序对应。比较类似应用程序和SurfaceFlinger连接时,都会有SurfaceComposerClient与其对应。
3)AudioFlinger中Binder实现
在上面例子中,AudioSystem会拿到AudioFlinger的Client端的实例,即BpAudioFlinger。IAudioFlinger类是用于AudioFlinger通讯的类,除了有Binder Client端的BpAudioFlinger外,还有Binder Server端的BnAudioFlinger,根据AudioFlinger.h的定义:
class AudioFlinger :public BinderService,public BnAudioFlinger
可以看到AudioFlinger是IAudioFlinger Binder Server端的实现,即通过AudioSystem的AudioFlingerClient,最终经过Binder通讯,会call到AudioFlinger。
4)AudioPolicyServiceClient如何与AudioPolicyService建立联系
这个过程和"AudioFlingerClient如何与AudioFlinger建立联系"类似,在AudioSystem中,有如下函数实现:
// establish binder interface to AudioPolicy service
const sp AudioSystem::get_audio_policy_service()
{
    sp ap;
    sp apc;
    {
        Mutex::Autolock _l(gLockAPS);
        if (gAudioPolicyService == 0) {
            sp sm = defaultServiceManager();
            sp binder;
            do {
                binder = sm->getService(String16("media.audio_policy"));
                if (binder != 0)
                    break;
                ALOGW("AudioPolicyService not published, waiting...");
                usleep(500000); // 0.5 s
            } while (true);
            if (gAudioPolicyServiceClient == NULL) {
                gAudioPolicyServiceClient = new AudioPolicyServiceClient();
            }
            binder->linkToDeath(gAudioPolicyServiceClient);
            gAudioPolicyService = interface_cast(binder);
            LOG_ALWAYS_FATAL_IF(gAudioPolicyService == 0);
            apc = gAudioPolicyServiceClient;
        }
        ap = gAudioPolicyService;
    }
    if (apc != 0) {
        ap->registerClient(apc);
    }

    return ap;
}
通过SysytemManager拿到IAudioPolicyService Binder Client端的实例,并作为函数返回值返回。同时实例化AudioPolicyServiceClient,并注册到AudioPolicyService中。
SystemService不会直接call AudioPolicyService的函数,而是通过AudioPolicyServiceClient,然后再call到AudioPolicyService。即应用程序有一个与之对应的AudioPolicyServiceClient。
5)AudioPolicyService中Binder实现
从AudioPolicyService的定义来:
class AudioPolicyService :public BinderService,public BnAudioPolicyService,public IBinder::DeathRecipient
可以看到AudioPolicyService作为BnAudioPolicyService的实现类,即IAudioPolicyService的Binder Server端的实现类。
关系图如下:

3.dump audio相关的数据
root@mangosteen:/ # service list  | grep audio                                 
29      audio: [android.media.IAudioService]
46      media.audio_policy: [android.media.IAudioPolicyService]
120     media.audio_flinger: [android.media.IAudioFlinger]
从上面可以看到audio相关的service有三个,分别是audio,media.audio_policy和media.audio_flinger。
可以分别通过如下命令,查看需要的audio数据信息:
dumpsys audio 主要包含每个stream volume的信息
例如:
- STREAM_RING:
   Muted: false
   Min: 0
   Max: 7
   Current: 2 (speaker): 3, 4 (headset): 1, 8 (headphone): 1, 80 (bt_a2dp): 3, 40000000 (default): 3
   Devices: speaker
- STREAM_MUSIC:
   Muted: false
   Min: 0
   Max: 100
   Current: 2 (speaker): 35, 4 (headset): 10, 8 (headphone): 10, 80 (bt_a2dp): 35, 40000000 (default): 35
   Devices: speaker
- STREAM_ALARM:
   Muted: false
   Min: 0
   Max: 7
   Current: 2 (speaker): 3, 4 (headset): 1, 8 (headphone): 1, 80 (bt_a2dp): 3, 40000000 (default): 3
   Devices: speaker

dumpsys  media.audio_policy  主要包含和audio策略相关的信息
例如:
 Available input devices:
  Device 1:
  - id:  8
  - type: AUDIO_DEVICE_IN_BUILTIN_MIC                     
  - sampling rates: 48000
  - channel masks: 0x000c
  - formats: AUDIO_FORMAT_PCM_16_BIT
  Device 2:
  - id:  9
  - type: AUDIO_DEVICE_IN_TV_TUNER                        
  - sampling rates: 44100, 48000
  - channel masks: 0x000c
  - formats: AUDIO_FORMAT_PCM_16_BIT

dumpsys  media.audio_flinger  主要包含audioFlinger相关线程的信息
例如:
Output thread 0xec9e5008 type 0 (MIXER):
  Thread name: AudioOut_2
  I/O handle: 2
  TID: 2193
  Standby: yes
  Sample rate: 48000 Hz
  HAL frame count: 1024
  HAL format: 0x1 (pcm16)
  HAL buffer size: 4096 bytes
  Channel count: 2
  Channel mask: 0x00000003 (front-left, front-right)
  Format: 0x1 (pcm16)
  Frame size: 4 bytes
  Pending config events: none
  Output device: 0x2 (SPEAKER)
  Input device: 0 (NONE)
  Audio source: 0 (default)
  Normal frame count: 1024
  Last write occurred (msecs): 6250709
  Total writes: 249
  Delayed writes: 0
  Blocked in write: no
  Suspend count: 0
  Sink buffer : 0xab51ac00
  Mixer buffer: 0xab521a20
  Effect buffer: 0xab51bc20
  Fast track availMask=0xfe
  AudioStreamOut: 0xab521960 flags 0x2 (PRIMARY)
  Thread throttle time (msecs): 37
  AudioMixer tracks: 0x00000001
  FastMixer not initialized
  Stream volumes in dB: 0:-18, 1:-16, 2:-17, 3:1, 4:-17, 5:-17, 6:0, 7:-16, 8:-18, 9:-96, 10:-27, 11:-15, 12:0, 13:0
  Normal mixer raw underrun counters: partial=0 empty=0
  1 Tracks of which 0 are active
    Name Active Client Type      Fmt Chn mask Session fCount S F SRate  L dB  R dB    Server Main buf  Aux Buf Flags UndFrmCnt
       0     no   1644    5 00000001 00000001      20  24576 S 1 48000     0     0  00014424 0xab51ac00 0x0 0x601       988 
  0 Effect Chains




你可能感兴趣的:(android移动开发)