AudioFlinger分析.docx

第二部分 AudioFlinger分析 一目的本文承接Audio第一部分的AudioTrack，通过AudioTrack作为AF（AudioFlinger）的客户端，来看看AF是如何完成工作的。在AT（AudioTrack）中，我们涉及到的都是流程方面的事务，而不是系统Audio策略上的内容。WHY？因为AT是AF的客户端，而AF是Android系统中Audio管理的中枢。AT我们分析的是按流程方法，那么以AT为切入点的话，AF的分析也应该是流程分析了。对于分析AT来说，只要能把它的调用顺序（也就是流程说清楚就可以了），但是对于AF的话，简单的分析调用流程我自己感觉是不够的。因为我发现手机上的声音交互和管理是一件比较复杂的事情。举个简单例子，当听music的时候来电话了，声音处理会怎样？虽然在Android中，还有一个叫AudioPolicyService的（APS）东西，但是它最终都会调用到AF中去，因为AF实际创建并管理了硬件设备。所以，针对Android声音策略上的分析，我会单独在以后来分析。二从AT切入到AF直接从头看代码是没法掌握AF的主干的，必须要有一个切入点，也就是用一个正常的调用流程来分析AF的处理流程。先看看AF的产生吧，这个C/S架构的服务者是如何产生的呢？2.1 AudioFlinger的诞生AF是一个服务，这个就不用我多说了吧？代码在framework/base/media/mediaserver/Main_mediaServer.cpp中。int main(int argc, char** argv){ spProcessState proc(ProcessState::self());spIServiceManager sm = defaultServiceManager();.... AudioFlinger::instantiate();---AF的实例化AudioPolicyService::instantiate();---APS的实例化.... ProcessState::self()-startThreadPool(); IPCThreadState::self()-joinThreadPool();}哇塞，看来这个程序的负担很重啊。没想到。为何AF，APS要和MediaService和CameraService都放到一个篮子里？看看AF的实例化静态函数，在framework/base/libs/audioFlinger/audioFlinger.cpp中void AudioFlinger::instantiate() { defaultServiceManager()-addService( //把AF实例加入系统服务 String16(media.audio_flinger), new AudioFlinger());}再来看看它的构造函数是什么做的。AudioFlinger::AudioFlinger() : BnAudioFlinger(),//初始化基类 mAudioHardware(0), //audio硬件的HAL对象mMasterVolume(1.0f), mMasterMute(false), mNextThreadId(0){mHardwareStatus = AUDIO_HW_IDLE;//创建代表Audio硬件的HAL对象 mAudioHardware = AudioHardwareInterface::create();? mHardwareStatus = AUDIO_HW_INIT; if (mAudioHardware-initCheck() == NO_ERROR) { setMode(AudioSystem::MODE_NORMAL);//设置系统的声音模式等，其实就是设置硬件的模式 setMasterVolume(1.0f); setMasterMute(false); }}AF中经常有setXXX的函数，到底是干什么的呢？我们看看setMode函数。status_t AudioFlinger::setMode(int mode){ mHardwareStatus = AUDIO_HW_SET_MODE; status_t ret = mAudioHardware-setMode(mode);//设置硬件的模式 mHardwareStatus = AUDIO_HW_IDLE; return ret;}当然，setXXX还有些别的东西，但基本上都会涉及到硬件对象。我们暂且不管它。等分析到Au