轉自大神博客
Android支持多種設備的的輸出。一台正常的機子,本身就自帶話筒,揚聲器,麥克風等多個聲音輸入輸出設備,再加上五花八門的外置設備(通過耳機,藍牙,wifi等方式連接),使聲音的輸出更具多樣性。Android支持如此多的設備連接,那么android內部是怎樣對設備的輸出輸出進行控制的呢?這一次我們主要來看看音頻通路的切換。
音頻流、設備、音頻策略
要想知道Andorid是怎樣對設備的輸出輸出進行控制的,我們首先來了解一些音頻相關的基本知識: stream_type、content_type、devices、routing_strategy。
stream_type:音頻流的類型。在當前系統中,Android(6.0)一共定義了11種stream_type以供開發者使用。Android上層開發要想要發出聲音,都必須先確定當前當前的音頻類型。
content_type:具體輸出類型。雖然當前一共有11種stream_type,但一旦進入到Attribute,Android就只將其整理成幾種類型。這才是實際的類型。
device:音頻輸入輸出設備。Android定義了多種設備輸入輸出設備(具體物理設備可能還是那幾個,但是輸出場景不盡相同)。
routing_strategy:音頻路由策略。默認情況下,Android是根據路由策略去選擇設備負責輸出輸入音頻的。
stream_type在android中Java層與c++層均有定義。並且對應的值是保持一致的。
device與stream_type一樣,在java層和C++層均有定義,並且會根據使用的情況不同蘊含多個定義:
相對stream_type,routing_strategy只是一個定義在RountingStrategy.h的一個簡單的枚舉結構體:
usecase只是qcom內部定義的一個數據結構,位於hal層,用作處理處理內部聲卡邏輯和輸出方案。輸出方案與聲卡中的mixer_path_xxx.xml相聯。而mixer_path等相關文件,才是具體的音頻輸出方案。
我們通過查看當前的聲卡情況確定了當前具體的mixer_path文件——mixer_path_skue.xml。xml文件內部就是我們預定義的usecase的具體情況:
在mixer_path類文件中,一個標准的path就如上面的紅框那樣。有名字,有一定的參數。另外,一個patch之中,還可以嵌套另外一個patch。
由於usecase只是目前高通hal層獨有的定義,所以本文不會花太多時間和精力去探討usecase的相關設置和內容。目前來說,對這個有一定的認知就可。
AudioPolicy和AudioPolicyService
在了解完Audio一些基本的定義設定之后,我們來看一下Android的Audio整體架構。
Audio內部系統從上到下包含各方面的東西。對於聲音輸出的設備的選擇與切換,我們主要需要關注2個地方。第一處,是外接設備如耳機,藍牙設備等連接的通知。第二處就是Audio系統中核心的AudioFinger與AudioPolicyService的處理內容。
AudioFinger是Audio系統的工作引擎,管理者系統中輸入輸出音頻流,並承擔音頻數據混音,以及讀寫Audio硬件等工作以實現數據的輸入輸出功能。AudioPolicyService是Audio系統策略控制中心,具體負責掌管系統中聲音設備的選擇和切換,音量控制等功能。
AudioFinger與AudioPolicyService的類圖關系:
在AudioFlinger和AudioPolicyService的運作中其實包含着很多類,但同時,我們也可以發現,在Audio系統中, AudioFinger與AudioPolicyService是緊密相連的。總得來說,AudioFinger與AudioPolicyService是Audio系統的核心。所以下面我們很多內容的主角,都是他們2個。
基本的聲音輸出調用
發出聲音是Android機器的一個最基本的功能。但是,Android是怎么發出聲音的呢?就算不連接外設,Android最基本還有聽筒和揚聲器2個設備。那么,Android內部,是怎么控制他們2個發出聲音的呢?下面我們來具體看 一下Android一般情況下發出聲音時選擇設備的過程。
我們要想分析Android中的聲音輸出,當然是先通過播放音頻去一步一步了解Android是怎惡魔輸出聲音的。下面我們以一個最簡單的AudioTrack播放音頻為例,來看下Android的發生過程。
一個簡單的AudioTrack播放的例子如下:
- AudioTrack audioTrack = new AudioTrack(AudioManager.STREAM_MUSIC, 11025/2,
- AudioFormat.CHANNEL_CONFIGURATION_MONO,
- AudioFormat.ENCODING_PCM_16BIT,
- audioLength, AudioTrack.MODE_STREAM);
- audioTrack.play();
- audioTrack.write(audioData, 0, sizeInBytes);
AudioTrack在接收參數創建的時候,就會將設置的steamtype保存在對應的AudioAttributes當中(AudioAttributes是一個描述關於音頻流的信息的屬性集合的類)。
我們知道,在android系統中,系統封裝的對象是一層一層往下調用的。所以,在我們創建了一個java的AudioTrack對象的時候,其實在同時,在C++當中,我們已經做了很多操作了。下面我們來看一下,AudioTrack對象創建時,主要做了什么:
- static jint
- android_media_AudioTrack_setup(JNIEnv *env, jobject thiz, jobject weak_this,
- jobject jaa,
- jint sampleRateInHertz, jint channelPositionMask, jint channelIndexMask,
- jint audioFormat, jint buffSizeInBytes, jint memoryMode, jintArray jSession) {
- //……
- // create the native AudioTrack object
- sp<AudioTrack> lpTrack = new AudioTrack();
- //……
- // initialize the native AudioTrack object
- status_t status = NO_ERROR;
- switch (memoryMode) {
- case MODE_STREAM:
- status = lpTrack->set(
- AUDIO_STREAM_DEFAULT,
- sampleRateInHertz,
- format,
- nativeChannelMask,
- frameCount,
- AUDIO_OUTPUT_FLAG_NONE,
- audioCallback, &(lpJniStorage->mCallbackData),
- 0,
- 0,
- true,
- sessionId,
- AudioTrack::TRANSFER_SYNC,
- NULL,
- -1, -1,
- paa);
- break;
- //……
- if (status != NO_ERROR) {
- ALOGE("Error %d initializing AudioTrack", status);
- goto native_init_failure;
- }
- // save our newly created C++ AudioTrack in the "nativeTrackInJavaObj" field
- // of the Java object (in mNativeTrackInJavaObj)
- setAudioTrack(env, thiz, lpTrack);
- //……
- }
從上面的代碼可以看出,在創建java層的AudioTrack對象時,對應的jni也創建出一個C++的AudioTrack對象,並且傳入了部分參數和調用了其方法。
接下來我們來看看C++的AudioTrack對象的構造方法:
- AudioTrack::AudioTrack()
- : mStatus(NO_INIT),
- mIsTimed(false),
- mPreviousPriority(ANDROID_PRIORITY_NORMAL),
- mPreviousSchedulingGroup(SP_DEFAULT),
- mPausedPosition(0),
- mSelectedDeviceId(AUDIO_PORT_HANDLE_NONE),
- mPlaybackRateSet(false)
- {
- mAttributes.content_type = AUDIO_CONTENT_TYPE_UNKNOWN;
- mAttributes.usage = AUDIO_USAGE_UNKNOWN;
- mAttributes.flags = 0x0;
- strcpy(mAttributes.tags, "");
- }
我們可以看到,AudioTrack的無參構造方法只是進行了一些參數的初始化,那么,具體是AudioTrack初始化是進行在哪里呢?
我們再回到上面,發現jni層在創建完AudioTrack對象后,根據memoryMode的不同而進行了不同的AudioTrack->set()操作,只是因為AudioTrack提供2種不同的輸出方式(對內存的影響和要求不同)。我來看看看set中主要的操作:
- status_t AudioTrack::set(…){
- //……
- status_t status = createTrack_l();
- if (status != NO_ERROR) {
- if (mAudioTrackThread != 0) {
- mAudioTrackThread->requestExit(); // see comment in AudioTrack.h
- mAudioTrackThread->requestExitAndWait();
- mAudioTrackThread.clear();
- }
- return status;
- //……
- }
在AudioTrack的set()中,除了部分的參數判斷和設置之外,我們可以看到,他調用了自身的createTrack_l()進行了進一步的設置。
- status_t AudioTrack::createTrack_l()
- {
- const sp<IAudioFlinger>& audioFlinger = AudioSystem::get_audio_flinger();
- if (audioFlinger == 0) {
- ALOGE("Could not get audioflinger");
- return NO_INIT;
- }
- audio_io_handle_t output;
- audio_stream_type_t streamType = mStreamType;
- audio_attributes_t *attr = (mStreamType == AUDIO_STREAM_DEFAULT) ? &mAttributes : NULL;
- //……
- audio_offload_info_t tOffloadInfo = AUDIO_INFO_INITIALIZER;
- if (mPlaybackRateSet == true && mOffloadInfo == NULL && mFormat == AUDIO_FORMAT_PCM_16_BIT) {
- mOffloadInfo = &tOffloadInfo;
- }
- status_t status = AudioSystem::getOutputForAttr(attr, &output,
- (audio_session_t)mSessionId, &streamType, mClientUid,
- mSampleRate, mFormat, mChannelMask,
- mFlags, mSelectedDeviceId, mOffloadInfo);
- //……
- IAudioFlinger::track_flags_t trackFlags = IAudioFlinger::TRACK_DEFAULT;
- //……
- sp<IAudioTrack> track = audioFlinger->createTrack(streamType,
- mSampleRate,
- mFormat,
- mChannelMask,
- &temp,
- &trackFlags,
- mSharedBuffer,
- output,
- tid,
- &mSessionId,
- mClientUid,
- &status);
- //……
上面的代碼可以看出,AudioTrack從這里開始,與AudioFlinger等進行大量的交互:獲取句柄,獲取輸出,創建IAudioTrack指針對象等等。所以接下來,就是AudioFlinger的相關內容了。在這里,我們先簡單總結下AudioTrack的創建過程:
根據AudioTrack的性質,Java層在創建完成AudioTrack對象直接調用play()和write()操作,那么其實從另一方面我們可以猜想,在Java層創建完成AudioTrack之后,系統已經設置好輸出的設備等等操作,只等調用play()和write方法進行播放。所以為了驗證我們的猜想,接下來針對AudioFlinger&AudioSystem的相關具體分析驗證。
AudioFlinger&AudioPolicyService的控制過程
回到上面的內容,我們可以看到,AudioTrack在調用createTrack_l()的方法的時候,開始通過AudioSystem獲取output。所以下面我們來看看AudioSystem的getOutputForAttr():
- status_t AudioSystem::getOutputForAttr()
- {
- const sp<IAudioPolicyService>& aps = AudioSystem::get_audio_policy_service();
- if (aps == 0) return NO_INIT;
- return aps->getOutputForAttr(attr, output, session, stream, uid,
- samplingRate, format, channelMask,
- flags, selectedDeviceId, offloadInfo);
- }
從上面我們可以看到,AudioSystem只是作為一個過渡,然后通過獲取AudioPolicyService的句柄去getOutputForAttr()。我們繼續跟蹤AudioPolicyService的情況,會發現其實他只是在AudioPolicyService中也只是作為一個過渡,真正進行getOutputForAttr()的,在AudioPolicyManager之中。
- status_t AudioPolicyManager::getOutputForAttr()
- {
- //……
- *stream = streamTypefromAttributesInt(&attributes);
- sp<DeviceDescriptor> deviceDesc;
- for (size_t i = 0; i < mAvailableOutputDevices.size(); i++) {
- if (mAvailableOutputDevices[i]->getId() == selectedDeviceId) {
- deviceDesc = mAvailableOutputDevices[i];
- break;
- }
- }
- mOutputRoutes.addRoute(session, *stream, SessionRoute::SOURCE_TYPE_NA, deviceDesc, uid);
- //根據strategy獲取device
- routing_strategy strategy = (routing_strategy) getStrategyForAttr(&attributes);
- audio_devices_t device = getDeviceForStrategy(strategy, false /*fromCache*/);
- if ((attributes.flags & AUDIO_FLAG_HW_AV_SYNC) != 0) {
- flags = (audio_output_flags_t)(flags | AUDIO_OUTPUT_FLAG_HW_AV_SYNC);
- }
- *output = getOutputForDevice(device, session, *stream,
- samplingRate, format, channelMask,
- flags, offloadInfo);
- //……
在AudioPolicyManager的getOutputForAttr()中,我們可以發現關鍵點在strategy的獲取與device的獲取當中。而在這當中,關鍵的參數恰恰是在先前從java層一步一步封裝的過來的attributes。我們先來簡單看一下attributes這個參數的數據結構:
從audio_attributes_t的結構我們可以看出,audio_attributes_t保存着需要輸出音頻的應用的相關配置信息。
然后,根據剛剛的代碼,我們來了解一下strategy的獲取:
- uint32_t AudioPolicyManager::getStrategyForAttr(const audio_attributes_t *attr) {
- // flags to strategy mapping
- if ((attr->flags & AUDIO_FLAG_BEACON) == AUDIO_FLAG_BEACON) {
- return (uint32_t) STRATEGY_TRANSMITTED_THROUGH_SPEAKER;
- }
- if ((attr->flags & AUDIO_FLAG_AUDIBILITY_ENFORCED) == AUDIO_FLAG_AUDIBILITY_ENFORCED) {
- return (uint32_t) STRATEGY_ENFORCED_AUDIBLE;
- }
- // usage to strategy mapping
- return static_cast<uint32_t>(mEngine->getStrategyForUsage(attr->usage));
雖然在這里,會先對flags參數進行比較,但是,在實際上flags大部分時候都是0。所以最后,都是根據“mEngine->getStrategyForUsage(attr->usage)”去選擇StrategyForUsage。當然,再到下一步就到了就是switch和case的過程,這里就不繼續展開了。
在獲取到strategy之后,我們來看看Audio接着是怎么來確定device的。
先繼續看AudioPolicyManager的getDeviceForStrategy():
- audio_devices_t AudioPolicyManager::getDeviceForStrategy(routing_strategy strategy,
- bool fromCache)
- {
- // Routing
- // see if we have an explicit route
- // scan the whole RouteMap, for each entry, convert the stream type to a strategy
- // (getStrategy(stream)).
- // if the strategy from the stream type in the RouteMap is the same as the argument above,
- // and activity count is non-zero
- // the device = the device from the descriptor in the RouteMap, and exit.
- for (size_t routeIndex = 0; routeIndex < mOutputRoutes.size(); routeIndex++) {
- sp<SessionRoute> route = mOutputRoutes.valueAt(routeIndex);
- routing_strategy strat = getStrategy(route->mStreamType);
- bool strategyMatch = (strat == strategy) ||
- ((strategy == STRATEGY_ACCESSIBILITY) &&
- ((mEngine->getStrategyForUsage(
- AUDIO_USAGE_ASSISTANCE_ACCESSIBILITY) == strat) ||
- (strat == STRATEGY_MEDIA)));
- if (strategyMatch && route->isActive()) {
- return route->mDeviceDescriptor->type();
- }
- }
- if (fromCache) {
- ALOGVV("getDeviceForStrategy() from cache strategy %d, device %x",
- strategy, mDeviceForStrategy[strategy]);
- return mDeviceForStrategy[strategy];
- }
- return mEngine->getDeviceForStrategy(strategy);
- }
調用AudioPolicyManager的getDeviceForStrategy()的時候,一般會先查下一下當前的RouteMap,看看有沒有匹配的情況的。但由於我們新申請一個output的時候,傳入的參數是false,所以這個時候,是會直接通過mEngine去直接獲取device。
而在mEngine中,getDeviceForStrategy()又是一堆的選擇判斷,然后返回設備:
- audio_devices_t Engine::getDeviceForStrategy(routing_strategy strategy) const
- {
- const DeviceVector &availableOutputDevices = mApmObserver->getAvailableOutputDevices();
- const DeviceVector &availableInputDevices = mApmObserver->getAvailableInputDevices();
- const SwAudioOutputCollection &outputs = mApmObserver->getOutputs();
- uint32_t device = AUDIO_DEVICE_NONE;
- uint32_t availableOutputDevicesType = availableOutputDevices.types();
- switch (strategy) {
- //……
- case STRATEGY_MEDIA: {
- uint32_t device2 = AUDIO_DEVICE_NONE;
- if (isInCall() && (device == AUDIO_DEVICE_NONE)) {
- // when in call, get the device for Phone strategy
- device = getDeviceForStrategy(STRATEGY_PHONE);
- break;
- }
- if (strategy != STRATEGY_SONIFICATION) {
- // no sonification on remote submix (e.g. WFD)
- if (availableOutputDevices.getDevice(AUDIO_DEVICE_OUT_REMOTE_SUBMIX, String8("0")) != 0) {
- device2 = availableOutputDevices.types() & AUDIO_DEVICE_OUT_REMOTE_SUBMIX;
- }
- }
- if (isInCall() && (strategy == STRATEGY_MEDIA)) {
- device = getDeviceForStrategy(STRATEGY_PHONE);
- break;
- }
- if ((device2 == AUDIO_DEVICE_NONE) &&
- (mForceUse[AUDIO_POLICY_FORCE_FOR_MEDIA] != AUDIO_POLICY_FORCE_NO_BT_A2DP) &&
- (outputs.getA2dpOutput() != 0)) {
- device2 = availableOutputDevicesType & AUDIO_DEVICE_OUT_BLUETOOTH_A2DP;
- if (device2 == AUDIO_DEVICE_NONE) {
- device2 = availableOutputDevicesType & AUDIO_DEVICE_OUT_BLUETOOTH_A2DP_HEADPHONES;
- }
- //……
- ALOGVV("getDeviceForStrategy() strategy %d, device %x", strategy, device);
- return device;
- }
我們就其中一個strategty(STRATEGY_MEDIA)來具體看看Audio系統的選擇輸出設備:
1) 首先我們會獲取當前存在的設備集合availableOutputDevices
2) 然后根據傳入的strategty類型進行匹配選擇
3) 在選擇之前會先檢測是否處於特殊情況下(如通話中)
4) 最后按照優先級匹配設備。
然后就這樣,選擇設備的流程就此結束。簡單來說,選擇設備的流程,主要是幾個參數一步一步去確定然后最后確定合適的設備。具體選擇設備的簡單流程如圖: