Android中的PCM裝置

檢視pcm裝置列表

如果手機的音訊系統正常工作，我們可以通過adb去檢視系統中的所有音訊裝置檔案。如下圖所示：

pcm裝置檔案的訪問

檢視pcm裝置檔案的屬性，可看到它們都是字元型裝置：

對於普通的字元型裝置，我們都是通過系統呼叫open/read/write/close來訪問，有些裝置支援隨機訪問，我們還可以使用lseek呼叫。pcm裝置檔案也是類似，不一樣的是，我們可以使用open/close來開啟/關閉裝置，讀取/寫入檔案卻不是通過read/write，而都是通過ioctl來操作的。

在android audio hal層中，是通過tinyalsa來訪問pcm裝置檔案的。tinyalsa封裝了一系列介面用於pcm裝置的訪問，這些介面被audio hal呼叫以後，最終又會被frameworks呼叫。介面包括：

struct pcm pcm_open(unsigned int card, unsigned int device, unsinged int flags, struct pcm_config config)

int pcm_close(struct pcm* pcm)

int pcm_write(struct pcm pcm, const void data, unsigned int count)

int pcm_read(struct pcm* pcm, void* data, unsigned int count)

還有很多其他介面，但我們不需要關心那些細節，除非想要再造一遍輪子。

從pcm_open這個介面可以看到，它通過幾個引數獲得了乙個控制代碼，之後所有的操作都通過這個控制代碼來完成。這些引數裡面，card代表第幾塊音效卡，device就是上面提到的device index，它跟驅動中配置的dai link的次序有關，flags引數中會指明這個裝置是capture型別還是playback型別。通過這3個引數，就可以找到對應的pcm裝置檔案，例如 /dev/snd/pcmc0d5p，然後就可以去獲取操作它的控制代碼，然後做更多的操作。

pcm裝置的管理 —— pcm id

如果我們檢視不同型號的手機上的音訊裝置列表，可以看到它們幾乎都是不一樣的，有的手機裝置檔案多，有的手機裝置檔案少。實際上不只是裝置檔案個數的差別，還有可能出現在a型號手機上speaker對應的pcm裝置檔案是/dev/snd/pcmc0d4p，而在b型號手機上speaker對應的pcm裝置檔案卻是/dev/snd/pcmc0d7p。因此，audio hal中需要考慮到這種場景差異的影響。

我們已經知道，使用tinyalsa介面訪問pcm裝置的時候，需要知道裝置的id，這個id我們稱為pcm id，那麼如何知道某乙個裝置例如speaker的pcm id呢？另外，在不接耳機的時候，我們希望聲音從speaker出來，這時候需要知道的是speaker的pcm id，如果接了耳機，我們又希望聲音從耳機出來，這時候需要知道的是耳機的pcm id。

針對這些問題、需求，audio hal的設計是根據使用場景（usecase）來決定要使用哪些裝置的，即為各個usecase分別定義好要使用的pcm裝置的id。frameworks通過usecase來指定pcm裝置，而audio hal通過usecase來找到pcm裝置檔案路徑。

如下圖所示，audio hal通過pcm_device_table這張表完成usecase到pcm id的對映。因此，pcm裝置的管理實際上就是管理這張對映表。

usecase與pcm id的對映關係可以通過配置檔案來修改，這樣的好處就是所有產品可以使用同一套**，差異的地方可以通過控制配置檔案的內容就可以簡單的區分開來，audio hal會解析這個配置檔案，然後更新對映表內容。使用adb shell cat /system/etc/audio_platform_info.xml可以看到如下配置：

如上圖，就會把usecase_audio_playback_low_latency這個使用場景的pcm id更新為12。其他應用場景的pcm id更新也是類似。

Android中的PCM裝置

Android中的PCM裝置

PCM裝置的E1接頭

PCM裝置的E1接頭

Android中的PCM裝置

Android中的PCM裝置

PCM裝置的E1接頭

PCM裝置的E1接頭

相關推薦