Android音频系统之AudioTrack(二)

1.1.1 AudioPolicyService的路由实现

我们在AudioPolicyService小节曾将其比作是一个“路由器”，不过还没有深入解析它是如何完成路由选择的。这部分的功能与使用者——AudioTrack有很大关联，所以我们特别将它的实现原理剖析放在这里，以使读者可以综合起来理解。

路由器功能由如下几个部分组成：

l  与发送方(AudioTrack)的接口

就好像路由器首先要接收到一个IP数据包，它才会去做路由处理，否则AudioPolicyService就成了“无源之水”了

l  与接收方(AudioFlinger)的接口

道理和上面是类似的，AudioPolicyService内部拥有当前系统中所有音频设备的信息，就好比一个路由器也需要预先知道它有多少个节点，才可能把音频数据发送到正确的终点一样

l  路由路径的选择策略

路径选择策略是AudioPolicyService的重点。和传统的路由器不同，它的路径选择算法并不是固定的，而是通过灵活的方式先产生一个策略制定者，然后再由它来生成具体的策略

 

大家应该还记得前面AudioTrack小节中，我们调用了AudioSystem::getOutput，即：

status_t AudioTrack::set(…)

{…

    audio_io_handle_t output =AudioSystem::getOutput(streamType, sampleRate, format, channelMask, flags);

…}

AudioSystem只是一个中介，其中的实现还是由AudioPolicyService完成的：

audio_io_handle_t AudioSystem::getOutput(…)

{

    constsp<IAudioPolicyService>& aps =AudioSystem::get_audio_policy_service();

    if (aps == 0) return 0;

    returnaps->getOutput(stream, samplingRate, format, channels, flags);

}

显然是直接调用了AudioPolicyService的服务接口：

audio_io_handle_t  AudioPolicyService::getOutput(...)

{   …

    Mutex::Autolock _l(mLock);

    return  mpAudioPolicy->get_output(mpAudioPolicy,stream, samplingRate, format, channels, flags);

}

变量mpAudioPolicy便是由策略制定者“生产”出来的Policy。在原生态的实现中它代表的是legacy_audio_policy::policy@Audio_policy_hal.cpp，因而上面实际上调用的是如下函数：

static  audio_io_handle_t  ap_get_output(struct audio_policy *pol,…)

{

    struct legacy_audio_policy*lap = to_lap(pol);

    returnlap->apm->getOutput((AudioSystem::stream_type)stream, sampling_rate,(int) format, channels,

                               (AudioSystem::output_flags)flags);

}

也就是说，前面的apm->getOutput的接口实现最终是落在getOutput @ AudioPolicyManagerBase(AudioPolicyManagerDefault继承自AudioPolicyManagerBase，而后者又继承自AudioPolicyInterface)。

我们先来看下Aud