Android深入浅出之Audio解析

android深入浅出之audio解析

第一部分audiotrack分析

一目的

本文的目的是通过从audio来分析android的代码，包括android自定义的那套机制和一些常见类的使用，比如thread，memorybase等。

分析的流程是：

l先从api层对应的某个类开始，用户层先要有一个简单的使用流程。

l根据这个流程，一步步进入到jni，服务层。在此过程中，碰到不熟悉或者第一次见到的类或者方法，都会解释。也就是深度优先的方法。

1.1分析工具

分析工具很简单，就是sourceinsight和android的api doc文档。当然还得有android的源代码。我这里是基于froyo的。

注意，froyo源码太多了，不要一股脑的加入到sourceinsight中，只要把framwork目录下的源码加进去就可以了，后续如要用的话，再加别的目录。

二audio系统

先看看audio里边有哪些东西？通过android的sdk文档，发现主要有三个：

laudiomanager：这个主要是用来管理audio系统的

laudiotrack：这个主要是用来播放声音的

laudiorecord：这个主要是用来录音的

其中audiomanager的理解需要考虑整个系统上声音的策略问题，例如来电话铃声，短信铃声等，主要是策略上的问题。一般看来，最简单的就是播放声音了。所以我们打算从audiotrack开始分析。

三audiotrack（java层）

java的audiotrack类的代码在：

framework/base/media/java/android/media/audiotrack.java中。

3.1 audiotrack api的使用例子

先看看使用例子，然后跟进去分析。至于audiotrack的其他使用方法和说明，需要大家自己去看api文档了。

//根据采样率，采样精度，单双声道来得到frame的大小。

int bufsize = audiotrack.getminbuffersize(8000,//每秒8k个点

　　audioformat.channel_configuration_stereo,//双声道

audioformat.encoding_pcm_16bit);//一个采样点16比特-2个字节

//注意，按照数字音频的知识，这个算出来的是一秒钟buffer的大小。

//创建audiotrack

audiotrack trackplayer = new audiotrack(audiomanager.stream_music, 8000,

　　audioformat.channel_configuration_ stereo,

　　audioformat.encoding_pcm_16bit,

　　bufsize,

audiotrack.mode_stream);//

trackplayer.play() ;//开始

trackplayer.write(bytes_pkg, 0, bytes_pkg.length) ;//往track中写数据

….

trackplayer.stop();//停止播放

trackplayer.release();//释放底层资源。

这里需要解释下两个东西：

1 audiotrack.mode_stream的意思：

audiotrack中有mode_static和mode_stream两种分类。stream的意思是由用户在应用程序通过write方式把数据一次一次得写到audiotrack中。这个和我们在socket中发送数据一样，应用层从某个地方获取数据，例如通过编解码得到pcm数据，然后write到audiotrack。

这种方式的坏处就是总是在java层和native层交互，效率损失较大。

而static的意思是一开始创建的时候，就把音频数据放到一个固定的buffer，然后直接传给audiotrack，后续就不用一次次得write了。audiotrack会自己播放这个buffer中的数据。

这种方法对于铃声等内存占用较小，延时要求较高的声音来说很适用。

2 streamtype

这个在构造audiotrack的第一个参数中使用。这个参数和android中的audiomanager有关系，涉及到手机上的音频管理策略。

android将系统的声音分为以下几类常见的（未写全）：

lstream_alarm：警告声

lstream_musci：音乐声，例如music等

lstream_ring：铃声

lstream_system：系统声音

lstream_vocie_call：电话声音

为什么要分这么多呢？以前在台式机上开发的时候很少知道有这么多的声音类型，不过仔细思考下，发现这样做是有道理的。例如你在听music的时候接到电话，这个时候music播放肯定会停止，此时你只能听到电话，如果你调节音量的话，这个调节肯定只对电话起作用。当电话打完了，再回到music，你肯定不用再调节音量了。

其实系统将这几种声音的数据分开管理，所以，这个参数对audiotrack来说，它的含义就是告诉系统，我现在想使用的是哪种类型的声音，这样系统就可以对应管理他们了。

3.2分析之getminbuffersize

audiotrack的例子就几个函数。先看看第一个函数：

audiotrack.getminbuffersize(8000,//每秒8k个点

　　audioformat.channel_configuration_stereo,//双声道

audioformat.encoding_pcm_16bit);

----->audiotrack.java

//注意，这是个static函数

