赞
踩
我们在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
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。