(forward)看到的一篇比较好的AudioFlinger分析
来源:互联网 发布:matlab 输出数据 编辑:程序博客网 时间:2024/05/02 21:20
一 目的
本文承接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)
{
spproc(ProcessState::self());
sp 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;
returnret;
}
当然,setXXX还有些别的东西,但基本上都会涉及到硬件对象。我们暂且不管它。等分析到Audio策略再说。
好了,Android系统启动的时候,看来AF也准备好硬件了。不过,创建硬件对象就代表我们可以播放了吗?
2.2 AT调用AF的流程我这里简单的把AT调用AF的流程列一下,待会按这个顺序分析AF的工作方式。
--参加AudioTrack分析的4.1节
(1). 创建
AudioTrack* lpTrack = new AudioTrack();
lpTrack->set(...);
这个就进入到C++的AT了。下面是AT的set函数
audio_io_handle_t output =
AudioSystem::getOutput((AudioSystem::stream_type)streamType,
sampleRate, format, channels,(AudioSystem::output_flags)flags);
status_tstatus = createTrack(streamType, sampleRate, format,channelCount,
frameCount, flags, sharedBuffer, output);
----->creatTrack会和AF打交道。我们看看createTrack重要语句
const sp& audioFlinger =AudioSystem::get_audio_flinger();
//下面很重要,调用AF的createTrack获得一个IAudioTrack对象
sp track =audioFlinger->createTrack();
sp cblk =track->getCblk();//获取共享内存的管理结构
总结一下创建的流程,AT调用AF的createTrack获得一个IAudioTrack对象,然后从这个对象中获得共享内存的对象。
(2). start和write
看看AT的start,估计就是调用IAudioTrack的start吧?
void AudioTrack::start()
{
//果然啊...
status_t status =mAudioTrack->start();
}
那write呢?我们之前讲了,AT就是从共享buffer中:
l Lock缓存
l 写缓存
l Unlock缓存
注意,这里的Lock和Unlock是有问题的,什么问题呢?待会我们再说
按这种方式的话,那么AF一定是有一个线程在那也是:
l Lock,
l 读缓存,写硬件
l Unlock
总之,我们知道了AT的调用AF的流程了。下面一个一个看。
2.3 AF流程1 createTrack
(1)
sp AudioFlinger::createTrack(
pid_t pid,//AT的pid号
int streamType,//MUSIC,流类型
uint32_t sampleRate,//8000 采样率
int format,//PCM_16类型
int channelCount,//2,双声道
int frameCount,//需要创建的buffer可包含的帧数
uint32_t flags,
const sp& sharedBuffer,//AT传入的共享buffer,这里为空
int output,//这个是从AuidoSystem获得的对应MUSIC流类型的索引
在AT(AudioTrack)中,我们涉及到的都是流程方面的事务,而不是系统Audio策略上的内容。WHY?因为AT是AF的客户端,而AF是Android系统中Audio管理的中枢。AT我们分析的是按流程方法,那么以AT为切入点的话,AF的分析也应该是流程分析了。
对于分析AT来说,只要能把它的调用顺序(也就是流程说清楚就可以了),但是对于AF的话,简单的分析调用流程我自己感觉是不够的。因为我发现手机上的声音交互和管理是一件比较复杂的事情。举个简单例子,当听music的时候来电话了,声音处理会怎样?
虽然在Android中,还有一个叫AudioPolicyService的(APS)东西,但是它最终都会调用到AF中去,因为AF实际创建并管理了硬件设备。所以,针对Android声音策略上的分析,我会单独在以后来分析。
二 从AT切入到AF
2.1 AudioFlinger的诞生AF是一个服务,这个就不用我多说了吧?
代码在framework/base/media/mediaserver/Main_mediaServer.cpp中。
int main(int argc, char** argv)
{
sp sm = defaultServiceManager();
....
AudioPolicyService::instantiate();--->APS的实例化
....
}
哇塞,看来这个程序的负担很重啊。没想到。为何AF,APS要和MediaService和CameraService都放到一个篮子里?
看看AF的实例化静态函数,在framework/base/libs/audioFlinger/audioFlinger.cpp中
void AudioFlinger::instantiate() {
}
再来看看它的构造函数是什么做的。
AudioFlinger::AudioFlinger()
mMasterVolume(1.0f), mMasterMute(false), mNextThreadId(0)
{
mHardwareStatus = AUDIO_HW_IDLE;
//创建代表Audio硬件的HAL对象
//设置系统的声音模式等,其实就是设置硬件的模式
}
AF中经常有setXXX的函数,到底是干什么的呢?我们看看setMode函数。
status_t AudioFlinger::setMode(int mode)
{
}
当然,setXXX还有些别的东西,但基本上都会涉及到硬件对象。我们暂且不管它。等分析到Audio策略再说。
好了,Android系统启动的时候,看来AF也准备好硬件了。不过,创建硬件对象就代表我们可以播放了吗?
2.2 AT调用AF的流程我这里简单的把AT调用AF的流程列一下,待会按这个顺序分析AF的工作方式。
--参加AudioTrack分析的4.1节
(1). 创建
AudioTrack* lpTrack = new AudioTrack();
lpTrack->set(...);
这个就进入到C++的AT了。下面是AT的set函数
audio_io_handle_t output =
AudioSystem::getOutput((AudioSystem::stream_type)streamType,
----->creatTrack会和AF打交道。我们看看createTrack重要语句
const sp& audioFlinger =AudioSystem::get_audio_flinger();
总结一下创建的流程,AT调用AF的createTrack获得一个IAudioTrack对象,然后从这个对象中获得共享内存的对象。
(2). start和write
看看AT的start,估计就是调用IAudioTrack的start吧?
void AudioTrack::start()
{
//果然啊...
}
那write呢?我们之前讲了,AT就是从共享buffer中:
l
l
l
注意,这里的Lock和Unlock是有问题的,什么问题呢?待会我们再说
按这种方式的话,那么AF一定是有一个线程在那也是:
l
l
l
总之,我们知道了AT的调用AF的流程了。下面一个一个看。
2.3 AF流程1 createTrack
(1)
sp AudioFlinger::createTrack(