static public int getminbuffersize(int samplerateinhz, int channelconfig, int audioformat) {

int channelcount = 0;

switch(channelconfig) {

case audioformat.channel_out_mono:

case audioformat.channel_configuration_mono:

channelcount = 1;

break;

case audioformat.channel_out_stereo:

case audioformat.channel_configuration_stereo:

channelcount = 2;--->看到了吧，外面名字搞得这么酷，其实就是指声道数

break;

default:

loge("getminbuffersize(): invalid channel configuration.");

return audiotrack.error_bad_value;

}

//目前只支持pcm8和pcm16精度的音频

if ((audioformat != audioformat.encoding_pcm_16bit)

&& (audioformat != audioformat.encoding_pcm_8bit)) {

loge("getminbuffersize(): invalid audio format.");

return audiotrack.error_bad_value;

}

//ft，对采样频率也有要求，太低或太高都不行，人耳分辨率在20hz到40khz之间

if ( (samplerateinhz < 4000) || (samplerateinhz > 48000) ) {

loge("getminbuffersize(): " + samplerateinhz +"hz is not a supported sample rate.");

return audiotrack.error_bad_value;

}

//调用native函数，够烦的，什么事情都搞到jni层去。

int size = native_get_min_buff_size(samplerateinhz, channelcount, audioformat);

if ((size == -1) || (size == 0)) {

loge("getminbuffersize(): error querying hardware");

return audiotrack.error;

}

else {

return size;

}

native_get_min_buff_size--->在framework/base/core/jni/android_media_track.cpp中实现。（不了解jni的一定要学习下，否则只能在java层搞，太狭隘了。）最终对应到函数

static jint android_media_audiotrack_get_min_buff_size(jnienv *env,jobject thiz,

jint samplerateinhertz, jint nbchannels, jint audioformat)

{//注意我们传入的参数是：

//samplerateinhertz = 8000

//nbchannels = 2；

//audioformat = audioformat.encoding_pcm_16bit

int afsamplingrate;

int afframecount;

uint32_t aflatency;

//下面涉及到audiosystem，这里先不解释了，

//反正知道从audiosystem那查询了一些信息

if (audiosystem::getoutputsamplingrate(&afsamplingrate) != no_error) {

return -1;

}

if (audiosystem::getoutputframecount(&afframecount) != no_error) {

return -1;

}

if (audiosystem::getoutputlatency(&aflatency) != no_error) {

return -1;

}

//音频中最常见的是frame这个单位，什么意思？经过多方查找，最后还是在alsa的wiki中

//找到解释了。一个frame就是1个采样点的字节数*声道。为啥搞个frame出来？因为对于多//声道的话，用1个采样点的字节数表示不全，因为播放的时候肯定是多个声道的数据都要播出来//才行。所以为了方便，就说1秒钟有多少个frame，这样就能抛开声道数，把意思表示全了。

// ensure that buffer depth covers at least audio hardware latency

uint32_t minbufcount = aflatency / ((1000 * afframecount)/afsamplingrate);

if (minbufcount < 2) minbufcount = 2;

uint32_t minframecount =

(afframecount*samplerateinhertz*minbufcount)/afsamplingrate;

//下面根据最小的framecount计算最小的buffersize

int minbuffsize = minframecount

* (audioformat == javaaudiotrackfields.pcm16 2 : 1)

* nbchannels;

return minbuffsize;

}

getminbufsize函数完了后，我们得到一个满足最小要求的缓冲区大小。这样用户分配缓冲区就有了依据。下面就需要创建audiotrack对象了

3.3分析之new audiotrack

先看看调用函数：

audiotrack trackplayer = new audiotrack(

audiomanager.stream_music,

8000,

　　audioformat.channel_configuration_ stereo,

　　audioformat.encoding_pcm_16bit,

　　bufsize,

audiotrack.mode_stream);//

其实现代码在audiotrack.java中。

public audiotrack(int streamtype, int samplerateinhz, int channelconfig, int audioformat,

int buffersizeinbytes, int mode)

throws illegalargumentexception {

mstate = state_uninitialized;

//获得主线程的looper，这个在mediascanner分析中已经讲过了

if ((minitializationlooper = looper.mylooper()) == null) {

minitializationlooper = looper.getmainlooper();

}

//检查参数是否合法之类的，可以不管它

audioparamcheck(streamtype, samplerateinhz, channelconfig, audioformat, mode);

//我是用getminbufsize得到的大小，总不会出错吧？

audiobuffsizecheck(buffersizeinbytes);

//调用native层的native_setup，把自己的weakreference传进去了

//不了解java weakreference的可以上网自己查一下，很简单的

int initresult = native_setup(new weakreference(this),

mstreamtype,这个值是audiomanager.stream_music

msamplerate,这个值是8000

mchannels,这个值是2

maudioformat,这个值是audioformat.encoding_pcm_16bit

mnativebuffersizeinbytes, //这个是刚才getminbufsize得到的

mdataloadmode);dataloadmode是mode_stream

....

}

上面函数调用最终进入了jni层android_media_audiotrack.cpp下面的函数

static int

android_media_audiotrack_native_setup(jnienv *env, jobject thiz, jobject weak_this,

jint streamtype, jint samplerateinhertz, jint channels,

jint audioformat, jint buffsizeinbytes, jint memorymode)

{

int afsamplerate;

int afframecount;

下面又要调用一堆东西，烦不烦呐？具体干什么用的，以后分析到audiosystem再说。

audiosystem::getoutputframecount(&afframecount, streamtype)；

audiosystem::getoutputsamplingrate(&afsamplerate, streamtype)；

audiosystem::isoutputchannel(channels)；

popcount是统计一个整数中有多少位为1的算法

int nbchannels = audiosystem::popcount(channels);

if (streamtype == javaaudiotrackfields.stream_music) {

atstreamtype = audiosystem::music;

}

int bytespersample = audioformat == javaaudiotrackfields.pcm16 2 : 1;

int format = audioformat == javaaudiotrackfields.pcm16

audiosystem::pcm_16_bit : audiosystem::pcm_8_bit;

int framecount = buffsizeinbytes / (nbchannels * bytespersample);

//上面是根据buffer大小和一个frame大小来计算帧数的。

// audiotrackjnistorage，就是一个保存一些数据的地方，这

//里边有一些有用的知识，下面再详细解释

audiotrackjnistorage* lpjnistorage = new audiotrackjnistorage();

jclass clazz = env->getobjectclass(thiz);

lpjnistorage->mcallbackdata.audiotrack_class = (jclass)env->newglobalref(clazz);

lpjnistorage->mcallbackdata.audiotrack_ref = env->newglobalref(weak_this);

lpjnistorage->mstreamtype = atstreamtype;

//创建真正的audiotrack对象

audiotrack* lptrack = new audiotrack();

if (memorymode == javaaudiotrackfields.mode_stream) {

//如果是stream流方式的话，把刚才那些参数设进去

lptrack->set(

atstreamtype,// stream type

samplerateinhertz,

format,// word length, pcm

channels,

framecount,

0,// flags

audiocallback,

&(lpjnistorage->mcallbackdata),//callback, callback data (user)

0,// notificationframes == 0 since not using event_more_data to feed the audiotrack

0,//共享内存，stream模式需要用户一次次写，所以就不用共享内存了

true);// thread can call java

} else if (memorymode == javaaudiotrackfields.mode_static) {

//如果是static模式，需要用户一次性把数据写进去，然后

//再由audiotrack自己去把数据读出来，所以需要一个共享内存

//这里的共享内存是指c++audiotrack和audioflinger之间共享的内容

//因为真正播放的工作是由audioflinger来完成的。

lpjnistorage->allocsharedmem(buffsizeinbytes);

lptrack->set(

atstreamtype,// stream type

samplerateinhertz,

format,// word length, pcm

channels,

framecount,

0,// flags

audiocallback,

&(lpjnistorage->mcallbackdata),//callback, callback data (user));

0,// notificationframes == 0 since not using event_more_data to feed the audiotrack

lpjnistorage->mmembase,// shared mem

true);// thread can call java

}

if (lptrack->initcheck() != no_error) {

loge("error initializing audiotrack");

goto native_init_failure;

}

//又来这一招，把c++audiotrack对象指针保存到java对象的一个变量中

//这样，native层的audiotrack对象就和java层的audiotrack对象关联起来了。

env->setintfield(thiz, javaaudiotrackfields.nativetrackinjavaobj, (int)lptrack);

env->setintfield(thiz, javaaudiotrackfields.jnidata, (int)lpjnistorage);

}

1 audiotrackjnistorage详解

这个类其实就是一个辅助类，但是里边有一些知识很重要，尤其是android封装的一套共享内存的机制。这里一并讲解，把这块搞清楚了，我们就能轻松得在两个进程间进行内存的拷贝。

audiotrackjnistorage的代码很简单。

struct audiotrack_callback_cookie {

jclassaudiotrack_class;

jobjectaudiotrack_ref;

};cookie其实就是把java中的一些东西保存了下，没什么特别的意义

class audiotrackjnistorage {

public:

spmmemheap;//这两个memory很重要

spmmembase;

audiotrack_callback_cookie mcallbackdata;

intmstreamtype;

bool allocsharedmem(int sizeinbytes) {

mmemheap = new memoryheapbase(sizeinbytes, 0, "audiotrack heap base");

mmembase = new memorybase(mmemheap, 0, sizeinbytes);

//注意用法，先弄一个heapbase，再把heapbase传入到memorybase中去。

return true;

}

};

2 memoryheapbase

memroyheapbase也是android搞的一套基于binder机制的对内存操作的类。既然是binder机制，那么肯定有一个服务端（bnxxx），一个代理端bpxxx。看看memoryheapbase定义：

class memoryheapbase : public virtual bnmemoryheap

{

果然，从bnmemoryheap派生，那就是bn端。这样就和binder挂上钩了

//bp端调用的函数最终都会调到bn这来

对binder机制不了解的，可以参考：

https://blog.csdn.net/innost/archive/2011/01/08/6124685.x

有好几个构造函数，我们看看我们使用的：

memoryheapbase::memoryheapbase(size_t size, uint32_t flags, char const * name)

: mfd(-1), msize(0), mbase(map_failed), mflags(flags),

mdevice(0), mneedunmap(false)

{

const size_t pagesize = getpagesize();

size = ((size + pagesize-1) & ~(pagesize-1));

//创建共享内存，ashmem_create_region这个是系统提供的,可以不管它

//设备上打开的是/dev/ashmem设备，而host上打开的是一个tmp文件

int fd = ashmem_create_region(name == null "memoryheapbase" : name, size);

mapfd(fd, size);//把刚才那个fd通过mmap方式得到一块内存

//不明白得去man mmap看看

mapfd完了后，mbase变量指向内存的起始位置, msize是分配的内存大小，mfd是

ashmem_create_region返回的文件描述符

}

memoryheapbase提供了一下几个函数，可以获取共享内存的大小和位置。

getbaseid()--->返回mfd，如果为负数，表明刚才创建共享内存失败了

getbase()->返回mbase，内存位置

getsize()->返回msize，内存大小

有了memoryheapbase，又搞了一个memorybase，这又是一个和binder机制挂钩的类。

唉，这个估计是一个在memoryheapbase上的方便类吧？因为我看见了offset

那么估计这个类就是一个能返回当前buffer中写位置（就是offset）的方便类

这样就不用用户到处去计算读写位置了。

class memorybase : public bnmemory

{

public:

memorybase(const sp& heap, ssize_t offset, size_t size);

virtual sp getmemory(ssize_t* offset, size_t* size) const;

protected:

size_t getsize() const { return msize; }

ssize_t getoffset() const { return moffset; }

const sp& getheap() const { return mheap; }

};

好了，明白上面两个memoryxxx，我们可以猜测下大概的使用方法了。

lbnxxx端先分配bnmemoryheapbase和bnmemorybase，

l然后把bnmemorybase传递到bpxxx

lbpxxx就可以使用bpmemorybase得到bnxxx端分配的共享内存了。

注意，既然是进程间共享内存，那么bp端肯定使用memcpy之类的函数来操作内存，这些函数是没有同步保护的，而且android也不可能在系统内部为这种共享内存去做增加同步保护。所以看来后续在操作这些共享内存的时候，肯定存在一个跨进程的同步保护机制。我们在后面讲实际播放的时候会碰到。

另外，这里的sharedbuffer最终会在bp端也就是audioflinger那用到。

3.4分析之play和write

java层到这一步后就是调用play和write了。java层这两个函数没什么内容，都是直接转到native层干活了。

先看看play函数对应的jni函数

static void

android_media_audiotrack_start(jnienv *env, jobject thiz)

{

//看见没，从java那个audiotrack对象获取保存的c++层的audiotrack对象指针

//从int类型直接转换成指针。要是以后arm变成64位平台了，看google怎么改！

audiotrack *lptrack = (audiotrack *)env->getintfield(

thiz, javaaudiotrackfields.nativetrackinjavaobj);

lptrack->start(); //这个以后再说

}

下面是write。我们写的是short数组，

static jint

android_media_audiotrack_native_write_short(jnienv *env,jobject thiz,

jshortarray javaaudiodata,

jint offsetinshorts,

jint sizeinshorts,

jint javaaudioformat) {

return (android_media_audiotrack_native_write(env, thiz,

(jbytearray) javaaudiodata,

offsetinshorts*2, sizeinshorts*2,

javaaudioformat)

/ 2);

}

烦人，又根据byte还是short封装了下，最终会调到重要函数writetotrack去

jint writetotrack(audiotrack* ptrack, jint audioformat, jbyte* data,

jint offsetinbytes, jint sizeinbytes) {

ssize_t written = 0;

// regular write() or copy the data to the audiotrack's shared memory

if (ptrack->sharedbuffer() == 0) {

//创建的是流的方式，所以没有共享内存在track中

//还记得我们在native_setup中调用的set吗？流模式下audiotrackjnistorage可没创建

//共享内存

written = ptrack->write(data + offsetinbytes, sizeinbytes);

} else {

if (audioformat == javaaudiotrackfields.pcm16) {

// writing to shared memory, check for capacity

if ((size_t)sizeinbytes > ptrack->sharedbuffer()->size()) {

sizeinbytes = ptrack->sharedbuffer()->size();

}

//看见没？static模式的，就直接把数据拷贝到共享内存里

//当然，这个共享内存是ptrack的，是我们在set时候把audiotrackjnistorage的

//共享设进去的

memcpy(ptrack->sharedbuffer()->pointer(),

data + offsetinbytes, sizeinbytes);

written = sizeinbytes;

} else if (audioformat == javaaudiotrackfields.pcm8) {

pcm8格式的要先转换成pcm16

}

return written;

}

到这里，似乎很简单啊，java层的audiotrack，无非就是调用write函数，而实际由jni层的c++ audiotrack write数据。反正jni这层是再看不出什么有意思的东西了。

四audiotrack（c++层）

接上面的内容，我们知道在jni层，有以下几个步骤：

lnew了一个audiotrack

l调用set函数，把audiotrackjnistorage等信息传进去

l调用了audiotrack的start函数

l调用audiotrack的write函数

那么，我们就看看真正干活的的c++audiotrack吧。

audiotrack.cpp位于framework/base/libmedia/audiotrack.cpp

4.1 new audiotrack()和set调用

jni层调用的是最简单的构造函数：

audiotrack::audiotrack()

: mstatus(no_init) //把状态初始化成no_init。android大量使用了设计模式中的state。

{

}

接下来调用set。我们看看jni那set了什么

lptrack->set(

atstreamtype, //应该是music吧

samplerateinhertz,//8000

format,//应该是pcm_16吧

channels,//立体声=2

framecount,//

0,// flags

audiocallback, //jni中的一个回调函数

&(lpjnistorage->mcallbackdata),//回调函数的参数

0,//通知回调函数，表示audiotrack需要数据，不过暂时没用上

0,//共享buffer地址，stream模式没有

true);//回调线程可以调java的东西

那我们看看set函数把。

status_t audiotrack::set(

int streamtype,

uint32_t samplerate,

int format,

int channels,

int framecount,

uint32_t flags,

callback_t cbf,

void* user,

int notificationframes,

const sp& sharedbuffer,

bool threadcancalljava)

{

...前面一堆的判断，等以后讲audiosystem再说

audio_io_handle_t output =

audiosystem::getoutput((audiosystem::stream_type)streamtype,

samplerate, format, channels, (audiosystem::output_flags)flags);

//createtrack？看来这是真正干活的

status_t status = createtrack(streamtype, samplerate, format, channelcount,

framecount, flags, sharedbuffer, output);

//cbf是jni传入的回调函数audiocallback

if (cbf != 0) { //看来，怎么着也要创建这个线程了！

maudiotrackthread = new audiotrackthread(*this, threadcancalljava);

}

return no_error;

}

看看真正干活的createtrack

status_t audiotrack::createtrack(

int streamtype,

uint32_t samplerate,

int format,

int channelcount,

int framecount,

uint32_t flags,

const sp& sharedbuffer,

audio_io_handle_t output)

{

status_t status;

//啊，看来和audioflinger挂上关系了呀。

const sp& audioflinger = audiosystem::get_audio_flinger();

//下面这个调用最终会在audioflinger中出现。暂时不管它。

sp track = audioflinger->createtrack(getpid(),

streamtype,

samplerate,

format,

channelcount,

framecount,

((uint16_t)flags) << 16,

sharedbuffer,

output,

&status);

//看见没，从track也就是audioflinger那边得到一个imemory接口

//这个看来就是最终write写入的地方

sp cblk = track->getcblk();

maudiotrack.clear();

maudiotrack = track;

mcblkmemory.clear();//sp的clear，就看着做是delete xxx吧

mcblkmemory = cblk;

mcblk = static_cast(cblk->pointer());*>

mcblk->out = 1;

mframecount = mcblk->framecount;

if (sharedbuffer == 0) {

//终于看到buffer相关的了。注意我们这里的情况

//stream模式没有传入共享buffer，但是数据确实又需要buffer承载。

//反正audiotrack是没有创建buffer，那只能是刚才从audioflinger中得到

//的buffer了。

mcblk->buffers = (char*)mcblk + sizeof(audio_track_cblk_t);

}

return no_error;

}

还记得我们说memoryxxx没有同步机制，所以这里应该有一个东西能体现同步的，

那么我告诉大家，就在audio_track_cblk_t结构中。它的头文件在

framework/base/include/private/media/audiotrackshared.h

实现文件就在audiotrack.cpp中

audio_track_cblk_t::audio_track_cblk_t()

//看见下面的shared没？都是表示跨进程共享的意思。这个我就不跟进去说了

//等以后介绍同步方面的知识时，再细说

: lock(mutex::shared), cv(condition::shared), user(0), server(0),

userbase(0), serverbase(0), buffers(0), framecount(0),

loopstart(uint_max), loopend(uint_max), loopcount(0), volumelr(0),

flowcontrolflag(1), forceready(0)

{

}

到这里，大家应该都有个大概的全景了。

laudiotrack得到audioflinger中的一个iaudiotrack对象，这里边有一个很重要的数据结构audio_track_cblk_t，它包括一块缓冲区地址，包括一些进程间同步的内容，可能还有数据位置等内容

laudiotrack启动了一个线程，叫audiotrackthread，这个线程干嘛的呢？还不知道

laudiotrack调用write函数，肯定是把数据写到那块共享缓冲了，然后iaudiotrack在另外一个进程audioflinger中（其实audioflinger是一个服务，在mediaservice中运行）接收数据，并最终写到音频设备中。

那我们先看看audiotrackthread干什么了。

调用的语句是：

maudiotrackthread = new audiotrackthread(*this, threadcancalljava);

audiotrackthread从thread中派生，这个内容在深入浅出binder机制讲过了。

反正最终会调用audiotrackathread的threadloop函数。

先看看构造函数

audiotrack::audiotrackthread::audiotrackthread(audiotrack& receiver, bool bcancalljava)

: thread(bcancalljava), mreceiver(receiver)

{//mreceiver就是audiotrack对象

// bcancalljava为true

}

这个线程的启动由audiotrack的start函数触发。

void audiotrack::start()

{

//start函数调用audiotrackthread函数触发产生一个新的线程，执行maudiotrackthread的

threadloop

sp t = maudiotrackthread;

t->run("audiotrackthread", thread_priority_audio_client);

//让audioflinger中的track也start

status_t status = maudiotrack->start();

}

bool audiotrack::audiotrackthread::threadloop()

{

//太恶心了，又调用audiotrack的processaudiobuffer函数

return mreceiver.processaudiobuffer(this);

}

bool audiotrack::processaudiobuffer(const sp& thread)

{

buffer audiobuffer;

uint32_t frames;

size_t writtensize;

...回调1

mcbf(event_underrun, muserdata, 0);

...回调2都是传递一些信息到jni里边

mcbf(event_buffer_end, muserdata, 0);

// manage loop end callback

while (mloopcount > mcblk->loopcount) {

mcbf(event_loop_end, muserdata, (void *)&loopcount);

}

//下面好像有写数据的东西

do {

audiobuffer.framecount = frames;

//获得buffer，

status_t err = obtainbuffer(&audiobuffer, 1);

size_t reqsize = audiobuffer.size;

//把buffer回调到jni那去，这是单独一个线程，而我们还有上层用户在那不停

//地write呢，怎么会这样？

mcbf(event_more_data, muserdata, &audiobuffer);

audiobuffer.size = writtensize;

frames -= audiobuffer.framecount;

releasebuffer(&audiobuffer); //释放buffer，和obtain相对应，看来是lock和unlock

操作了

}

while (frames);

return true;

}

难道真的有两处在write数据？看来必须得到mcbf去看看了，传的是event_more_data标志。

mcbf由set的时候传入c++的audiotrack，实际函数是：

static void audiocallback(int event, void* user, void *info) {

if (event == audiotrack::event_more_data) {

//哈哈，太好了，这个函数没往里边写数据

audiotrack::buffer* pbuff = (audiotrack::buffer*)info;

pbuff->size = 0;

}

从代码上看，本来google考虑是异步的回调方式来写数据，可惜发现这种方式会比较复杂，尤其是对用户开放的java audiotrack会很不好处理，所以嘛，偷偷摸摸得给绕过去了。

太好了，看来就只有用户的write会真正的写数据了，这个audiotrackthread除了通知一下，也没什么实际有意义的操作了。

让我们看看write吧。

4.2 write

ssize_t audiotrack::write(const void* buffer, size_t usersize)

{

够简单，就是obtainbuffer，memcpy数据，然后releasbuffer

眯着眼睛都能想到，obtainbuffer一定是lock住内存了，releasebuffer一定是unlock内存了

do {

audiobuffer.framecount = usersize/framesize();

status_t err = obtainbuffer(&audiobuffer, -1);

size_t towrite;

towrite = audiobuffer.size;

memcpy(audiobuffer.i8, src, towrite);

src += towrite;

}

usersize -= towrite;

written += towrite;

releasebuffer(&audiobuffer);

} while (usersize);

return written;

}

obtainbuffer太复杂了，不过大家知道其大概工作方式就可以了

status_t audiotrack::obtainbuffer(buffer* audiobuffer, int32_t waitcount)

{

//恕我中间省略太多，大部分都是和当前数据位置相关，

uint32_t framesavail = cblk->framesavailable();

cblk->lock.lock();//看见没，lock了

result = cblk->cv.waitrelative(cblk->lock, milliseconds(waittimems));

//我发现很多地方都要判断远端的audioflinger的状态，比如是否退出了之类的，难道

//没有一个好的方法来集中处理这种事情吗？

if (result == dead_object) {

result = createtrack(mstreamtype, cblk->samplerate, mformat, mchannelcount,

mframecount, mflags, msharedbuffer,getoutput());

}

//得到buffer

audiobuffer->raw = (int8_t *)cblk->buffer(u);

return active status_t(no_error) : status_t(stopped);

}

在看看releasebuffer

void audiotrack::releasebuffer(buffer* audiobuffer)

{

audio_track_cblk_t* cblk = mcblk;

cblk->stepuser(audiobuffer->framecount);

}

uint32_t audio_track_cblk_t::stepuser(uint32_t framecount)

{

uint32_t u = this->user;

u += framecount;

if (out) {

if (buffertimeoutms == max_startup_timeout_ms-1) {

buffertimeoutms = max_run_timeout_ms;

}

} else if (u > this->server) {

u = this->server;

}

if (u >= userbase + this->framecount) {

userbase += this->framecount;

}

this->user = u;

flowcontrolflag = 0;

return u;

}

奇怪了，releasebuffer没有unlock操作啊？难道我失误了？

再去看看obtainbuffer为何写得这么晦涩难懂？

原来在obtainbuffer中会某一次进去lock，再某一次进去可能就是unlock了。没看到obtainbuffer中到处有lock,unlock,wait等同步操作吗。一定是这个道理。难怪写这么复杂。还使用了少用的goto语句。

唉，有必要这样吗！

五audiotrack总结

通过这一次的分析，我自己觉得有以下几个点：

laudiotrack的工作原理，尤其是数据的传递这一块，做了比较细致的分析，包括共享内存，跨进程的同步等，也能解释不少疑惑了。

l看起来，最重要的工作是在audioflinger中做的。通过audiotrack的介绍，我们给后续深入分析audioflinger提供了一个切入点

工作原理和流程嘛，再说一次好了，java层就看最前面那个例子吧，实在没什么说的。

laudiotrack被new出来，然后set了一堆信息，同时会通过binder机制调用另外一端的audioflinger，得到iaudiotrack对象，通过它和audioflinger交互。

l调用start函数后，会启动一个线程专门做回调处理，代码里边也会有那种数据拷贝的回调，但是jni层的回调函数实际并没有往里边写数据，大家只要看write就可以了

l用户一次次得write，那audiotrack无非就是把数据memcpy到共享buffer中咯

l可想而知，audioflinger那一定有一个线程在memcpy数据到音频设备中去。我们拭目以待。

android深入浅出之audio 第二部分 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)

{

sp proc(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;

return ret;

}

当然，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_t status = 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中:

llock缓存

l写缓存

lunlock缓存

注意，这里的lock和unlock是有问题的，什么问题呢待会我们再说

按这种方式的话，那么af一定是有一个线程在那也是：

llock，

l读缓存，写硬件

lunlock

总之，我们知道了at的调用af的流程了。下面一个一个看。

2.3 af流程

1 createtrack

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流类型的索引

status_t *status)

{

sp<:track> track;

sp trackhandle;

sp client;

wp wclient;

status_t lstatus;

{

mutex::autolock _l(mlock);

//根据output句柄，获得线程？

playbackthread *thread = checkplaybackthread_l(output);

//看看这个进程是不是已经是af的客户了

//这里说明一下，由于是c/s架构，那么作为服务端的af肯定有地方保存作为c的at的信息

//那么，af是根据pid作为客户端的唯一标示的

//mclients是一个类似map的数据组织结构

wclient = mclients.valuefor(pid);

if (wclient != null) {

} else {

//如果还没有这个客户信息，就创建一个，并加入到map中去

client = new client(this, pid);

mclients.add(pid, client);

}

//从刚才找到的那个线程对象中创建一个track

track = thread->createtrack_l(client, streamtype, samplerate, format,

channelcount, framecount, sharedbuffer, &lstatus);

}

//喔，还有一个trackhandle，而且返回到af端的是这个trackhandle对象

trackhandle = new trackhandle(track);

return trackhandle;

}

这个af函数中，突然冒出来了很多新类型的数据结构。说实话，我刚开始接触的时候，大脑因为常接触到这些眼生的东西而死机！大家先不要拘泥于这些东西，我会一一分析到的。

先进入到checkplaybackthread_l看看。

audioflinger::playbackthread *audioflinger::checkplaybackthread_l(int output) const

{

playbackthread *thread = null;

//看到这种indexofkey的东西，应该立即能想到：

//喔，这可能是一个map之类的东西，根据key能找到实际的value

if (mplaybackthreads.indexofkey(output) >= 0) {

thread = (playbackthread *)mplaybackthreads.valuefor(output).get();

}

//这个函数的意思是根据output值，从一堆线程中找到对应的那个线程

return thread;

}

看到这里很疑惑啊：

laf的构造函数中没有创建线程，只创建了一个audio的hal对象

l如果at是af的第一个客户的话，我们刚才的调用流程里边，也没看到哪有创建线程的地方呀。

loutput是个什么玩意儿？为什么会根据它作为key来找线程呢？

看来，我们得去output的来源那看看了。

我们知道，output的来源是由at的set函数得到的：如下：

audio_io_handle_t output = audiosystem::getoutput(

(audiosystem::stream_type)streamtype, //music类型

samplerate, //8000

format, //pcm_16

channels, //2两个声道

(audiosystem::output_flags)flags//0

);

上面这几个参数后续不再提示了，大家知道这些值都是由at做为切入点传进去的

然后它在调用at自己的createtrack，最终把这个output值传递到af了。其中audio_io_handle_t类型就是一个int类型。

//叫handle啊？好像linux下这种叫法的很少，难道又是受ms的影响吗？

我们进到audiosystem::getoutput看看。注意，大家想想这是系统的第一次调用,而且发生在audiotrack那个进程里边。audiosystem的位置在framework/base/media/libmedia/audiosystem.cpp中

audio_io_handle_t audiosystem::getoutput(stream_type stream,

uint32_t samplingrate,

uint32_t format,

uint32_t channels,

output_flags flags)

{

audio_io_handle_t output = 0;

if ((flags & audiosystem::output_flag_direct) == 0 &&

((stream != audiosystem::voice_call && stream != audiosystem::bluetooth_sco) ||

channels != audiosystem::channel_out_mono ||

(samplingrate != 8000 && samplingrate != 16000))) {

mutex::autolock _l(glock);

//根据我们的参数，我们会走到这个里边来

//喔，又是从map中找到stream=music的output。可惜啊，我们是第一次进来

//output一定是0

output = audiosystem::gstreamoutputmap.valuefor(stream);

}

if (output == 0) {

//我晕，又到audiopolicyservice(aps)

//由它去getoutput

const sp& aps = audiosystem::get_audio_policy_service();

output = aps->getoutput(stream, samplingrate, format, channels, flags);

if ((flags & audiosystem::output_flag_direct) == 0) {

mutex::autolock _l(glock);

//如果取到output了，再把output加入到audiosystem维护的这个map中去

//说白了，就是保存一些信息吗。免得下次又这么麻烦去骚扰aps！

audiosystem::gstreamoutputmap.add(stream, output);

}

}

return output;

}

怎么办？需要到aps中才能找到output的信息？

没办法，硬着头皮进去吧。那先得看看aps是如何创建的。不过这个刚才已经说了，是和af一块在那个main_mediaservice.cpp中实例化的。

位置在framework/base/lib/libaudioflinger/ audiopolicyservice.cpp中

audiopolicyservice::audiopolicyservice()

: bnaudiopolicyservice() , mppolicymanager(null)

{

//下面两个线程以后再说

mtoneplaybackthread = new audiocommandthread(string8(""));

maudiocommandthread = new audiocommandthread(string8("apmcommandthread"));

#if (defined generic_audio) || (defined audio_policy_test)

//喔，使用普适的audiopolicymanager，把自己this做为参数

//我们这里先使用普适的看看吧

mppolicymanager = new audiopolicymanagerbase(this);

//使用硬件厂商提供的特殊的audiopolicymanager

//mppolicymanager = createaudiopolicymanager(this);

}

}

我们看看audiomanagerbase的构造函数吧，在framework/base/lib/audioflinger/

audiopolicymanagerbase.cpp中。

audiopolicymanagerbase::audiopolicymanagerbase(audiopolicyclientinterface *clientinterface)

: mphonestate(audiosystem::mode_normal), mringermode(0), mmusicstoptime(0), mlimitringtonevolume(false)

{

mpclientinterface = clientinterface;这个client就是aps，刚才通过this传进来了

audiooutputdescriptor *outputdesc = new audiooutputdescriptor();

outputdesc->mdevice = (uint32_t)audiosystem::device_out_speaker;

mhardwareoutput = mpclientinterface->openoutput(&outputdesc->mdevice,

&outputdesc->msamplingrate,

&outputdesc->mformat,

&outputdesc->mchannels,

&outputdesc->mlatency,

outputdesc->mflags);

openoutput又交给aps的openoutput来完成了，真绕....

}

唉，看来我们还是得回到aps，

audio_io_handle_t audiopolicyservice::openoutput(uint32_t *pdevices,

uint32_t *psamplingrate,

uint32_t *pformat,

uint32_t *pchannels,

uint32_t *platencyms,

audiosystem::output_flags flags)

{

sp af = audiosystem::get_audio_flinger();

//ft,ft,ft,ft,ft,ft,ft

//绕了这么一个大圈子，竟然回到audioflinger中了啊？？

return af->openoutput(pdevices, psamplingrate, (uint32_t *)pformat, pchannels,

platencyms, flags);

}

在我们再次被绕晕之后，我们回眸看看足迹吧：

l在audiotrack中，调用set函数

l这个函数会通过audiosystem::getoutput来得到一个output的句柄

las的getoutput会调用audiopolicyservice的getoutput

l然后我们就没继续讲aps的getoutput了，而是去看看aps创建的东西

l发现aps创建的时候会创建一个audiomanagerbase，这个amb的创建又会调用aps的openoutput。

laps的openoutput又会调用audioflinger的openoutput

有一个疑问，at中set参数会和aps构造时候最终传入到af的openoutput一样吗？如果不一样，那么构造时候openoutput的又是什么参数呢？

先放下这个悬念，我们继续从aps的getoutput看看。

audio_io_handle_t audiopolicyservice::getoutput(audiosystem::stream_type stream,

uint32_t samplingrate,

uint32_t format,

uint32_t channels,

audiosystem::output_flags flags)

{

mutex::autolock _l(mlock);

//自己又不干活，由audiomanagerbase干活

return mppolicymanager->getoutput(stream, samplingrate, format, channels, flags);

}

进去看看吧

audio_io_handle_t audiopolicymanagerbase::getoutput(audiosystem::stream_type stream,

uint32_t samplingrate,

uint32_t format,

uint32_t channels,

audiosystem::output_flags flags)

{

audio_io_handle_t output = 0;

uint32_t latency = 0;

// open a non direct output

output = mhardwareoutput; //这个是在哪里创建的？在amb构造的时候..

return output;

}

具体amb的分析待以后audio系统策略的时候我们再说吧。反正，到这里，我们知道了，在aps构造的时候会open一个output，而这个output又会调用af的openoutput。

int audioflinger::openoutput(uint32_t *pdevices,

uint32_t *psamplingrate,

uint32_t *pformat,

uint32_t *pchannels,

uint32_t *platencyms,

uint32_t flags)

{

status_t status;

playbackthread *thread = null;

mhardwarestatus = audio_hw_output_open;

uint32_t samplingrate = psamplingrate *psamplingrate : 0;

uint32_t format = pformat *pformat : 0;

uint32_t channels = pchannels *pchannels : 0;

uint32_t latency = platencyms *platencyms : 0;

mutex::autolock _l(mlock);

//由audio硬件hal对象创建一个audiostreamout对象

audiostreamout *output = maudiohardware->openoutputstream(*pdevices,

(int *)&format,

&channels,

&samplingrate,

&status);

mhardwarestatus = audio_hw_idle;

if (output != 0) {

//创建一个mixer线程

thread = new mixerthread(this, output, ++mnextthreadid);

}

//终于找到了，把这个线程加入线程管理组织中

mplaybackthreads.add(mnextthreadid, thread);

return mnextthreadid;

}

}

