Android深入浅出之Audio 第一部分 AudioTrack分析
http://www.cnblogs.com/innost/archive/2011/01/09/1931457.html
Android深入浅出之Audio 第二部分 AudioFlinger分析
http://www.cnblogs.com/innost/archive/2011/01/15/1936425.html
Android深入浅出之Audio第三部分Audio Policy[1]
http://www.cnblogs.com/innost/archive/2011/01/22/1942149.html
Android深入浅出之Audio
第一部分 AudioTrack分析
一 目的
本文的目的是通过从Audio系统来分析Android的代码,包括Android自定义的那套机制和一些常见类的使用,比如Thread,MemoryBase等。
分析的流程是:
l 先从API层对应的某个类开始,用户层先要有一个简单的使用流程。
l 根据这个流程,一步步进入到JNI,服务层。在此过程中,碰到不熟悉或者第一次见到的类或者方法,都会解释。也就是深度优先的方法。
分析工具很简单,就是sourceinsight和android的API doc文档。当然还得有android的源代码。我这里是基于froyo的源码。
注意,froyo源码太多了,不要一股脑的加入到sourceinsight中,只要把framwork目录下的源码加进去就可以了,后续如要用的话,再加别的目录。
二 Audio系统
先看看Audio里边有哪些东西?通过Android的SDK文档,发现主要有三个:
l AudioManager:这个主要是用来管理Audio系统的
l AudioTrack:这个主要是用来播放声音的
l AudioRecord:这个主要是用来录音的
其中AudioManager的理解需要考虑整个系统上声音的策略问题,例如来电话铃声,短信铃声等,主要是策略上的问题。一般看来,最简单的就是播放声音了。所以我们打算从AudioTrack开始分析。
三 AudioTrack(JAVA层)
JAVA的AudioTrack类的代码在:
framework\base\media\java\android\media\AudioTrack.java中。
先看看使用例子,然后跟进去分析。至于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将系统的声音分为以下几类常见的(未写全):
l STREAM_ALARM:警告声
l STREAM_MUSCI:音乐声,例如music等
l STREAM_RING:铃声
l STREAM_SYSTEM:系统声音
l STREAM_VOCIE_CALL:电话声音
为什么要分这么多呢?以前在台式机上开发的时候很少知道有这么多的声音类型,不过仔细思考下,发现这样做是有道理的。例如你在听music的时候接到电话,这个时候music播放肯定会停止,此时你只能听到电话,如果你调节音量的话,这个调节肯定只对电话起作用。当电话打完了,再回到music,你肯定不用再调节音量了。
其实系统将这几种声音的数据分开管理,所以,这个参数对AudioTrack来说,它的含义就是告诉系统,我现在想使用的是哪种类型的声音,这样系统就可以对应管理他们了。
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对象了
先看看调用函数:
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<AudioTrack>(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 {
jclass audioTrack_class;
jobject audioTrack_ref;
}; cookie其实就是把JAVA中的一些东西保存了下,没什么特别的意义
class AudioTrackJniStorage {
public:
sp<MemoryHeapBase> mMemHeap;//这两个Memory很重要
sp<MemoryBase> mMemBase;
audiotrack_callback_cookie mCallbackData;
int mStreamType;
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机制不了解的,可以参考:
http://blog.csdn.net/Innost/archive/2011/01/08/6124685.aspx
有好几个构造函数,我们看看我们使用的:
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<IMemoryHeap>& heap, ssize_t offset, size_t size);
virtual sp<IMemoryHeap> getMemory(ssize_t* offset, size_t* size) const;
protected:
size_t getSize() const { return mSize; }
ssize_t getOffset() const { return mOffset; }
const sp<IMemoryHeap>& getHeap() const { return mHeap; }
};
好了,明白上面两个MemoryXXX,我们可以猜测下大概的使用方法了。
l BnXXX端先分配BnMemoryHeapBase和BnMemoryBase,
l 然后把BnMemoryBase传递到BpXXX
l BpXXX就可以使用BpMemoryBase得到BnXXX端分配的共享内存了。
注意,既然是进程间共享内存,那么Bp端肯定使用memcpy之类的函数来操作内存,这些函数是没有同步保护的,而且Android也不可能在系统内部为这种共享内存去做增加同步保护。所以看来后续在操作这些共享内存的时候,肯定存在一个跨进程的同步保护机制。我们在后面讲实际播放的时候会碰到。
另外,这里的SharedBuffer最终会在Bp端也就是AudioFlinger那用到。
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层,有以下几个步骤:
l new了一个AudioTrack
l 调用set函数,把AudioTrackJniStorage等信息传进去
l 调用了AudioTrack的start函数
l 调用AudioTrack的write函数
那么,我们就看看真正干活的的C++AudioTrack吧。
AudioTrack.cpp位于framework\base\libmedia\AudioTrack.cpp
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<IMemory>& 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<IMemory>& sharedBuffer,
audio_io_handle_t output)
{
status_t status;
//啊,看来和audioFlinger挂上关系了呀。
const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger();
//下面这个调用最终会在AudioFlinger中出现。暂时不管它。
sp<IAudioTrack> track = audioFlinger->createTrack(getpid(),
streamType,
sampleRate,
format,
channelCount,
frameCount,
((uint16_t)flags) << 16,
sharedBuffer,
output,
&status);
//看见没,从track也就是AudioFlinger那边得到一个IMemory接口
//这个看来就是最终write写入的地方
sp<IMemory> cblk = track->getCblk();
mAudioTrack.clear();
mAudioTrack = track;
mCblkMemory.clear();//sp<XXX>的clear,就看着做是delete XXX吧
mCblkMemory = cblk;
mCblk = static_cast<audio_track_cblk_t*>(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)
{
}
到这里,大家应该都有个大概的全景了。
l AudioTrack得到AudioFlinger中的一个IAudioTrack对象,这里边有一个很重要的数据结构audio_track_cblk_t,它包括一块缓冲区地址,包括一些进程间同步的内容,可能还有数据位置等内容
l AudioTrack启动了一个线程,叫AudioTrackThread,这个线程干嘛的呢?还不知道
l AudioTrack调用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<AudioTrackThread> 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<AudioTrackThread>& 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吧。
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总结
通过这一次的分析,我自己觉得有以下几个点:
l AudioTrack的工作原理,尤其是数据的传递这一块,做了比较细致的分析,包括共享内存,跨进程的同步等,也能解释不少疑惑了。
l 看起来,最重要的工作是在AudioFlinger中做的。通过AudioTrack的介绍,我们给后续深入分析AudioFlinger提供了一个切入点
工作原理和流程嘛,再说一次好了,JAVA层就看最前面那个例子吧,实在没什么说的。
l AudioTrack被new出来,然后set了一堆信息,同时会通过Binder机制调用另外一端的AudioFlinger,得到IAudioTrack对象,通过它和AudioFlinger交互。
l 调用start函数后,会启动一个线程专门做回调处理,代码里边也会有那种数据拷贝的回调,但是JNI层的回调函数实际并没有往里边写数据,大家只要看write就可以了
l 用户一次次得write,那AudioTrack无非就是把数据memcpy到共享buffer中咯
l 可想而知,AudioFlinger那一定有一个线程在memcpy数据到音频设备中去。我们拭目以待。
一目的
本文承接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架构的服务者是如何产生的呢?
AF是一个服务,这个就不用我多说了吧?代码在
framework/base/media/mediaserver/Main_mediaServer.cpp中。
int main(int argc, char** argv)
{
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> 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也准备好硬件了。不过,创建硬件对象就代表我们可以播放了吗?
我这里简单的把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<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger();
//下面很重要,调用AF的createTrack获得一个IAudioTrack对象
sp<IAudioTrack> track = audioFlinger->createTrack();
sp<IMemory> 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的流程了。下面一个一个看。
1 createTrack
sp<IAudioTrack> 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<IMemory>& sharedBuffer,//AT传入的共享buffer,这里为空
int output,//这个是从AuidoSystem获得的对应MUSIC流类型的索引
status_t *status)
{
sp<PlaybackThread::Track> track;
sp<TrackHandle> trackHandle;
sp<Client> client;
wp<Client> 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;
}
看到这里很疑惑啊:
l AF的构造函数中没有创建线程,只创建了一个audio的HAL对象
l 如果AT是AF的第一个客户的话,我们刚才的调用流程里边,也没看到哪有创建线程的地方呀。
l output是个什么玩意儿?为什么会根据它作为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<IAudioPolicyService>& 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<IAudioFlinger> 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的句柄
l AS的getOutput会调用AudioPolicyService的getOutput
l 然后我们就没继续讲APS的getOutPut了,而是去看看APS创建的东西
l 发现APS创建的时候会创建一个AudioManagerBase,这个AMB的创建又会调用APS的openOutput。
l APS的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<IMemory>& sharedBuffer,
int output,
status_t *status)
{
sp<PlaybackThread::Track> track;
sp<TrackHandle> trackHandle;
sp<Client> client;
wp<Client> 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<AudioFlinger::PlaybackThread::Track> AudioFlinger::PlaybackThread::createTrack_l(
const sp<AudioFlinger::Client>& client,
int streamType,
uint32_t sampleRate,
int format,
int channelCount,
int frameCount,
const sp<IMemory>& sharedBuffer,
status_t *status)
{
sp<Track> 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<ThreadBase>& thread,
const sp<Client>& client,
int streamType,
uint32_t sampleRate,
int format,
int channelCount,
int frameCount,
const sp<IMemory>& 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<ThreadBase>& thread,
const sp<Client>& client,
uint32_t sampleRate,
int format,
int channelCount,
int frameCount,
uint32_t flags,
const sp<IMemory>& 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<audio_track_cblk_t *>(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的返回值。
读到这里的人,一定会被异常多的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:
sp<AudioFlinger> mAudioFlinger;//代表S端的AudioFlinger
sp<MemoryDealer> mMemoryDealer;//每个C端使用的共享内存,通过它分配
pid_t mPid;//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<PlaybackThread::Track>& track);
virtual ~TrackHandle();
virtual status_t start();
virtual void stop();
virtual void flush();
virtual void mute(bool);
virtual void pause();
virtual void setVolume(float left, float right);
virtual sp<IMemory> getCblk() const;
sp<PlaybackThread::Track> mTrack;
};
4 线程类
AF中有好几种不同类型的线程,分别有对应的线程类型:
l RecordThread:
RecordThread : public ThreadBase, public AudioBufferProvider
用于录音的线程。
l PlaybackThread:
class PlaybackThread : public ThreadBase
用于播放的线程
l MixerThread
MixerThread : public PlaybackThread
用于混音的线程,注意他是从PlaybackThread派生下来的。
l DirectoutputThread
DirectOutputThread : public PlaybackThread
直接输出线程,我们之前在代码里老看到DIRECT_OUTPUT之类的判断,看来最终和这个线程有关。
l DuplicatingThread:
DuplicatingThread : public MixerThread
复制线程?而且从混音线程中派生?暂时不知道有什么用
这么多线程,都有一个共同的父类ThreadBase,这个是AF对Audio系统单独定义的一个以Thread为基类的类。------》FT,真的很麻烦。
ThreadBase我们不说了,反正里边封装了一些有用的函数。
我们看看PlayingThread吧,里边由定义了内部类:
5 PlayingThread的内部类Track
我们知道,TrackHandle构造用的那个Track是PlayingThread的createTrack_l得到的。
class Track : public TrackBase
晕喔,又来一个TrackBase。
TrackBase是ThreadBase定义的内部类
class TrackBase : public AudioBufferProvider, public RefBase
基类AudioBufferProvider是一个对Buffer的封装,以后在AF读共享缓冲,写数据到硬件HAL中用得到。
个人感觉:上面这些东西,其实完完全全可以独立到不同的文件中,然后加一些注释说明。
写这样的代码,要是我是BOSS的话,一定会很不爽。有什么意义吗?有什么好处吗?
好了,这里终于在AF中的createTrack返回了TrackHandle。这个时候系统处于什么状态?
l AF中的几个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>& 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 AudioFlinger::PlaybackThread::Track::start()
{
status_t status = NO_ERROR;
sp<ThreadBase> thread = mThread.promote();
//这个Thread就是调用createTrack_l的那个thread对象,这里是MixerThread
if (thread != 0) {
Mutex::Autolock _l(thread->mLock);
int state = mState;
if (mState == PAUSED) {
mState = TrackBase::RESUMING;
} else {
mState = TrackBase::ACTIVE;
}
//把自己由加到addTrack_l了
//奇怪,我们之前在看createTrack_l的时候,不是已经有个map保存创建的track了
//这里怎么又出现了一个类似的操作?
PlaybackThread *playbackThread = (PlaybackThread *)thread.get();
playbackThread->addTrack_l(this);
return status;
}
看看这个addTrack_l函数
status_t AudioFlinger::PlaybackThread::addTrack_l(const sp<Track>& track)
{
status_t status = ALREADY_EXISTS;
// set retry count for buffer fill
track->mRetryCount = kMaxTrackStartupRetries;
if (mActiveTracks.indexOf(track) < 0) {
mActiveTracks.add(track);//啊,原来是加入到活跃Track的数组啊
status = NO_ERROR;
}
//我靠,有戏啊!看到这个broadcast,一定要想到:恩,在不远处有那么一个线程正
//等着这个CV呢。
mWaitWorkCV.broadcast();
return status;
}
让我们想想吧。start是把某个track加入到PlayingThread的活跃Track队列,然后触发一个信号事件。由于这个事件是PlayingThread的内部成员变量,而PlayingThread又创建了一个线程,那么难道是那个线程在等待这个事件吗?这时候有一个活跃track,那个线程应该可以干活了吧?
这个线程是MixerThread。我们去看看它的线程函数threadLoop吧。
bool AudioFlinger::MixerThread::threadLoop()
{
int16_t* curBuf = mMixBuffer;
Vector< sp<Track> > tracksToRemove;
while (!exitPending())
{
processConfigEvents();
//Mixer进到这个循环中来
mixerStatus = MIXER_IDLE;
{ // scope for mLock
Mutex::Autolock _l(mLock);
const SortedVector< wp<Track> >& activeTracks = mActiveTracks;
//每次都取当前最新的活跃Track数组
//下面是预备操作,返回状态看看是否有数据需要获取
mixerStatus = prepareTracks_l(activeTracks, &tracksToRemove);
}
//LIKELY,是GCC的一个东西,可以优化编译后的代码
//就当做是TRUE吧
if (LIKELY(mixerStatus == MIXER_TRACKS_READY)) {
// mix buffers...
//调用混音器,把buf传进去,估计得到了混音后的数据了
//curBuf是mMixBuffer,PlayingThread的内部buffer,在某个地方已经创建好了,
//缓存足够大
mAudioMixer->process(curBuf);
sleepTime = 0;
standbyTime = systemTime() + kStandbyTimeInNsecs;
}
有数据要写到硬件中,肯定不能sleep了呀
if (sleepTime == 0) {
//把缓存的数据写到outPut中。这个mOutput是AudioStreamOut
//由Audio HAL的那个对象创建得到。等我们以后分析再说
int bytesWritten = (int)mOutput->write(curBuf, mixBufferSize);
mStandby = false;
} else {
usleep(sleepTime);//如果没有数据,那就休息吧..
}
3. MixerThread核心
到这里,大家是不是有种焕然一新的感觉?恩,对了,AF的工作就是如此的精密,每个部分都配合得丝丝入扣。不过对于我们看代码的人来说,实在搞不懂这么做的好处----哈哈 有点扯远了。
MixerThread的线程循环中,最重要的两个函数:
prepare_l和mAudioMixer->process,我们一一来看看。
uint32_t AudioFlinger::MixerThread::prepareTracks_l(const SortedVector< wp<Track> >& activeTracks, Vector< sp<Track> > *tracksToRemove)
{
uint32_t mixerStatus = MIXER_IDLE;
//得到活跃track个数,这里假设就是我们创建的那个AT吧,那么count=1
size_t count = activeTracks.size();
float masterVolume = mMasterVolume;
bool masterMute = mMasterMute;
for (size_t i=0 ; i<count ; i++) {
sp<Track> t = activeTracks[i].promote();
Track* const track = t.get();
//得到placement new分配的那个跨进程共享的对象
audio_track_cblk_t* cblk = track->cblk();
//设置混音器,当前活跃的track。
mAudioMixer->setActiveTrack(track->name());
if (cblk->framesReady() && (track->isReady() || track->isStopped()) &&
!track->isPaused() && !track->isTerminated())
{
// compute volume for this track
//AT已经write数据了。所以肯定会进到这来。
int16_t left, right;
if (track->isMuted() || masterMute || track->isPausing() ||
mStreamTypes[track->type()].mute) {
left = right = 0;
if (track->isPausing()) {
track->setPaused();
}
//AT设置的音量假设不为零,我们需要聆听声音!
//所以走else流程
} else {
// read original volumes with volume control
float typeVolume = mStreamTypes[track->type()].volume;
float v = masterVolume * typeVolume;
float v_clamped = v * cblk->volume[0];
if (v_clamped > MAX_GAIN) v_clamped = MAX_GAIN;
left = int16_t(v_clamped);
v_clamped = v * cblk->volume[1];
if (v_clamped > MAX_GAIN) v_clamped = MAX_GAIN;
right = int16_t(v_clamped);
//计算音量
}
//注意,这里对混音器设置了数据提供来源,是一个track,还记得我们前面说的吗?Track从
AudioBufferProvider派生
mAudioMixer->setBufferProvider(track);
mAudioMixer->enable(AudioMixer::MIXING);
int param = AudioMixer::VOLUME;
//为这个track设置左右音量等
mAudioMixer->setParameter(param, AudioMixer::VOLUME0, left);
mAudioMixer->setParameter(param, AudioMixer::VOLUME1, right);
mAudioMixer->setParameter(
AudioMixer::TRACK,
AudioMixer::FORMAT, track->format());
mAudioMixer->setParameter(
AudioMixer::TRACK,
AudioMixer::CHANNEL_COUNT, track->channelCount());
mAudioMixer->setParameter(
AudioMixer::RESAMPLE,
AudioMixer::SAMPLE_RATE,
int(cblk->sampleRate));
} else {
if (track->isStopped()) {
track->reset();
}
//如果这个track已经停止了,那么把它加到需要移除的track队列tracksToRemove中去
//同时停止它在AudioMixer中的混音
if (track->isTerminated() || track->isStopped() || track->isPaused()) {
tracksToRemove->add(track);
mAudioMixer->disable(AudioMixer::MIXING);
} else {
mAudioMixer->disable(AudioMixer::MIXING);
}
}
}
// remove all the tracks that need to be...
count = tracksToRemove->size();
return mixerStatus;
}
看明白了吗?prepare_l的功能是什么?根据当前活跃的track队列,来为混音器设置信息。可想而知,一个track必然在混音器中有一个对应的东西。我们待会分析AudioMixer的时候再详述。
为混音器准备好后,下面调用它的process函数
void AudioMixer::process(void* output)
{
mState.hook(&mState, output);//hook?难道是钩子函数?
}
晕乎,就这么简单的函数???
CTRL+左键,hook是一个函数指针啊,在哪里赋值的?具体实现函数又是哪个?
没办法了,只能分析AudioMixer类了。
4. AudioMixer
AudioMixer实现在framework/base/libs/audioflinger/AudioMixer.cpp中
AudioMixer::AudioMixer(size_t frameCount, uint32_t sampleRate)
: mActiveTrack(0), mTrackNames(0), mSampleRate(sampleRate)
{
mState.enabledTracks= 0;
mState.needsChanged = 0;
mState.frameCount = frameCount;
mState.outputTemp = 0;
mState.resampleTemp = 0;
mState.hook = process__nop;//process__nop,是该类的静态函数
track_t* t = mState.tracks;
//支持32路混音。牛死了
for (int i=0 ; i<32 ; i++) {
t->needs = 0;
t->volume[0] = UNITY_GAIN;
t->volume[1] = UNITY_GAIN;
t->volumeInc[0] = 0;
t->volumeInc[1] = 0;
t->channelCount = 2;
t->enabled = 0;
t->format = 16;
t->buffer.raw = 0;
t->bufferProvider = 0;
t->hook = 0;
t->resampler = 0;
t->sampleRate = mSampleRate;
t->in = 0;
t++;
}
}
//其中,mState是在AudioMixer.h中定义的一个数据结构
//注意,source insight没办法解析这个mState,因为....见下面的注释。
struct state_t {
uint32_t enabledTracks;
uint32_t needsChanged;
size_t frameCount;
mix_t hook;
int32_t *outputTemp;
int32_t *resampleTemp;
int32_t reserved[2];
track_t tracks[32];// __attribute__((aligned(32)));《--把这里注释掉
//否则source insight会解析不了这个state_t类型
};
int mActiveTrack;
uint32_t mTrackNames;//names?搞得像字符串,实际是一个int
const uint32_t mSampleRate;
state_t mState
好了,没什么吗。hook对应的可选函数实现有:
process__validate
process__nop
process__genericNoResampling
process__genericResampling
process__OneTrack16BitsStereoNoResampling
process__TwoTracks16BitsStereoNoResampling
AudioMixer构造的时候,hook是process__nop,有几个地方会改变这个函数指针的指向。
这部分涉及到数字音频技术,我就无力讲解了。我们看看最接近的函数
process__OneTrack16BitsStereoNoResampling
void AudioMixer::process__OneTrack16BitsStereoNoResampling(state_t* state, void* output)
{
单track,16bit双声道,不需要重采样,大部分是这种情况了
const int i = 31 - __builtin_clz(state->enabledTracks);
const track_t& t = state->tracks[i];
AudioBufferProvider::Buffer& b(t.buffer);
int32_t* out = static_cast<int32_t*>(output);
size_t numFrames = state->frameCount;
const int16_t vl = t.volume[0];
const int16_t vr = t.volume[1];
const uint32_t vrl = t.volumeRL;
while (numFrames) {
b.frameCount = numFrames;
//获得buffer
t.bufferProvider->getNextBuffer(&b);
int16_t const *in = b.i16;
size_t outFrames = b.frameCount;
if UNLIKELY--->不走这.
else {
do {
//计算音量等数据,和数字音频技术有关。这里不说了
uint32_t rl = *reinterpret_cast<uint32_t const *>(in);
in += 2;
int32_t l = mulRL(1, rl, vrl) >> 12;
int32_t r = mulRL(0, rl, vrl) >> 12;
*out++ = (r<<16) | (l & 0xFFFF);
} while (--outFrames);
}
numFrames -= b.frameCount;
//释放buffer。
t.bufferProvider->releaseBuffer(&b);
}
}
好像挺简单的啊,不就是把数据处理下嘛。这里注意下buffer。到现在,我们还没看到取共享内存里AT端write的数据呐。
那只能到bufferProvider去看了。
注意,这里用的是AudioBufferProvider基类,实际的对象是Track。它从AudioBufferProvider派生。
我们用得是PlaybackThread的这个Track
status_t AudioFlinger::PlaybackThread::Track::getNextBuffer(AudioBufferProvider::Buffer* buffer)
{
//一阵暗喜吧。千呼万唤始出来,终于见到cblk了
audio_track_cblk_t* cblk = this->cblk();
uint32_t framesReady;
uint32_t framesReq = buffer->frameCount;
//哈哈,看看数据准备好了没,
framesReady = cblk->framesReady();
if (LIKELY(framesReady)) {
uint32_t s = cblk->server;
uint32_t bufferEnd = cblk->serverBase + cblk->frameCount;
bufferEnd = (cblk->loopEnd < bufferEnd) ? cblk->loopEnd : bufferEnd;
if (framesReq > framesReady) {
framesReq = framesReady;
}
if (s + framesReq > bufferEnd) {
framesReq = bufferEnd - s;
}
获得真实的数据地址
buffer->raw = getBuffer(s, framesReq);
if (buffer->raw == 0) goto getNextBuffer_exit;
buffer->frameCount = framesReq;
return NO_ERROR;
}
getNextBuffer_exit:
buffer->raw = 0;
buffer->frameCount = 0;
return NOT_ENOUGH_DATA;
}
再看看释放缓冲的地方:releaseBuffer,这个直接在ThreadBase中实现了
void AudioFlinger::ThreadBase::TrackBase::releaseBuffer(AudioBufferProvider::Buffer* buffer)
{
buffer->raw = 0;
mFrameCount = buffer->frameCount;
step();
buffer->frameCount = 0;
}
看看step吧。mFrameCount表示我已经用完了这么多帧。
bool AudioFlinger::ThreadBase::TrackBase::step() {
bool result;
audio_track_cblk_t* cblk = this->cblk();
result = cblk->stepServer(mFrameCount);//哼哼,调用cblk的stepServer,更新
服务端的使用位置
return result;
}
到这里,大伙应该都明白了吧。原来AudioTrack中write的数据,最终是这么被使用的呀!!!
恩,看一个process__OneTrack16BitsStereoNoResampling不过瘾,再看看
process__TwoTracks16BitsStereoNoResampling。
void AudioMixer::process__TwoTracks16BitsStereoNoResampling(state_t* state, void*
output)
int i;
uint32_t en = state->enabledTracks;
i = 31 - __builtin_clz(en);
const track_t& t0 = state->tracks[i];
AudioBufferProvider::Buffer& b0(t0.buffer);
en &= ~(1<<i);
i = 31 - __builtin_clz(en);
const track_t& t1 = state->tracks[i];
AudioBufferProvider::Buffer& b1(t1.buffer);
int16_t const *in0;
const int16_t vl0 = t0.volume[0];
const int16_t vr0 = t0.volume[1];
size_t frameCount0 = 0;
int16_t const *in1;
const int16_t vl1 = t1.volume[0];
const int16_t vr1 = t1.volume[1];
size_t frameCount1 = 0;
int32_t* out = static_cast<int32_t*>(output);
size_t numFrames = state->frameCount;
int16_t const *buff = NULL;
while (numFrames) {
if (frameCount0 == 0) {
b0.frameCount = numFrames;
t0.bufferProvider->getNextBuffer(&b0);
if (b0.i16 == NULL) {
if (buff == NULL) {
buff = new int16_t[MAX_NUM_CHANNELS * state->frameCount];
}
in0 = buff;
b0.frameCount = numFrames;
} else {
in0 = b0.i16;
}
frameCount0 = b0.frameCount;
}
if (frameCount1 == 0) {
b1.frameCount = numFrames;
t1.bufferProvider->getNextBuffer(&b1);
if (b1.i16 == NULL) {
if (buff == NULL) {
buff = new int16_t[MAX_NUM_CHANNELS * state->frameCount];
}
in1 = buff;
b1.frameCount = numFrames;
} else {
in1 = b1.i16;
}
frameCount1 = b1.frameCount;
}
size_t outFrames = frameCount0 < frameCount1?frameCount0:frameCount1;
numFrames -= outFrames;
frameCount0 -= outFrames;
frameCount1 -= outFrames;
do {
int32_t l0 = *in0++;
int32_t r0 = *in0++;
l0 = mul(l0, vl0);
r0 = mul(r0, vr0);
int32_t l = *in1++;
int32_t r = *in1++;
l = mulAdd(l, vl1, l0) >> 12;
r = mulAdd(r, vr1, r0) >> 12;
// clamping...
l = clamp16(l);
r = clamp16(r);
*out++ = (r<<16) | (l & 0xFFFF);
} while (--outFrames);
if (frameCount0 == 0) {
t0.bufferProvider->releaseBuffer(&b0);
}
if (frameCount1 == 0) {
t1.bufferProvider->releaseBuffer(&b1);
}
}
if (buff != NULL) {
delete [] buff;
}
}
看不懂了吧??哈哈,知道有这回事就行了,专门搞数字音频的需要好好研究下了!
三再论共享audio_track_cblk_t
为什么要再论这个?因为我在网上找了下,有人说audio_track_cblk_t是一个环形buffer,环形buffer是什么意思?自己查查!
这个吗,和我之前的工作经历有关系,某BOSS费尽心机想搞一个牛掰掰的环形buffer,搞得我累死了。现在audio_track_cblk_t是环形buffer?我倒是想看看它是怎么实现的。
顺便我们要解释下,audio_track_cblk_t的使用和我之前说的Lock,读/写,Unlock不太一样。为何?
l 第一因为我们没在AF代码中看到有缓冲buffer方面的wait,MixThread只有当没有数据的时候会usleep一下。
l 第二,如果有多个track,多个audio_track_cblk_t的话,假如又是采用wait信号的办法,那么由于pthread库缺乏WaitForMultiObjects的机制,那么到底该等哪一个?这个问题是我们之前在做跨平台同步库的一个重要难题。
1. 写者的使用
我们集中到audio_track_cblk_t这个类,来看看写者是如何使用的。写者就是AudioTrack端,在这个类中,叫user
l framesAvailable,看看是否有空余空间
l buffer,获得写空间起始地址
l stepUser,更新user的位置。
2. 读者的使用
读者是AF端,在这个类中加server。
l framesReady,获得可读的位置
l stepServer,更新读者的位置
看看这个类的定义:
struct audio_track_cblk_t
{
Mutex lock; //同步锁
Condition cv;//CV
volatile uint32_t user;//写者
volatile uint32_t server;//读者
uint32_t userBase;//写者起始位置
uint32_t serverBase;//读者起始位置
void* buffers;
uint32_t frameCount;
// Cache line boundary
uint32_t loopStart; //循环起始
uint32_t loopEnd; //循环结束
int loopCount;
uint8_t out; //如果是Track的话,out就是1,表示输出。
}
注意这是volatile,跨进程的对象,看来这个volatile也是可以跨进程的嘛。
l 唉,又要发挥下了。volatile只是告诉编译器,这个单元的地址不要cache到CPU的缓冲中。也就是每次取值的时候都要到实际内存中去读,而且可能读内存的时候先要锁一下总线。防止其他CPU核执行的时候同时去修改。由于是跨进程共享的内存,这块内存在两个进程都是能见到的,又锁总线了,又是同一块内存,volatile当然保证了同步一致性。
l loopStart和loopEnd这两个值是表示循环播放的起点和终点的,下面还有一个loopCount吗,表示循环播放次数的
那就分析下吧。
先看写者的那几个函数
4 写者分析
先用frameavail看看当前剩余多少空间,我们可以假设是第一次进来嘛。读者还在那sleep呢。
uint32_t audio_track_cblk_t::framesAvailable()
{
Mutex::Autolock _l(lock);
return framesAvailable_l();
}
int32_t audio_track_cblk_t::framesAvailable_l()
{
uint32_t u = this->user; 当前写者位置,此时也为0
uint32_t s = this->server; //当前读者位置,此时为0
if (out) { out为1
uint32_t limit = (s < loopStart) ? s : loopStart;
我们不设循环播放时间吗。所以loopStart是初始值INT_MAX,所以limit=0
return limit + frameCount - u;
//返回0+frameCount-0,也就是全缓冲最大的空间。假设frameCount=1024帧
}
}
然后调用buffer获得其实位置,buffer就是得到一个地址位置。
void* audio_track_cblk_t::buffer(uint32_t offset) const
{
return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;
}
完了,我们更新写者,调用stepUser
uint32_t audio_track_cblk_t::stepUser(uint32_t frameCount)
{
//framecount,表示我写了多少,假设这一次写了512帧
uint32_t u = this->user;//user位置还没更新呢,此时u=0;
u += frameCount;//u更新了,u=512
// Ensure that user is never ahead of server for AudioRecord
if (out) {
//没甚,计算下等待时间
}
//userBase还是初始值为0,可惜啊,我们只写了1024的一半
//所以userBase加不了
if (u >= userBase + this->frameCount) {
userBase += this->frameCount;
//但是这句话很重要,userBase也更新了。根据buffer函数的实现来看,似乎把这个
//环形缓冲铺直了....连绵不绝。
}
this->user = u;//喔,user位置也更新为512了,但是useBase还是0
return u;
}
好了,假设写者这个时候sleep了,而读者起来了。
5 读者分析
uint32_t audio_track_cblk_t::framesReady()
{
uint32_t u = this->user; //u为512
uint32_t s = this->server;//还没读呢,s为零
if (out) {
if (u < loopEnd) {
return u - s;//loopEnd也是INT_MAX,所以这里返回512,表示有512帧可读了
} else {
Mutex::Autolock _l(lock);
if (loopCount >= 0) {
return (loopEnd - loopStart)*loopCount + u - s;
} else {
return UINT_MAX;
}
}
} else {
return s - u;
}
}
使用完了,然后stepServer
bool audio_track_cblk_t::stepServer(uint32_t frameCount)
{
status_t err;
err = lock.tryLock();
uint32_t s = this->server;
s += frameCount; //读了512帧了,所以s=512
if (out) {
}
没有设置循环播放嘛,所以不走这个
if (s >= loopEnd) {
s = loopStart;
if (--loopCount == 0) {
loopEnd = UINT_MAX;
loopStart = UINT_MAX;
}
}
//一样啊,把环形缓冲铺直了
if (s >= serverBase + this->frameCount) {
serverBase += this->frameCount;
}
this->server = s; //server为512了
cv.signal(); //读者读完了。触发下写者吧。
lock.unlock();
return true;
}
6 真的是环形缓冲吗?
环形缓冲是这样一个场景,现在buffer共1024帧。
假设:
l 写者先写到1024帧
l 读者读到512帧
l 那么,写者还可以从头写512帧。
所以,我们得回头看看frameavail是不是把这512帧算进来了。
uint32_t audio_track_cblk_t::framesAvailable_l()
{
uint32_t u = this->user; //1024
uint32_t s = this->server;//512
if (out) {
uint32_t limit = (s < loopStart) ? s : loopStart;
return limit + frameCount - u;返回512,用上了!
}
}
再看看stepUser这句话
if (u >= userBase + this->frameCount) {u为1024,userBase为0,frameCount为1024
userBase += this->frameCount;//好,userBase也为1024了
}
看看buffer
return (int8_t *)this->buffers + (offset - userBase) * this->frameSize;
//offset是外界传入的基于user的一个偏移量。offset-userBase,得到的正式从头开始的那段数据空间。太牛了!
一目的
上回我们说了AudioFlinger(AF),总感觉代码里边有好多东西没说清楚,心里发毛。就看了看AF的流程,我们敢说自己深入了解了Android系统吗?AudioPolicyService(APS)是个什么东西?为什么要有它的存在?下层的Audio HAL层又是怎么结合到Android中来的?更有甚者,问个实在问题:插入耳机后,声音又怎么从最开始的外放变成从耳机输出了?调节音量的时候到底是调节Music的还是调节来电音量呢?这些东西,我们在AF的流程中统统都没讲到。但是这些他们又是至关重要的。从我个人理解来看,策略(Policy)比流程更复杂和难懂。
当然,遵循我们的传统分析习惯,得有一个切入点,否则我们都不知道从何入手了。
这里的切入点将是:
l AF和APS系统第一次起来后,到底干了什么。
l 检测到耳机插入事件后,AF和APS的处理。
大家跟着我一步步来看,很快就发现,啊哈,APS也不是那么难嘛。
另外,这次代码分析的格式将参考《Linux内核情景分析》的样子,函数调用的解析将采用深度优先的办法,即先解释所调用的函数,然后再出来继续讲。
我曾经数度放弃分析APS,关键原因是我没找到切入点,只知道代码从头看到尾!
二 AF和APS的诞生
这个东西,已经说得太多了。在framework\base\media\MediaServer\Main_MediaServer中。
我们看看。
int main(int argc, char** argv)
{
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
//先创建AF
AudioFlinger::instantiate();
//再创建APS
AudioPolicyService::instantiate();
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
前面说过,instantiate内部会实例化一个对象,那直接看AF的构造函数。
AudioFlinger::AudioFlinger()
: BnAudioFlinger(),//基类构造函数
mAudioHardware(0), mMasterVolume(1.0f), mMasterMute(false), mNextThreadId(0)
{
注意mAudioHardware和mNextThreadId
mHardwareStatus = AUDIO_HW_IDLE;
//创建audio的HAL代表
mAudioHardware = AudioHardwareInterface::create();
mHardwareStatus = AUDIO_HW_INIT;
//下面这些不至于会使用APS吧?APS还没创建呢!
if (mAudioHardware->initCheck() == NO_ERROR) {
setMode(AudioSystem::MODE_NORMAL);
setMasterVolume(1.0f);
setMasterMute(false);
}
}
感觉上,AF的构造函数就是创建了一个最重要的AudioHardWare的HAL代表。
其他好像是没干什么策略上的事情。
不过:AF创建了一个AudioHardware的HAL对象。注意整个系统就这一个AudioHardware了。也就是说,不管是线控耳机,蓝牙耳机,麦克,外放等等,最后都会由这一个HAL统一管理。
再看APS吧。
AudioPolicyService::AudioPolicyService()
: BnAudioPolicyService() , mpPolicyManager(NULL)
{
// mpPolicyManager?策略管理器?可能很重要
char value[PROPERTY_VALUE_MAX];
// TonePlayback?播放铃声的?为什么放在这里?以后来看看
mTonePlaybackThread = new AudioCommandThread(String8(""));
// Audio Command?音频命令?看到Command,我就想到设计模式中的Command模式了
//Android尤其是MediaPlayerService中大量使用了这种模式。
mAudioCommandThread = new AudioCommandThread(String8("ApmCommandThread"));
#if (defined GENERIC_AUDIO) || (defined AUDIO_POLICY_TEST)
//注意AudioPolicyManagerBase的构造函数,把this传进去了。
mpPolicyManager = new AudioPolicyManagerBase(this);
//先假设我们使用Generic的Audio设备吧。
#else
...
#endif
// 根据系统属性来判断摄像机是否强制使用声音。这个...为什么会放在这里?
//手机带摄像机好像刚出来的时候,为了防止偷拍,强制按快门的时候必须发出声音
//就是这个目的吧?
property_get("ro.camera.sound.forced", value, "0");
mpPolicyManager->setSystemProperty("ro.camera.sound.forced", value);
}
so easy!,不至于吧?我们不应该放过任何一个疑问!这么多疑问,先看哪个呢?这里分析的是Audio Policy,而构造函数中又创建了一个AudioPolicyManagerBase,而且不同厂商还可以实现自己的AudioPolicyManager,看来这个对于音频策略有至关重要的作用了。
不得不说的是,Android代码中的这些命名在关键地方上还是比较慎重和准确的。
另外,AudioPolicyManagerBase的构造函数可是把APS传进去了,看来又会有一些回调靠APS了。真绕。
代码位置在framework\base\libs\audioflinger\AudioPolicyManagerBase.cpp中
AudioPolicyManagerBase::AudioPolicyManagerBase(AudioPolicyClientInterface *clientInterface)
:
mPhoneState(AudioSystem::MODE_NORMAL), ---->这里有电话的状态?
mRingerMode(0),
mMusicStopTime(0),
mLimitRingtoneVolume(false)
{
[--->mPhoneState(AudioSystem::MODE_NORMAL)]
AudioSystem其实是窥视Android如何管理音频系统的好地方。位置在
framework\base\include\media\AudioSystem.h中,定义了大量的枚举之类的东西来表达Google对音频系统的看法。我们只能见招拆招了。
下面是audio_mode的定义。这里要注意一个地方:
这些定义都和SDK中的JAVA层定义类似。实际上应该说先有C++层的定义,然后再反映到JAVA层中。但是C++层的定义一般没有解释说明,而SDK中有。所以我们不能不面对的一个痛苦现实就是:常常需要参考SDK的说明才能搞明白到底是什么。
关于C++的AudioSystem这块,SDK的说明在AudioManager中。
enum audio_mode {
//解释参考SDK说明,以下不再说明
MODE_INVALID = -2, //无效mode
MODE_CURRENT = -1,//当前mode,和音频设备的切换(路由)有关
MODE_NORMAL = 0,//正常mode,没有电话和铃声
MODE_RINGTONE,//收到来电信号了,此时会有铃声
MODE_IN_CALL,//电话mode,这里表示已经建立通话了
NUM_MODES // Android大量采用这种技巧来表示枚举结束了。
};
好,继续:
...
mPhoneState(AudioSystem::MODE_NORMAL), ---->这里有电话的状态?
mRingerMode(0),
mMusicStopTime(0),
mLimitRingtoneVolume(false)
{
mpClientInterface = clientInterface;//BT,保存APS对象。
//forceUse?这是个什么玩意儿?
for (int i = 0; i < AudioSystem::NUM_FORCE_USE; i++) {
mForceUse[i] = AudioSystem::FORCE_NONE;
}
[---->AudioSystem::FORCE_NONE和AudioSystem::NUM_FORCE_USE]
注意,这里有两个枚举,太无耻了。先看看FORCE_NONE这个
enum forced_config {强制_配置,看名字好像是强制使用设备吧,比如外放,耳机,蓝牙等
FORCE_NONE,
FORCE_SPEAKER,
FORCE_HEADPHONES,
FORCE_BT_SCO,
FORCE_BT_A2DP,
FORCE_WIRED_ACCESSORY,
FORCE_BT_CAR_DOCK,
FORCE_BT_DESK_DOCK,
NUM_FORCE_CONFIG,
FORCE_DEFAULT = FORCE_NONE //这个,太无聊了。
};
再看看AudioSystem::NUM_FORCE_USE这个
enum force_use {
FOR_COMMUNICATION,//这里是for_xxx,不是force_xxx。
FOR_MEDIA,
FOR_RECORD,
FOR_DOCK,
NUM_FORCE_USE
};
不懂,两个都不懂。为何?能猜出来什么吗?也不行。因为我们没找到合适的场景!那好吧,我们去SDK找找。恩
我看到AudioManager这个函数setSpeakerphoneOn (boolean on)。好吧,我
这么调用
setSpeakerphoneOn(true),看看实现。
这次我没再浪费时间了,我用一个新的工具coolfind,把搜索framework目录,寻找*.java文件,匹配字符串setSpeakerphone。终于,我在
framework/base/media/java/android/media/AudioService.java中找到了。
public void setSpeakerphoneOn(boolean on){
if (!checkAudioSettingsPermission("setSpeakerphoneOn()")) {
return;
}
if (on) {
//看到这里,是不是明白十之八九了?下面这个调用是:
//强制通话使用speaker!原来是这么个意思!
AudioSystem.setForceUse(AudioSystem.FOR_COMMUNICATION,
AudioSystem.FORCE_SPEAKER);
mForcedUseForComm = AudioSystem.FORCE_SPEAKER;
} else {
AudioSystem.setForceUse(AudioSystem.FOR_COMMUNICATION,
AudioSystem.FORCE_NONE);
mForcedUseForComm = AudioSystem.FORCE_NONE;
}
}
好了,说点题外话,既然Android源码都放开给我们了,有什么理由我们不去多搜搜呢?上网google也是搜,查源代码也是一样吗。不过我们要有目的:就是找到一个合适的使用场景。
force_use和force_config就不用我再解释了吧?
[--->AudioPolicyManagerBase::AudioPolicyManagerBase]
...
//下面这个意思就是把几种for_use的情况使用的设备全部置为NONE。
//比如设置FOR_MEDIA的场景,使用的设备就是FORCE_NONE
for (int i = 0; i < AudioSystem::NUM_FORCE_USE; i++) {
mForceUse[i] = AudioSystem::FORCE_NONE;
}
// 目前可以的输出设备,耳机和外放
mAvailableOutputDevices = AudioSystem::DEVICE_OUT_EARPIECE |
AudioSystem::DEVICE_OUT_SPEAKER;
//目前可用的输入设备,内置MIC
mAvailableInputDevices = AudioSystem::DEVICE_IN_BUILTIN_MIC;
又得来看看AudioSystem是怎么定义输入输出设备的了。
[--->mAvailableOutputDevices = AudioSystem::DEVICE_OUT_EARPIECE]
enum audio_devices {
// output devices
DEVICE_OUT_EARPIECE = 0x1,
DEVICE_OUT_SPEAKER = 0x2,
DEVICE_OUT_WIRED_HEADSET = 0x4,
DEVICE_OUT_WIRED_HEADPHONE = 0x8,
DEVICE_OUT_BLUETOOTH_SCO = 0x10,
DEVICE_OUT_BLUETOOTH_SCO_HEADSET = 0x20,
DEVICE_OUT_BLUETOOTH_SCO_CARKIT = 0x40,
DEVICE_OUT_BLUETOOTH_A2DP = 0x80,
DEVICE_OUT_BLUETOOTH_A2DP_HEADPHONES = 0x100,
DEVICE_OUT_BLUETOOTH_A2DP_SPEAKER = 0x200,
DEVICE_OUT_AUX_DIGITAL = 0x400,
DEVICE_OUT_DEFAULT = 0x8000,
DEVICE_OUT_ALL = (DEVICE_OUT_EARPIECE | DEVICE_OUT_SPEAKER |
DEVICE_OUT_WIRED_HEADSET | DEVICE_OUT_WIRED_HEADPHONE | DEVICE_OUT_BLUETOOTH_SCO | DEVICE_OUT_BLUETOOTH_SCO_HEADSET |DEVICE_OUT_BLUETOOTH_SCO_CARKIT |
DEVICE_OUT_BLUETOOTH_A2DP | DEVICE_OUT_BLUETOOTH_A2DP_HEADPHONES |
DEVICE_OUT_BLUETOOTH_A2DP_SPEAKER | DEVICE_OUT_AUX_DIGITAL | DEVICE_OUT_DEFAULT),
DEVICE_OUT_ALL_A2DP = (DEVICE_OUT_BLUETOOTH_A2DP |
DEVICE_OUT_BLUETOOTH_A2DP_HEADPHONES |DEVICE_OUT_BLUETOOTH_A2DP_SPEAKER),
// input devices
DEVICE_IN_COMMUNICATION = 0x10000,
DEVICE_IN_AMBIENT = 0x20000,
DEVICE_IN_BUILTIN_MIC = 0x40000,
DEVICE_IN_BLUETOOTH_SCO_HEADSET = 0x80000,
DEVICE_IN_WIRED_HEADSET = 0x100000,
DEVICE_IN_AUX_DIGITAL = 0x200000,
DEVICE_IN_VOICE_CALL = 0x400000,
DEVICE_IN_BACK_MIC = 0x800000,
DEVICE_IN_DEFAULT = 0x80000000,
DEVICE_IN_ALL = (DEVICE_IN_COMMUNICATION | DEVICE_IN_AMBIENT |
DEVICE_IN_BUILTIN_MIC |DEVICE_IN_BLUETOOTH_SCO_HEADSET | DEVICE_IN_WIRED_HEADSET |
DEVICE_IN_AUX_DIGITAL | DEVICE_IN_VOICE_CALL | DEVICE_IN_BACK_MIC |
DEVICE_IN_DEFAULT)
};
一些比较容易眼花的东西我标成红色的了。这么多东西,不过没什么我们不明白的了。
得嘞,继续走。
[--->AudioPolicyManagerBase::AudioPolicyManagerBase]
// 目前可以的输出设备,又有耳机又有外放,配置很强悍啊。
//注意这里是OR操作符,最终mAvailableOutputDevices = 0X3
mAvailableOutputDevices = AudioSystem::DEVICE_OUT_EARPIECE |
AudioSystem::DEVICE_OUT_SPEAKER;
//目前可用的输入设备,内置MIC,mAvailableInputDevices为0x4000,不过我们不关注input
mAvailableInputDevices = AudioSystem::DEVICE_IN_BUILTIN_MIC;
...
下面东西就很少了,我们一气呵成。
//创建一个AudioOutputDescriptor,并设置它的device为外设0x2
AudioOutputDescriptor *outputDesc = new AudioOutputDescriptor();
outputDesc->mDevice = (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER;
//调用APS的openOutput,得到一个mHardwareOutput东东。这是个int型
//不过保不准是一个指针也不一定喔。
//而且,下面的参数都是指针类型(flags除外),难道?有人会改value吗?
mHardwareOutput = mpClientInterface->openOutput(&outputDesc->mDevice,
&outputDesc->mSamplingRate,
&outputDesc->mFormat,
&outputDesc->mChannels,
&outputDesc->mLatency,
outputDesc->mFlags);
//这个...估计是把int和指针加入到一个map了,方便管理。
addOutput(mHardwareOutput, outputDesc);
//不知道干嘛,待会看。
setOutputDevice(mHardwareOutput, (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER, true);
//不知道干嘛,待会看。
updateDeviceForStrategy();
好了,上面还有一系列函数,等着我们调用呢。我们一个一个看。
提前说一下,这块可是AudioManagerBase的核心喔。
[---->AudioOutputDescriptor *outputDesc = new AudioOutputDescriptor()]
AudioOutputDescriptor是个什么?我不是神,我也得看注释。
// descriptor for audio outputs. Used to maintain current configuration of each opened audio output
// and keep track of the usage of this output by each audio stream type.
明白了么?大概意思就是它,是这么一个东西:
l 描述audio输出的,可以用来保存一些配置信息。
l 跟踪音频stream类型使用这个output的一些情况。
没明白吧?以后碰到场景就明白了。
它的构造函数干了如下勾当:
AudioPolicyManagerBase::AudioOutputDescriptor::AudioOutputDescriptor()
: mId(0), mSamplingRate(0), mFormat(0), mChannels(0), mLatency(0),
mFlags((AudioSystem::output_flags)0), mDevice(0), mOutput1(0), mOutput2(0)
{}
//很好,统统都置零了。上面这些东西不用我解释了吧?命名规则也可以看出来。
OK,go on.
[--->mHardwareOutput = mpClientInterface->openOutput()]:
这里调用的是APS的openOutput,看看去:
[--->AudioPolicyService::openOutput]
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<IAudioFlinger> af = AudioSystem::get_audio_flinger();
//娘希匹,搞到AF去了
return af->openOutput(pDevices, pSamplingRate, (uint32_t *)pFormat, pChannels,
pLatencyMs, flags);
}
[----->AudioFlinger::openOutput]
int AudioFlinger::openOutput(uint32_t *pDevices,
uint32_t *pSamplingRate,
uint32_t *pFormat,
uint32_t *pChannels,
uint32_t *pLatencyMs,
uint32_t flags)
{
//我们思考下传进来的值吧
//*pDevices=0x2,代表外放
//其他都是0。 嘿嘿,有了值,这不就知道下面该怎么走了吗?
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);
//HAL对象得到一个AudioStreamOut,传进去的值会改吗?
AudioStreamOut *output = mAudioHardware->openOutputStream(*pDevices,
(int *)&format,
&channels,
&samplingRate,
&status);
mHardwareStatus = AUDIO_HW_IDLE;
if (output != 0) {
//走哪个分支?我把答案告诉大家吧。
//刚才那个mAudioHardware->openOutputStream确实会更改指针对应的value。
//当然,我们说了,AF使用的是GENERIC的Audio硬件。大家有兴趣可以去看看它的实现。
//我待会再贴出它的内容。反正到这里。
//那几个值变成:format为PCM_16_BIT,channels为2,samplingRate为44100
//这样的话,那只能走else分支了。
if ((flags & AudioSystem::OUTPUT_FLAG_DIRECT) ||
(format != AudioSystem::PCM_16_BIT) ||
(channels != AudioSystem::CHANNEL_OUT_STEREO)) {
thread = new DirectOutputThread(this, output, ++mNextThreadId);
} else {
//还记得前两节分析的同学,看到这里是不是明白了?恩,原来
//open一个Output,就会在AF中创建一个混音线程。设计得真好。
//想象下,所有设置为外放的程序,它的输出都是这个外放stream混音线程来工作
//所有设置为耳机的程序,它的输出都是这个耳机stream混音线程来完成。
//为什么对stream特加强调呢,没看见
//我们调用的是mAudioHardware->openOutputStream(0x2,,,)嘛。返回的
//是一个AudioStreamOut,可不是设备喔。Android把这些个东西都交给HAL层去实现了。
//不用自己来管理系统上有什么耳机,外设,蓝牙真实设备之类的东东,它反正用AudioStreamOut来表示它想要的就可以了。例如Generic的Audio Hal只支持一个OutputStream。--> only my opinion
thread = new MixerThread(this, output, ++mNextThreadId);
}
//好了,又多得了一个线程,
mPlaybackThreads.add(mNextThreadId, thread);
if (pSamplingRate) *pSamplingRate = samplingRate;
if (pFormat) *pFormat = format;
if (pChannels) *pChannels = channels;
if (pLatencyMs) *pLatencyMs = thread->latency();
//从这里返回的是混音线程的索引。
return mNextThreadId;
}
return 0;//如果没创建成功线程,则返回零。
}
好,我们回到AudioManagerBase中。
[--->AudioPolicyManagerBase::AudioPolicyManagerBase]
mHardwareOutput = mpClientInterface->openOutput(&outputDesc->mDevice,
&outputDesc->mSamplingRate,
&outputDesc->mFormat,
&outputDesc->mChannels,
&outputDesc->mLatency,
outputDesc->mFlags);
//上面实际就返回一个线程index。我有点疑惑,难道APS就只这么一个实际是线程index的东西就就行了吗?虽然它把这个index当成hardware的标识了。
//这个...估计是把int和指针加入到一个map了,方便管理。不看了。
addOutput(mHardwareOutput, outputDesc);
//不知道干嘛,待会看。
setOutputDevice(mHardwareOutput, (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER, true);
[--->setOutputDevice(mHardwareOutput,...)]
这个函数,很重要!另外,再传点技巧。不要老在source insight中后退后退了,直接找到window菜单,里边列出了最近打开的文件,找到我们的AudioManagerBase.cpp,不就行了吗?
void AudioPolicyManagerBase::setOutputDevice(audio_io_handle_t output, uint32_t device, bool force, int delayMs)
{
//注意我们的参数:
// output = 1,
//device为AudioSystem::DEVICE_OUT_SPEAKER
// force为true,delayMs用默认值0
//map吧?刚才通过addOutput已经加进去了
AudioOutputDescriptor *outputDesc = mOutputs.valueFor(output);
if (outputDesc->isDuplicated()) {
setOutputDevice(outputDesc->mOutput1->mId, device, force, delayMs);
setOutputDevice(outputDesc->mOutput2->mId, device, force, delayMs);
return;
}
//还记得addOutput前设置的device吗?对了,为0X3,外放|耳机
uint32_t prevDevice = (uint32_t)outputDesc->device();
现在设置的是外设,
if ((device == 0 || device == prevDevice) && !force) {
return;
}
//喔,设置这个outputDesc为外放
outputDesc->mDevice = device;
popCount为2,因为device=0x2=0010
//另外,我对下面这个output== mHardwareOutput尤其感兴趣。还记得我们刚才的疑问吗?
// mHardwareOutput实际上是AF返回的一个线程索引,那AMB怎么根据这样一个东西来
//管理所有的线程呢?果然,这里就比较了output是不是等于最初创建的线程索引
//这就表明。虽然只有这么一个mHardwareOutput,但实际上还是能够操作其他output的!
if (output == mHardwareOutput && AudioSystem::popCount(device) == 2) {
setStrategyMute(STRATEGY_MEDIA, true, output);
usleep(outputDesc->mLatency*2*1000);
}
// 晕,又冒出来一个AudioParameter,不过意思却很明白
//说我们要设置路由,新的输出设备为外放
//等我们以后讲由外放切换到耳机,再来看这个问题。
AudioParameter param = AudioParameter();
param.addInt(String8(AudioParameter::keyRouting), (int)device);
mpClientInterface->setParameters(mHardwareOutput, param.toString(), delayMs);
// update stream volumes according to new device
applyStreamVolumes(output, device, delayMs);
// if changing from a combined headset + speaker route, unmute media streams
if (output == mHardwareOutput && AudioSystem::popCount(prevDevice) == 2) {
//这里说,把media的音量置为0。以后再说。
setStrategyMute(STRATEGY_MEDIA, false, output, delayMs);
}
}
好了,返回了。
setOutputDevice(mHardwareOutput, (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER, true);
这个调研,更新了mHardwareOutput对应的输出路由设备,而且还发了一个命令给APS,说你给我更新对应混音线程的输出路由设备。
[--->AudioPolicyManagerBase::AudioPolicyManagerBase]
.....
addOutput(mHardwareOutput, outputDesc);
setOutputDevice(mHardwareOutput, (uint32_t)AudioSystem::DEVICE_OUT_SPEAKER,
true);
//只剩下最后一个函数了
updateDeviceForStrategy();
[----->updateDeviceForStrategy()]
void AudioPolicyManagerBase::updateDeviceForStrategy()
{
for (int i = 0; i < NUM_STRATEGIES; i++) {
mDeviceForStrategy[i] = getDeviceForStrategy((routing_strategy)i, false);
}
}
晕,又出来一个枚举。我们看看
[---->for (int i = 0; i < NUM_STRATEGIES; i++)]
NUM_STRATEGIES在hardware/libhardware_legacy/include/hardware_legacy/
AudioPolicyManagerBase.h中定义。
enum routing_strategy {
//好像很好理解
STRATEGY_MEDIA,
STRATEGY_PHONE,//通话音吗?
STRATEGY_SONIFICATION,//除了其他三个外的,可以是铃声,提醒声等。
STRATEGY_DTMF,//好像是拨号音
NUM_STRATEGIES
};
这个,反正我在SDK上没找到对应说明,我们待到以后看看会不会柳暗花明呢?
[----->getDeviceForStrategy((routing_strategy)i, false)]
看这个函数名的意思是,为各种策略找到它对应的设备。
uint32_t AudioPolicyManagerBase::getDeviceForStrategy(routing_strategy strategy, bool fromCache)
{
// fromCache为false
//放眼望去,这个函数好像涉及到很对策略方面的事情。
//我们大概讲解下,至于系统为什么要这么做,问Google吧。
uint32_t device = 0;
switch (strategy) {
case STRATEGY_DTMF:
if (mPhoneState != AudioSystem::MODE_IN_CALL) {
//如果在打电话过程中,你再按按键,则和MEDIA走一个设备
device = getDeviceForStrategy(STRATEGY_MEDIA, false);
break;
}
//注意这里没有break,所以在其他mode下,DTMF和PHONE用一个策略
case STRATEGY_PHONE:
//还得判断用户是不是强制使用了输出设备。
switch (mForceUse[AudioSystem::FOR_COMMUNICATION]) {
case AudioSystem::FORCE_BT_SCO:
if (mPhoneState != AudioSystem::MODE_IN_CALL || strategy != STRATEGY_DTMF) {
device = mAvailableOutputDevices &
AudioSystem::DEVICE_OUT_BLUETOOTH_SCO_CARKIT;
if (device) break;
}
device = mAvailableOutputDevices &
AudioSystem::DEVICE_OUT_BLUETOOTH_SCO_HEADSET;
if (device) break;
device = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_BLUETOOTH_SCO;
if (device) break;
// if SCO device is requested but no SCO device is available, fall back to default
// case
// FALL THROUGH
//我们还记得强制设置那里吗?对了,此时都是FORCE_NONE
//而且,mAvailableOutputDevices是0X3 (外放|耳机)
default: // FORCE_NONE
device = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_WIRED_HEADPHONE;
if (device) break;
device = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_WIRED_HEADSET;
if (device) break;
//看,下面这句会成立。啥意思?如果有耳机的话,那么输出设备就是耳机
//太正确了。实际手机是不是就是这样的呢?
device = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_EARPIECE;
break;
//再验证下我们刚才说的,如果强制使用外放的话,
case AudioSystem::FORCE_SPEAKER:
if (mPhoneState != AudioSystem::MODE_IN_CALL || strategy != STRATEGY_DTMF) {
device = mAvailableOutputDevices &
AudioSystem::DEVICE_OUT_BLUETOOTH_SCO_CARKIT;
if (device) break;
}
//果然,会强制使用外放。
device = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_SPEAKER;
break;
}
break;
case STRATEGY_SONIFICATION://分析方法同上,我不说了。
if (mPhoneState == AudioSystem::MODE_IN_CALL) {
device = getDeviceForStrategy(STRATEGY_PHONE, false);
break;
}
device = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_SPEAKER;
// 同样没有break,说明SONIFICATION受MEDIA策略影响。
case STRATEGY_MEDIA: {
uint32_t device2 = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_AUX_DIGITAL;
if (device2 == 0) {
device2 = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_WIRED_HEADPHONE;
}
if (device2 == 0) {
device2 = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_WIRED_HEADSET;
}
//可惜,上面那些高级设备我们都没有
if (device2 == 0) {
device2 = mAvailableOutputDevices & AudioSystem::DEVICE_OUT_SPEAKER;
}
//假设我们没有从SONIFICATION下来,那么device最终会= DEVICE_OUT_SPEAKER。
//假设我们从SONIFICATION下来,那么device还是等于DEVICE_OUT_SPEAKER
//奇怪,如果有耳机的话为何会走外放呢?普通耳机和线控耳机还能区分?
device |= device2;
} break;
default:
break;
}
return device;
}
好了,回到
[---->AudioPolicyManagerBase::updateDeviceForStrategy()]
void AudioPolicyManagerBase::updateDeviceForStrategy()
{
for (int i = 0; i < NUM_STRATEGIES; i++) {
mDeviceForStrategy[i] = getDeviceForStrategy((routing_strategy)i, false);
}
}
这个函数完了,表明各种策略下使用的对应设备也准备好了。
真爽,一路回去,APS的构造就完了。
留个纪念:
AudioPolicyManagerBase::AudioPolicyManagerBase(AudioPolicyClientInterface *clientInterface)
{
....
updateDeviceForStrategy();
}
AudioPolicyService::AudioPolicyService()
: BnAudioPolicyService() , mpPolicyManager(NULL)
{
#if (defined GENERIC_AUDIO) || (defined AUDIO_POLICY_TEST)
mpPolicyManager = new AudioPolicyManagerBase(this);
LOGV("build for GENERIC_AUDIO - using generic audio policy");
...
#endif
property_get("ro.camera.sound.forced", value, "0");
mpPolicyManager->setSystemProperty("ro.camera.sound.forced", value);
}
总结下吧,AF,APS都创建完了,得到什么了吗?下面按先后顺序说说。
l AF创建了一个代表HAL对象的东西
l APS创建了两个AudioCommandThread,一个用来处理命令,一个用来播放tone。我们还没看。
l APS同时会创建AudioManagerBase,做为系统默认的音频管理
l AMB集中管理了策略上面的事情,同时会在AF的openOutput中创建一个混音线程。同时,AMB会更新一些策略上的安排。
另外,我们分析的AMB是Generic的,但不同厂商可以实现自己的策略。例如我可以设置只要有耳机,所有类型声音都从耳机出。
上面关于AMB方面,我们还只是看了看它的代码,还没有一个实际例子来体会。