Android音频(6)——音频系统分析

一、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端管理共享内存

// frameworks\av\media\libmedia\AudioTrack.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类是用于给播放线程管理内存的

// frameworks\av\services\audioflinger\Tracks.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成员指向不同的处理函数

//frameworks\av\services\audioflinger\AudioMixer.cpp
process__nop():手机静音了，不做任何处理
process__genericNoResampling(): 不需要重采样
process__genericResampling(): 应该就是进行重采样

3. PlaybackThread 处理流程

AudioFlinger::PlaybackThread::threadLoop()
frameworks\av\services\audioflinger\Threads.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中将数据发给声卡硬件。

posted on 2019-05-27 18:27 Hello-World3 阅读(2994) 评论(0) 编辑收藏举报

刷新页面返回顶部

hellokitty2

Android音频(6)——音频系统分析

导航

公告