明白了，看来at在调用af的createtrack的之前，af已经在某个时候把线程创建好了，而且是一个mixer类型的线程，看来和混音有关系呀。这个似乎和我们开始设想的af工作有点联系喔。lock，读缓存，写audio硬件，unlock。可能都是在这个线程里边做的。

2继续createtrack

audioflinger::createtrack(

pid_t pid,

int streamtype,

uint32_t samplerate,

int format,

int channelcount,

int framecount,

uint32_t flags,

const sp& sharedbuffer,

int output,

status_t *status)

{

sp<:track> track;

sp trackhandle;

sp client;

wp wclient;

status_t lstatus;

{

//假设我们找到了对应的线程

mutex::autolock _l(mlock);

playbackthread *thread = checkplaybackthread_l(output);

//晕，调用这个线程对象的createtrack_l

track = thread->createtrack_l(client, streamtype, samplerate, format,

channelcount, framecount, sharedbuffer, &lstatus);

}

trackhandle = new trackhandle(track);

return trackhandle；----》注意，这个对象是最终返回到at进程中的。

实在是....太绕了。再进去看看thread->createtrack_l吧。_l的意思是这个函数进入之前已经获得同步锁了。

跟着sourceinsight ctrl+鼠标左键就进入到下面这个函数。

下面这个函数的签名好长啊。这是为何？

原来android的c++类中大量定义了内部类。说实话，我之前几年的c++的经验中基本没接触过这么频繁使用内部类的东东。--->当然，你可以说stl也大量使用了呀。

我们就把c++的内部类当做普通的类一样看待吧，其实我感觉也没什么特殊的含义，和外部类是一样的，包括函数调用，public/private之类的东西。这个和java的内部类是大不一样的。

sp<:playbackthread::track>audioflinger::playbackthread::createtrack_l(

const sp<:client>& client,

int streamtype,

uint32_t samplerate,

int format,

int channelcount,

int framecount,

const sp& sharedbuffer,

status_t *status)

{

sp track;

status_t lstatus;

{ // scope for mlock

mutex::autolock _l(mlock);

//new一个track对象

//我有点愤怒了，android真是层层封装啊，名字取得也非常相似。

//看看这个参数吧，注意sharedbuffer这个，此时的值应是0

track = new track(this, client, streamtype, samplerate, format,

channelcount, framecount, sharedbuffer);

mtracks.add(track); //把这个track加入到数组中，是为了管理用的。

}

lstatus = no_error;

return track;

}

看到这个数组的存在，我们应该能想到什么吗？这时已经有：

l一个mixerthread，内部有一个数组保存track的

看来，不管有多少个audiotrack，最终在af端都有一个track对象对应，而且这些所有的track对象都会由一个线程对象来处理。----难怪是mixer啊

再去看看new track，我们一直还没找到共享内存在哪里创建的！！！

audioflinger::playbackthread::track::track(

const wp& thread,

const sp& client,

int streamtype,

uint32_t samplerate,

int format,

int channelcount,

int framecount,

const sp& sharedbuffer)

:trackbase(thread, client, samplerate, format, channelcount, framecount, 0, sharedbuffer),

mmute(false), msharedbuffer(sharedbuffer), mname(-1)

{

// mcblk !=null什么时候创建的？？

//只能看基类trackbase，还是很愤怒，太多继承了。

if (mcblk != null) {

mvolume[0] = 1.0f;

mvolume[1] = 1.0f;

mstreamtype = streamtype;

mcblk->framesize = audiosystem::islinearpcm(format) channelcount *

sizeof(int16_t) : sizeof(int8_t);

}

}

看看基类trackbase干嘛了

audioflinger::threadbase::trackbase::trackbase(

const wp& thread,

const sp& client,

uint32_t samplerate,

int format,

int channelcount,

int framecount,

uint32_t flags,

const sp& sharedbuffer)

:refbase(),

mthread(thread),

mclient(client),

mcblk(0),

mframecount(0),

mstate(idle),

mclienttid(-1),

mformat(format),

mflags(flags & ~system_flags_mask)

{

size_t size = sizeof(audio_track_cblk_t);

size_t buffersize = framecount*channelcount*sizeof(int16_t);

if (sharedbuffer == 0) {

size += buffersize;

}

//调用client的allocate函数。这个client是什么？就是我们在createtrack中创建的

那个client，我不想再说了。反正这里会创建一块共享内存

mcblkmemory = client->heap()->allocate(size);

有了共享内存，但是还没有里边有同步锁的那个对象audio_track_cblk_t

mcblk = static_cast(mcblkmemory->pointer());

下面这个语法好怪啊。什么意思？？？

new(mcblk) audio_track_cblk_t();

//各位，这就是c++语法中的placement new。干啥用的啊new后面的括号中是一块buffer，再

后面是一个类的构造函数。对了，这个placement new的意思就是在这块buffer中构造一个对象。

我们之前的普通new是没法让一个对象在某块指定的内存中创建的。而placement new却可以。

这样不就达到我们的目的了吗？搞一块共享内存，再在这块内存上创建一个对象。这样，这个对象不也就能在两个内存*享了吗？太牛牛牛牛牛了。怎么想到的？

// clear all buffers

mcblk->framecount = framecount;

mcblk->samplerate = samplerate;

mcblk->channels = (uint8_t)channelcount;

}

好了，解决一个重大疑惑，跨进程数据共享的重要数据结构audio_track_cblk_t是通过placement new在一块共享内存上来创建的。

回到af的createtrack，有这么一句话：

trackhandle = new trackhandle(track);

return trackhandle；----》注意，这个对象是最终返回到at进程中的。

trackhandle的构造使用了thread->createtrack_l的返回值。

2.4到底有少种对象

读到这里的人，一定会被异常多的class类型，内部类，继承关系搞疯掉。说实话，这里废点心血整个或者paste一个大的uml图未尝不可。但是我是不太习惯用图说话，因为图我实在是记不住。那好吧。我们就用最简单的话语争取把目前出现的对象说清楚。

1 audioflinger

class audioflinger : public bnaudioflinger, public ibinder::deathrecipient

audioflinger类是代表整个audioflinger服务的类，其余所有的工作类都是通过内部类的方式在其中定义的。你把它当做一个壳子也行吧。

2 client

client是描述c/s结构的c端的代表，也就算是一个at在af端的对等物吧。不过可不是binder机制中的bpxxx喔。因为af是用不到at的功能的。

class client : public refbase {

public:

spmaudioflinger;//代表s端的audioflinger

spmmemorydealer;//每个c端使用的共享内存，通过它分配

pid_tmpid;//c端的进程id

};

3 trackhandle

trackhandle是at端调用af的createtrack得到的一个基于binder机制的track。

这个trackhandle实际上是对真正干活的playbackthread::track的一个跨进程支持的封装。

什么意思？本来playbackthread::track是真正在af中干活的东西，不过为了支持跨进程的话，我们用trackhandle对其进行了一下包转。这样在audiotrack调用trackhandle的功能，实际都由trackhandle调用playbackthread::track来完成了。可以认为是一种proxy模式吧。

这个就是audioflinger异常复杂的一个原因！！！

class trackhandle : public android::bnaudiotrack {

public:

trackhandle(const sp<:track>& track);

virtual~trackhandle();

virtual status_tstart();

virtual voidstop();

virtual voidflush();

virtual voidmute(bool);

virtual voidpause();

virtual voidsetvolume(float left, float right);

virtual sp getcblk() const;

sp<:track> mtrack;

};

4线程类

af中有好几种不同类型的线程，分别有对应的线程类型：

lrecordthread：

recordthread : public threadbase, public audiobufferprovider

用于录音的线程。

lplaybackthread:

class playbackthread : public threadbase

用于播放的线程

lmixerthread

mixerthread : public playbackthread

用于混音的线程，注意他是从playbackthread派生下来的。

ldirectoutputthread

directoutputthread : public playbackthread

直接输出线程，我们之前在代码里老看到direct_output之类的判断，看来最终和这个线程有关。

lduplicatingthread：

duplicatingthread : public mixerthread

复制线程？而且从混音线程中派生？暂时不知道有什么用

这么多线程，都有一个共同的父类threadbase，这个是af对audio系统单独定义的一个以thread为基类的类。------》ft，真的很麻烦。

threadbase我们不说了，反正里边封装了一些有用的函数。

我们看看playingthread吧，里边由定义了内部类：

5playingthread的内部类track

我们知道，trackhandle构造用的那个track是playingthread的createtrack_l得到的。

class track : public trackbase

晕喔，又来一个trackbase。

trackbase是threadbase定义的内部类

class trackbase : public audiobufferprovider, public refbase

基类audiobufferprovider是一个对buffer的封装，以后在af读共享缓冲，写数据到硬件hal中用得到。

个人感觉：上面这些东西，其实完完全全可以独立到不同的文件中，然后加一些注释说明。

写这样的代码，要是我是boss的话，一定会很不爽。有什么意义吗？有什么好处吗？

2.5 af流程继续

好了，这里终于在af中的createtrack返回了trackhandle。这个时候系统处于什么状态？

laf中的几个thread我们之前说了，在af启动的某个时间就已经起来了。我们就假设at调用af服务前，这个线程就已经启动了。

这个可以看代码就知道了：

void audioflinger::playbackthread::onfirstref()

{

const size_t size = 256;

char buffer[size];

snprintf(buffer, size, "playback thread %p", this);

//onfirstref，实际是refbase的一个方法，在构造sp的时候就会被调用

//下面的run就真正创建了线程并开始执行threadloop了

run(buffer, android_priority_urgent_audio);

}

到底执行哪个线程的threadloop？我记得我们是根据output句柄来查找线程的。

看看openoutput的实行，真正的线程对象创建是在那儿。

nt audioflinger::openoutput(uint32_t *pdevices,

uint32_t *psamplingrate,

uint32_t *pformat,

uint32_t *pchannels,

uint32_t *platencyms,

uint32_t flags)

{

if ((flags & audiosystem::output_flag_direct) ||

(format != audiosystem::pcm_16_bit) ||

(channels != audiosystem::channel_out_stereo)) {

thread = new directoutputthread(this, output, ++mnextthreadid);

//如果flags没有设置直接输出标准，或者format不是16bit，或者声道数不是2立体声

//则创建directoutputthread。

} else {

//可惜啊，我们创建的是最复杂的mixerthread

thread = new mixerthread(this, output, ++mnextthreadid);

1. mixerthread

非常重要的工作线程，我们看看它的构造函数。

audioflinger::mixerthread::mixerthread(const sp& audioflinger, audiostreamout* output, int id)

:playbackthread(audioflinger, output, id),

maudiomixer(0)

{

mtype = playbackthread::mixer;

//混音器对象，传进去的两个参数时基类threadbase的，都为0

//这个对象巨复杂，最终混音的数据都由它生成，以后再说...

maudiomixer = new audiomixer(mframecount, msamplerate);

}

2. at调用start

此时，at得到iaudiotrack对象后，调用start函数。

status_t audioflinger::trackhandle::start() {

return mtrack->start();

} //果然，自己又不干活，交给mtrack了，这个是playintthread createtrack_l得到的track对象

status_t audio