手機可以說是現(xiàn)在人日常生活中最離不開的電子設備了。它自誕生以來，從模擬的發(fā)展到數(shù)字的，從1G發(fā)展到目前的4G以及不久將來的5G，從最初的只有唯一的功能（打電話）發(fā)展到目前的全功能，從功能機（feature phone）發(fā)展到智能機（smart phone），可謂變化巨大。對于手機上的音頻來說，剛開始只有語音通信功能，現(xiàn)在不僅語音通信，還可以聽音樂、錄音、智能語音（語音輸入/語音交互）等。智能手機中的音頻場景眾多，可以說是手機多媒體系統(tǒng)中最復雜的子系統(tǒng)了。今天我們就談談Android智能手機上的音頻。

先從硬件談起吧。下圖是android智能手機中目前主流的跟音頻相關的硬件框圖。

上圖中AP是應用處理器（applicaTIon processor），在上面主要運行的是操作系統(tǒng)（OS，例如android）和應用程序。CP是通信處理器（communicaTIon processor），也叫基帶處理器（baseband processor，BP）或者modem，上面主要處理跟通信相關的，比如手機信號好不好就跟它相關。Audio DSP，顧名思義，就是一個處理音頻的DSP。我在剛做手機的時候就很納悶現(xiàn)在AP處理器頻率那么高，音頻處理（尤其是語音）CPU load 不高，AP上完全可以處理，為啥還要額外加一個音頻DSP處理音頻呢，這不是增加了成本嗎？隨著做的深入，知道了這主要是出于功耗的考慮。功耗是手機上的一個重要指標，也是過認證的必選項，它決定了手機的續(xù)航能力。在手機電池技術沒有獲得突破的現(xiàn)在，要想續(xù)航能力強，就得降功耗。音頻中的打電話和聽音樂是手機上的最主要功能之一，必須在這兩種場景下降功耗。怎么降呢？就是加一塊專門處理音頻的DSP，在打電話和聽音樂時讓AP在絕大多數(shù)時間都出于sleep狀態(tài)，這樣功耗就降下來了。 AP、CP和audio DSP之間通過IPC（inter-processor communicaTIon）通信，交互控制消息和音頻數(shù)據。通常AP、CP和audio DSP（當然還包括其他功能的處理器）集成在一個芯片內，形成一個SOC（system on chip，片上系統(tǒng)）。此外有一個主要用于音頻采集和播放的硬件codec芯片，它受AP控制（使能以及選擇不同音頻路徑等，主要是配置寄存器），與audio DSP通過I2S總線交換音頻數(shù)據。連著硬件codec的是各種外設，有MIC（現(xiàn)在主流的是雙MIC方案）、earpiece（聽筒）、speaker（揚聲器）、有線耳機（有三段式四段式兩種，三段式沒有MIC功能，四段式有）等。但是藍牙耳機比較特殊，它是直接通過I2S總線與audio DSP連接的，主要是因為音頻的采集和播放在藍牙芯片里都有了。當用藍牙耳機聽音樂時，音頻碼流在AP上解碼成PCM數(shù)據用A2DP協(xié)議經過UART直接送給藍牙耳機播放，而不是經過audio DSP通過IIS總線送給藍牙耳機播放。

再來看軟件。音頻相關的軟件在三個處理器（AP/CP/audio DSP）上都有，先看AP上的音頻軟件。本文講的是Android智能手機上的音頻，運行的當然就是Android系統(tǒng)了，Android系統(tǒng)就運行在AP上。Android里有mulTImedia framework，audio是其中的一部分，AP上audio部分的軟件框圖如下：

Android音頻軟件分不同的層，主要有kernel/user/Framework/JNI/Java。從底層kernel向上講吧。Android的核用的是Linux的。Linux上音頻相關的子系統(tǒng)叫ALSA，包括kernel space和user space兩部分。Kernel space里是音頻驅動，user space里主要是提供API給應用程序調用。Android的音頻驅動跟Linux是一樣的，在user space里對ALSA進行了裁剪形成了tinyalsa。關于這些我在前面的文章（ 音頻的采集和播放）里簡單描述過，有興趣可以去看看。同時user space里還有音頻軟件編解碼的各種庫，包括音樂的（MP3/AAC等）和語音的（AMR-NB/AMR-WB等）。再向上就是Framework，里面模塊眾多，主要有NuPlayer/stageFright Record/openMAX/AudioFlinger等，網上講audio Framework的文章太多了，這里就不細講了。Auido HAL（Hardware Adapter Layer，硬件適配層）也在這一層。Framework上層是JNI（Java Native Interface），提供接口供Java調用，提供的接口主要有MediaRecorder/MediaPlayer/AudioTrack/AudioRecorder。最上層是Java層，也就是各種帶有音頻功能的APP（調用提供的API）了。

再看audio DSP上的音頻軟件。下圖是audio的軟件框圖：

從上圖看出，模塊主要有codec（MP3/AAC/AMR/EVS等）、前處理（AGC/ANS/AGC等）、后處理（EQ/AGC/ANS 等）、重采樣（SRC）、混音（MIX）、從DMA獲取采集到的音頻數(shù)據（CAPTURE）、將音頻數(shù)據送給DMA后播放（PLAY）等，當然還有接收和發(fā)送給其他處理器的音頻數(shù)據處理等，AP和CP都要與audio DSP交互語音數(shù)據。

最后看CP上的音頻軟件，它上面處理的就是跟語音通信相關的。2/3G跟4G完全處理完全不一樣（2/3G是CS call，會有專用的信道處理語音。4G是一個純IP的網絡，是PS call），會有兩套處理機制。我沒做過CP上的音頻處理（我主要做audio DSP上的音頻處理，偶爾做些AP上的音頻處理），對2/3G下的語音處理不熟悉，對4G下的語音處理了解。下圖是4G下的音頻軟件處理框圖：

主要分兩大部分，IMS stub，處理IMS（IP Multimedia Subsystem， IP多媒體子系統(tǒng)）中的語音數(shù)據相關的（IMS 控制協(xié)議相關的在AP中處理）。Audio，對IMS中語音數(shù)據的pack/unpack以及與audio DSP的交互等。

智能手機中音頻場景眾多，有些場景中三個處理器中的音頻軟件都會涉及，比如打電話，AP上主要是處理一些控制上的邏輯，CP和audio DSP上不僅有控制邏輯，還有語音數(shù)據的處理，上行是先從MIC采集到語音經Audio DSP處理后變成碼流發(fā)給CP，CP處理后經過空口發(fā)到網絡上，下行是CP從空口拿語音碼流，處理后發(fā)給audio DSP，audio DSP再解碼后發(fā)給codec芯片直到外設播放出來。有些場景只涉及部分處理器中的音頻軟件，比如在播放音樂時CP上的音頻軟件就不會涉及，在用APP播放音樂時，是音樂從AP上傳到audio DSP上，經過相關處理后通過外設播放出來。在下一篇文章中我會詳細的描述在各種音頻場景中音頻數(shù)據的流向。