一、AudioPolicyService启动过程分析
1. 播放声音，声音从哪个设备播放出来是由audio policy决定的。
2.在每一个声卡，对应一个output，一个output对应系统中都有一个线程与其对应。
3.对硬件的访问操作是由AudioFlinger来完成的
4.AudioPolicyService在启动时会去读取解析配置文件/system/etc/audio_policy.conf 根据配置文件来操作AudioFlinger来打开output，创建线程。
5.tiny4412上的配置文件
# cat /system/etc/audio_policy.conf global_configuration { attached_output_devices AUDIO_DEVICE_OUT_SPEAKER default_output_device AUDIO_DEVICE_OUT_SPEAKER attached_input_devices AUDIO_DEVICE_IN_BUILTIN_MIC } audio_hw_modules { //注意这里是modules,里面的每一项都表示一个module primary { //这是一个module，一个module对一个厂家提供的一个.so文件 outputs { //注意这是outputs,里面的每一项都是一个output primary { //这是一个output，里面的参数是对这个output的配置，格式“name value” sampling_rates 44100 channel_masks AUDIO_CHANNEL_OUT_STEREO formats AUDIO_FORMAT_PCM_16_BIT devices AUDIO_DEVICE_OUT_SPEAKER|AUDIO_DEVICE_OUT_EARPIECE|AUDIO_DEVICE_OUT_WIRED_HEADSET|AUDIO_DEVICE_OUT_WIRED_HEADPHONE|AUDIO_DEVICE_OUT_ALL_SCO|AUDIO_DEVICE_OUT_AUX_DIGITAL flags AUDIO_OUTPUT_FLAG_PRIMARY } } inputs { primary { sampling_rates 8000|11025|12000|16000|22050|24000|32000|44100|48000 channel_masks AUDIO_CHANNEL_IN_MONO|AUDIO_CHANNEL_IN_STEREO formats AUDIO_FORMAT_PCM_16_BIT devices AUDIO_DEVICE_IN_BUILTIN_MIC|AUDIO_DEVICE_IN_WIRED_HEADSET|AUDIO_DEVICE_IN_BLUETOOTH_SCO_HEADSET|AUDIO_DEVICE_IN_AUX_DIGITAL|AUDIO_DEVICE_IN_VOICE_CALL } } } }
6.AudioPolicyService启动过程分析
a. 加载解析/vendor/etc/audio_policy.conf或/system/etc/audio_policy.conf
对于配置文件里的每一个module项, new HwModule(name), 放入mHwModules数组
对于module里的每一个output, new IOProfile, 放入module的mOutputProfiles
对于module里的每一个input, new IOProfile, 放入module的mInputProfiles
b. 根据module的name加载厂家提供的so文件 (通过AudioFlinger来加载) 这里很重要！！！
c. 打开对应的output (通过AudioFlinger来open output)
7.HwModule是来自配置文件中的audio_hw_modules中的成员primary
8.instantiate()用于注册服务
main() //framework/main_mediaserver.cpp AudioPolicyService::instantiate(); //framework/main_mediaserver.cpp 这个instantiate()实现在BinderService类中，用于add Service.
二、AudioFlinger启动过程分析
参考002 UML
1.加载的.so文件在/system/lib/hw下
2 AudioFlinger启动过程分析
a. 注册AudioFlinger服务 b. 被AudioPolicyService调用以打开厂家提供的so文件 b.1 加载哪个so文件? 文件名是什么? 文件名从何而来? 名字从/system/etc/audio_policy.conf得到module的名字为: primary，所以so文件就是 : audio.primary.XXX.so, eg. audio.primary.tiny4412.so(来自audio_hw_hal.cpp和AudioHardware.cpp) b.2 该so文件由什么源文件组成? 查看Android.mk audio.primary.$(TARGET_DEVICE) : device/friendly-arm/common/libaudio/AudioHardware.cpp libhardware_legacy libhardware_legacy : hardware/libhardware_legacy/audio/audio_hw_hal.cpp 结论：主要是由AudioHardware.cpp和audio_hw_hal.cpp构成。 b.3 对硬件的封装: AudioFlinger.cpp : 把硬件封装成AudioHwDevice (放入mAudioHwDevs数组中) audio_hw_hal.cpp : 把硬件封装成audio_hw_device 厂家 : 把硬件封装成AudioHardware (派生自: AudioHardwareInterface) AudioHwDevice是对audio_hw_device的封装, audio_hw_device中函数的实现要通过AudioHardware类对象 c. 被AudioPolicyService调用来open output、创建playback thread
三、AudioTrack创建过程
1.AudioTrack::AudioTrack()调用的set()中创建一个AudioTrack并与硬件挂钩
2.Android中使用一个output来描述声卡的输出通道。一个output对应一个playbackThread,这些信息由AudioFilnger决定
3.AudioTrack创建过程概述
a.1 C++实现测试程序: frameworks/base/media/tests/audiotests/shared_mem_test.cpp 内容为自己构造一个正弦波音频，一直播放知道Ctrl+C结束。 a.2 java实现的测试程序：（目前还没测试） frameworks/base/media/tests/MediaFrameworkTest/src/com/android/mediaframeworktest/functional/audio/MediaAudioTrackTest.java 播放声音时都要创建AudioTrack对象(这个AudioTrack对象可以是C++实现的，也可以是Java实现的), java的AudioTrack对象创建时会导致C++的AudioTrack对象被创建; 所以分析的核心是c++的AudioTrack类, 创建AudioTrack时涉及一个重要函数: set b. 猜测创建过程的主要工作 b.1 set()使用AudioTrack的属性, 根据AudioPolicy找到对应的output、playbackThread(一个output就对应一个playbackThread) b.2 在playbackThread中创建对应的track b.3 APP的AudioTrack 和 playbackThread的mTracks中的track之间建立共享内存 c. 源码时序图 003 UML
四、AudioTrack创建过程_选择output
1. AudioTrack创建过程_选择output
a. APP构造AudioTrack时指定了 stream type b. AudioTrack::setAttributesFromStreamType 根据stream type设置属性 c. AudioPolicyManager::getStrategyForAttr 根据属性获得声音的strategy(类别) d. AudioPolicyManager::getDeviceForStrategy 根据类别选择声音从哪个device里面播放 e. AudioPolicyManager::getOutputForDevice 根据device获得output. //可能有多个output支持同一类别的一个device e.1 AudioPolicyManager::getOutputsForDevice //获取这个device的所有output e.2 output = selectOutput(outputs, flags, format);//从这个device的多个output中选择某一个output
2.AudioPolicyManager.mOutputs对应于已打开的output，每一项都含有mProfile，这个mProfile是来自/system/etc/audio_policy.conf，mProfile中指明该output支持哪些device。
DefaultKeyedVector<audio_io_handle_t, sp<AudioOutputDescriptor> > mOutputs;
3.有可能有多个output都支持某个device，怎么从多个output中取出最合适的output?
AudioPolicyManager::selectOutput中 首先匹配flag,找出最吻合的output: a.APP创建AudioTrack时会传入flag b.output对应的profile中也有flag(来自/system/etc/audio_policy.conf中指定的flag), c.使用上述a,b的flag进行比较，取出吻合度最高的output. 如果吻合度相同： 如果primary output支持该设备，选它，否则取出第一个output。
五、AudioTrack创建过程_Track和共享内存
1.一个output对应一个播放设备(声卡)，也对应一个播放线程。音频数据流向playbackThread ---> output ---> 声卡设备
2.应用程序中的AudioTrack和播放线程中的mTrack中的成员是一一对应的。它们之间通过共享内存来传递数据。
3. AudioTrack创建过程_Track和共享内存
回顾:
a. APP创建AudioTrack <-----------------> AudioFlinger中PlaybackThread创建对应的Track
b. APP给AudioTrack提供音频数据有2种方式: 一次性提供(MODE_STATIC)、边播放边提供(MODE_STREAM)
问:
a. 音频数据存在buffer中, 这个buffer由谁提供? APP 还是 PlaybackThread ?
(1)MODE_STATIC：若是App一次性提供音频数据，那么buffer是由App创建的，因为App更方便知道buffer的大小属性。
(2)MODE_STREAM：若App是边播放边提供音频数据，那么就由playbackThread创建，这样App实现起来比较方便。
b. APP提供数据, PlaybackThread消耗数据, 如何同步?
(1)MODE_STATIC：一次性提供，就不需要同步，这是一前一后的事情。
(2)MODE_STREAM：边播放边提供音频数据的时候，这是典型的生产者消费者问题，使用环形缓冲区来同步。
4.playbackThread中的mTracks是个链表，上面的每一个Track都对应应用程序中的一个AudioTrack. 也正是由于App创建了
AudioTrack才导致mTracks链表上的track被创建。
5.App和playbackThread是处于不同的进程中的，音频数据可以通过binder通信，但是效率不是很高，所以使用共享内存来传递数据。
6.测试程序shared_mem_test.cpp中使用的就是一次性提供：
AudioTrackTest::Test01() iMem = heap->allocate(BUF_SZ*sizeof(short)); memcpy(p, smpBuf, BUF_SZ*sizeof(short)); sp<AudioTrack> track = new AudioTrack(AUDIO_STREAM_MUSIC,// stream type rate, AUDIO_FORMAT_PCM_16_BIT,// word length, PCM AUDIO_CHANNEL_OUT_MONO, iMem); /*这里一次性把音频数据传下去了*/
对于C++的实现，参数iMem若是不为NULL就表示这个共享内存是由App创建的，之后就会使用MODE_STATIC这个方式传输数据；若为NULL，表明App并没有去创建这个buffer，将由playbackThread来创建这个共享内存，之后将通过MODE_STREAM方式传输数据；
AudioTrack它并没有一个模式来分辨是使用MODE_STATIC还是MODE_STREAM，它通过参数iMem是NULL还是非NULL来分辨使用哪种方式。
C++的AudioTrack类不需要指定模式，但是Java的AudioTrack需要：
MediaAudioTrackTest.java testSetPlaybackHeadPositionTooFar() int TEST_MODE = AudioTrack.MODE_STREAM; AudioTrack track = new AudioTrack(TEST_STREAM_TYPE, TEST_SR, TEST_CONF, TEST_FORMAT, 2*minBuffSize, TEST_MODE); testSetPlaybackRateUninit() int TEST_MODE = AudioTrack.MODE_STATIC; AudioTrack track = new AudioTrack(TEST_STREAM_TYPE, TEST_SR, TEST_CONF, TEST_FORMAT, minBuffSize, TEST_MODE);
7.AudioTrack构造函数：
AudioTrack(AudioAttributes attributes, AudioFormat format, int bufferSizeInBytes, int mode, int sessionId) //AudioTrack.java //本地初始化 native_setup(new WeakReference<AudioTrack>(this), mAttributes, mSampleRate, mChannels, mAudioFormat, mNativeBufferSizeInBytes, mDataLoadMode, session); //对应这个JNI函数 android_media_AudioTrack_setup //android_media_AudioTrack.cpp //本地的AudioTrack类对象，没有传入任何参数 sp<AudioTrack> lpTrack = new AudioTrack(); case MODE_STREAM: //对于MODE_STREAM模式，直接调用set()，没有在App进程中分配内存 lpTrack->set() case MODE_STATIC: //对于MODE_STATIC模式，会在App进程中分配buffer lpJniStorage->allocSharedMem(buffSizeInBytes) lpTrack->set()
六、音频数据的传递
1.App这边相关的代码在AudioTrack.cpp中，playbackTread的处理函数在Track.cpp中。
2.mProxy用于App端管理共享内存
// frameworksavmedialibmediaAudioTrack.cpp AudioTrack::createTrack_l() // update proxy if (mSharedBuffer == 0) { mStaticProxy.clear(); mProxy = new AudioTrackClientProxy(cblk, buffers, frameCount, mFrameSizeAF); } else { mStaticProxy = new StaticAudioTrackClientProxy(cblk, buffers, frameCount, mFrameSizeAF); mProxy = mStaticProxy; }
mServerProxy类是用于给播放线程管理内存的
// frameworksavservicesaudioflingerTracks.cpp AudioFlinger::PlaybackThread::Track::Track if (sharedBuffer == 0) { mAudioTrackServerProxy = new AudioTrackServerProxy(mCblk, mBuffer, frameCount, mFrameSize, !isExternalTrack(), sampleRate); } else { mAudioTrackServerProxy = new StaticAudioTrackServerProxy(mCblk, mBuffer, frameCount, mFrameSize); } mServerProxy = mAudioTrackServerProxy;
3.音频数据的传递总结
a. APP创建AudioTrack, playbackThread创建对应的Track，它们之间通过共享内存传递音频数据 b. APP有2种使用共享内存的方式: b.1 MODE_STATIC: APP创建共享内存, APP一次性填充数据 b.2 MODE_STREAM: APP使用obtainBuffer获得空白内存, 填充数据后使用releaseBuffer释放内存 c. playbackThread使用obtainBuffer获得含有数据的内存, 使用数据后使用releaseBuffer释放内存 d. App端的AudioTrack中含有mProxy，它被用来管理共享内存，里面含有obtainBuffer，releaseBuffer函数； 播放线程端的Track中含有mServerProxy，它被用来管理共享内存，里面含有obtainBuffer, releaseBuffer函数 对于不同的MODE, 这些Proxy指向不同的对象。 e. 对于MODE_STREAM, APP和playbackThread使用环型缓冲区的方式传递数据。
5.环形缓冲区讲解
a.初始R=0,W=0,buff的长度为LEN b.写入一个数据 w = W % LEN; buff[w] = data; W++; c.读出一个数据 r = R % LEN; data = buff[r]; R++; 判断缓冲区满：R + LEN == W 判断缓冲区空：R == W 由上可以看出R和W是一直递增的。 判断溢出时，R和W同时都减少LEN的整数倍大小，将不影响结果 改进: 将LEN圆整到2的n次方，此时W%LEN这个可能比较慢的操作就可以转换为w=W&(LEN-1)
七、PlaybackThread处理流程
1.声卡往往只支持一种格式的音频数据(如2-Channel，44K-Sample, 16bit-Deep)。但是App可能会传递下来不同格式的音频数据，
这些数据在在playbackThread中进行重采样，采样到声卡支持的格式。mAudioMixer对象负责这一工作。重采样之后还要把各个App
的音频数据混合起来，称为混音，也是由mAudioMixer负责的。
2.hook成员指向不同的处理函数
//frameworksavservicesaudioflingerAudioMixer.cpp process__nop():手机静音了，不做任何处理 process__genericNoResampling(): 不需要重采样 process__genericResampling(): 应该就是进行重采样
3. PlaybackThread 处理流程
AudioFlinger::PlaybackThread::threadLoop()
frameworksavservicesaudioflingerThreads.cpp
a. prepareTracks_l :
确定enabled track, disabled track。对于enabled track, 设置mState.tracks[x]中的参数
b. threadLoop_mix : 处理数据(比如重采样)、混音
确定hook: 逐个分析mState.tracks[x]的数据, 根据它的格式确定tracks[x].hook。再确定总的mState.hook
调用hook: 调用总的mState.hook即可, 它会再去调用每一个mState.tracks[x].hook
混音后的数据会放在mState.outputTemp临时BUFFER中然后转换格式后存入 thread.mMixerBuffer
c. memcpy_by_audio_format : 把数据从thread.mMixerBuffer或thread.mEffectBuffer复制到thread.mSinkBuffer
d. threadLoop_write: 把thread.mSinkBuffer写到声卡上
e. threadLoop_exit
4.总结
原始数据会保存在共享内存中，经过重采样等处理后存放在一个临时的outputTemp buffer中，这个临时buffer中的数据保存的是重采样后的数据，数据来源是多个Track。最终的可播放的数据经过混音后存放在mMixerBuffer这个buffer中。如果需要进行音效处理(比如加强低音)，还有一部分数据会被放在mEffectBuffer中。之后会把mMixerBuffer和mEffectBuffer中的音频数据都输出到mSinkBuffer中，然后从mSinkBuffer中将数据发给声卡硬件。