動(dòng)開(kāi)發(fā)：音頻控件類(lèi)型、注冊(cè)與DAPM調(diào)試實(shí)戰(zhàn))
1. 從一次耳機(jī)雜音排查說(shuō)起ASoC控件到底在管什么前陣子幫朋友調(diào)一塊基于i.MX6ULL的工控板音頻部分用的是WM8960編解碼器?，F(xiàn)象很怪系統(tǒng)能枚舉出聲卡aplay也能跑但插上耳機(jī)后左聲道一直有沙沙底噪右聲道正常。一開(kāi)始懷疑是硬件布線(xiàn)示波器量了半天沒(méi)發(fā)現(xiàn)問(wèn)題。后來(lái)用amixer把播放通路的幾個(gè)開(kāi)關(guān)逐個(gè)關(guān)掉發(fā)現(xiàn)只要關(guān)掉Left Output Mixer PCM這個(gè)控件底噪立刻消失。問(wèn)題根因是PCM數(shù)據(jù)在左聲道混音器里被重復(fù)疊加了一次而驅(qū)動(dòng)里這個(gè)控件的默認(rèn)值設(shè)錯(cuò)了。這件事讓我再次意識(shí)到ASoC編解碼器驅(qū)動(dòng)里音頻控件kcontrol才是真正決定聲音長(zhǎng)什么樣的那一層。寄存器配置、時(shí)鐘樹(shù)、DMA這些固然重要但用戶(hù)空間能感知到的音量、通路、靜音、增益全部通過(guò)控件暴露出來(lái)?？丶O(shè)計(jì)得對(duì)不對(duì)直接決定了這顆codec能不能被正常使用。這篇內(nèi)容面向的是已經(jīng)寫(xiě)過(guò)基礎(chǔ)字符設(shè)備驅(qū)動(dòng)、正在往ASoC方向深入的嵌入式Linux開(kāi)發(fā)者也適合那些能跑通聲卡但搞不清amixer里那一堆開(kāi)關(guān)到底對(duì)應(yīng)什么的工程師。我會(huì)圍繞編解碼器驅(qū)動(dòng)中音頻控件的開(kāi)發(fā)把控件類(lèi)型、注冊(cè)流程、與DAPM的關(guān)系、調(diào)試手段這些核心要點(diǎn)拆開(kāi)講盡量把我在實(shí)際項(xiàng)目里踩過(guò)的坑和總結(jié)的經(jīng)驗(yàn)都放進(jìn)來(lái)。需要先明確一個(gè)概念邊界ASoCALSA System on Chip把音頻系統(tǒng)拆成三塊——Machine驅(qū)動(dòng)負(fù)責(zé)把CPU DAI和Codec DAI綁在一起Platform驅(qū)動(dòng)管DMA和CPU側(cè)DAICodec驅(qū)動(dòng)管編解碼芯片本身。音頻控件主要誕生在Codec驅(qū)動(dòng)里少數(shù)在Machine驅(qū)動(dòng)里定義。所以下面討論的控件開(kāi)發(fā)默認(rèn)是在Codec驅(qū)動(dòng)的語(yǔ)境下。2. 音頻控件的四種基本類(lèi)型與選型邏輯2.1 從用戶(hù)能調(diào)什么反推控件類(lèi)型很多人寫(xiě)控件是照著芯片手冊(cè)的寄存器表一個(gè)個(gè)抄抄完發(fā)現(xiàn)amixer里冒出來(lái)幾十個(gè)控件用戶(hù)根本不知道該動(dòng)哪個(gè)。正確的思路應(yīng)該反過(guò)來(lái)先想清楚用戶(hù)空間需要調(diào)整哪些量再?zèng)Q定用哪種控件類(lèi)型去封裝。ALSA的snd_kcontrol_new結(jié)構(gòu)體里iface、name、info、get、put這幾個(gè)字段決定了控件的類(lèi)型和行為。按功能劃分編解碼器驅(qū)動(dòng)里最常用的是四類(lèi)控件類(lèi)型典型用途關(guān)鍵回調(diào)用戶(hù)空間表現(xiàn)音量/增益調(diào)節(jié)PCM、ADC、DAC增益snd_ctl_boolean_mono_info等帶數(shù)值范圍的滑動(dòng)條開(kāi)關(guān)靜音、通路使能snd_ctl_boolean_mono_infoon/off開(kāi)關(guān)枚舉輸入源選擇、濾波器模式snd_ctl_enum_info下拉列表路由混音器通路連接snd_soc_dapm_*由DAPM自動(dòng)管理選型的核心判斷標(biāo)準(zhǔn)是這個(gè)量是連續(xù)可調(diào)的、二值的、還是多選一的。連續(xù)可調(diào)就用SNDRV_CTL_ELEM_IFACE_MIXER配合info回調(diào)返回范圍二值用SNDRV_CTL_ELEM_IFACE_MIXER配合布爾info多選一用枚舉。路由類(lèi)控件比較特殊它不直接暴露給用戶(hù)而是交給DAPM去管理后面單獨(dú)講。2.2 音量控件的范圍計(jì)算別直接抄手冊(cè)音量控件最容易出錯(cuò)的地方是范圍計(jì)算。芯片手冊(cè)通常給的是寄存器值到dB的對(duì)應(yīng)關(guān)系比如WM8960的耳機(jī)輸出增益寄存器0x02的bit[6:0]對(duì)應(yīng)0到127每步0.5dB。但你不能直接把0到127丟給用戶(hù)空間因?yàn)橛脩?hù)看到的是0到127這種裸數(shù)值沒(méi)有物理意義不同通路的增益步進(jìn)不一樣混在一起很亂有些芯片的增益是反的寄存器值越大增益越小。我的做法是在info回調(diào)里把范圍映射成dB值或者至少映射成有意義的百分比。具體實(shí)現(xiàn)時(shí)snd_ctl_elem_info的value.integer.min和max填映射后的值get和put回調(diào)里做雙向轉(zhuǎn)換。舉個(gè)例子如果寄存器0到127對(duì)應(yīng)-17.25dB到30dB步進(jìn)0.375dB那可以這樣處理static int wm8960_hp_vol_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { uinfo-type SNDRV_CTL_ELEM_TYPE_INTEGER; uinfo-count 2; /* 左右聲道 */ uinfo-value.integer.min 0; uinfo-value.integer.max 127; uinfo-value.integer.step 1; return 0; }這里我保留了原始寄存器范圍但在控件名字里標(biāo)注了單位比如Headphone Playback Volume讓用戶(hù)知道這是寄存器級(jí)調(diào)節(jié)。如果要做dB映射就在get里把寄存器值轉(zhuǎn)成dB再返回。兩種做法各有取舍保留原始值實(shí)現(xiàn)簡(jiǎn)單、調(diào)試直觀映射成dB對(duì)用戶(hù)友好但代碼復(fù)雜。我個(gè)人的經(jīng)驗(yàn)是調(diào)試階段保留原始值產(chǎn)品化階段再考慮映射因?yàn)檎{(diào)試時(shí)你更關(guān)心寄存器現(xiàn)在是多少。2.3 枚舉控件的坑字符串?dāng)?shù)組的生命周期枚舉控件用來(lái)做多選一比如輸入源選擇Line In / Mic / PCM。它的info回調(diào)需要返回一個(gè)字符串?dāng)?shù)組這里有個(gè)非常隱蔽的坑字符串?dāng)?shù)組必須是靜態(tài)的或者生命周期覆蓋整個(gè)控件存在期。我見(jiàn)過(guò)有人在info回調(diào)里用局部數(shù)組結(jié)果amixer讀出來(lái)的選項(xiàng)是亂碼或者空。正確的寫(xiě)法是把字符串?dāng)?shù)組定義成static const char *放在文件作用域static const char *wm8960_input_texts[] { Line In, Mic, PCM }; static int wm8960_input_enum_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { return snd_ctl_enum_info(uinfo, 1, 3, wm8960_input_texts); }snd_ctl_enum_info的第二個(gè)參數(shù)是通道數(shù)第三個(gè)是選項(xiàng)個(gè)數(shù)。注意選項(xiàng)個(gè)數(shù)要和數(shù)組長(zhǎng)度嚴(yán)格一致多一個(gè)少一個(gè)都會(huì)導(dǎo)致越界讀。這個(gè)函數(shù)是ALSA提供的輔助函數(shù)比自己填uinfo-value.enumerated.item省事得多。2.4 開(kāi)關(guān)控件與靜音別把兩者混為一談開(kāi)關(guān)控件看起來(lái)最簡(jiǎn)單但靜音和通路開(kāi)關(guān)是兩個(gè)不同的東西。靜音Mute是在信號(hào)鏈末端把輸出拉低通路開(kāi)關(guān)Switch是控制某段電路是否導(dǎo)通。有些芯片兩者都有有些只有其一。寫(xiě)驅(qū)動(dòng)時(shí)要看清楚手冊(cè)別把靜音寄存器當(dāng)成通路開(kāi)關(guān)來(lái)用。另外開(kāi)關(guān)控件的get回調(diào)要返回當(dāng)前實(shí)際狀態(tài)而不是你上次put進(jìn)去的值。因?yàn)樾酒赡芤驗(yàn)槠渌虮热缟想姀?fù)位、DAPM自動(dòng)管理改變了寄存器狀態(tài)。每次get都去讀一次寄存器這是最穩(wěn)妥的做法雖然多一次I2C讀但避免了狀態(tài)不一致。3. 控件注冊(cè)的完整鏈路從snd_kcontrol_new到用戶(hù)空間3.1 注冊(cè)時(shí)機(jī)為什么不能在probe里一股腦全注冊(cè)Codec驅(qū)動(dòng)的probe函數(shù)里通常會(huì)調(diào)用snd_soc_add_component_controls或者把控件數(shù)組掛到snd_soc_component_driver的controls字段上。后者是推薦做法因?yàn)锳SoC框架會(huì)在合適的時(shí)機(jī)統(tǒng)一注冊(cè)。但這里有個(gè)時(shí)機(jī)問(wèn)題DAPM的widget和route必須在控件注冊(cè)之前或者同時(shí)建立好否則控件可能引用到不存在的通路。我一般把控件數(shù)組、DAPM widget數(shù)組、route數(shù)組都定義成靜態(tài)的然后在component_driver里一次性?huà)焐先プ尶蚣苋ヌ幚眄樞?。static const struct snd_soc_component_driver wm8960_component_driver { .controls wm8960_snd_controls, .num_controls ARRAY_SIZE(wm8960_snd_controls), .dapm_widgets wm8960_dapm_widgets, .num_dapm_widgets ARRAY_SIZE(wm8960_dapm_widgets), .dapm_routes wm8960_dapm_routes, .num_dapm_routes ARRAY_SIZE(wm8960_dapm_routes), };ARRAY_SIZE這個(gè)宏一定要用別手寫(xiě)數(shù)字。我見(jiàn)過(guò)有人改了控件數(shù)組但忘了改num_controls結(jié)果多出來(lái)的控件沒(méi)注冊(cè)或者注冊(cè)了越界的內(nèi)存現(xiàn)象是amixer里少幾個(gè)控件或者內(nèi)核直接oops。3.2 控件命名規(guī)范用戶(hù)空間靠名字找控件控件的name字段是用戶(hù)空間識(shí)別控件的唯一標(biāo)識(shí)。amixer、alsactl、各種音頻框架都靠名字來(lái)匹配。命名不規(guī)范會(huì)導(dǎo)致用戶(hù)空間找不到控件音量調(diào)不了同名控件沖突后注冊(cè)的覆蓋先注冊(cè)的自動(dòng)化測(cè)試腳本匹配失敗。ALSA有一套約定俗成的命名規(guī)范核心是**源 方向 功能**三段式比如Headphone Playback Volume—— 耳機(jī)播放音量Capture Volume—— 錄音音量Left Output Mixer PCM—— 左輸出混音器的PCM輸入開(kāi)關(guān)ADC PCM Capture Volume—— ADC到PCM的錄音音量方向詞用Playback和Capture功能詞用Volume、Switch、Route、Mux。別自創(chuàng)命名比如寫(xiě)成hp_vol雖然能注冊(cè)成功但用戶(hù)空間的通用工具可能識(shí)別不了而且可讀性差。3.3 私有數(shù)據(jù)的傳遞kcontrol到codec的橋梁控件的get和put回調(diào)里需要訪(fǎng)問(wèn)codec的寄存器。怎么從kcontrol拿到codec的指針標(biāo)準(zhǔn)做法是用snd_soc_component_get_drvdatastatic int wm8960_hp_vol_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_component *component snd_kcontrol_chip(kcontrol); struct wm8960_priv *wm8960 snd_soc_component_get_drvdata(component); /* 讀寄存器填ucontrol */ ... }snd_kcontrol_chip返回的是snd_soc_component指針在ASoC語(yǔ)境下再通過(guò)get_drvdata拿到驅(qū)動(dòng)私有數(shù)據(jù)。這個(gè)鏈路要記牢因?yàn)閹缀趺總€(gè)回調(diào)都要用。注意早期內(nèi)核版本用的是snd_soc_kcontrol_codec新版本改成了snd_soc_component。移植驅(qū)動(dòng)時(shí)要注意內(nèi)核版本差異別直接抄老代碼。3.4 寄存器訪(fǎng)問(wèn)的原子性put回調(diào)里的讀改寫(xiě)put回調(diào)里經(jīng)常要做讀-改-寫(xiě)讀出寄存器當(dāng)前值改掉某幾位再寫(xiě)回去。這個(gè)操作在并發(fā)場(chǎng)景下可能出問(wèn)題比如兩個(gè)進(jìn)程同時(shí)調(diào)amixer。ASoC框架對(duì)控件的put回調(diào)有加鎖保護(hù)但如果你在put里訪(fǎng)問(wèn)了多個(gè)寄存器或者訪(fǎng)問(wèn)了非控件管理的寄存器就要自己加鎖。我的習(xí)慣是在put里盡量只操作一個(gè)寄存器如果必須操作多個(gè)用snd_soc_component_read和snd_soc_component_write這對(duì)函數(shù)它們內(nèi)部有緩存和鎖機(jī)制。別直接用i2c_smbus_read_byte_data繞過(guò)ASoC的寄存器緩存否則DAPM的狀態(tài)會(huì)和實(shí)際寄存器不一致。4. DAPM與控件的關(guān)系為什么你的控件不生效4.1 DAPM自動(dòng)管理了大部分通路很多人寫(xiě)完控件后發(fā)現(xiàn)amixer里明明把某個(gè)開(kāi)關(guān)打開(kāi)了但聲音還是出不來(lái)。原因往往是DAPM在背后自動(dòng)管理了通路你手動(dòng)開(kāi)的開(kāi)關(guān)被DAPM關(guān)掉了。DAPMDynamic Audio Power Management是ASoC的核心機(jī)制它根據(jù)當(dāng)前的音頻流狀態(tài)自動(dòng)開(kāi)關(guān)音頻通路上各個(gè)widget的電源。一個(gè)widget只有在被需要的時(shí)候才會(huì)通電。比如播放時(shí)從PCM到DAC到輸出混音器到耳機(jī)這條路徑上的widget會(huì)被自動(dòng)上電不在這條路徑上的比如錄音通路會(huì)被斷電。所以如果你把某個(gè)通路開(kāi)關(guān)定義成了普通kcontrolDAPM不認(rèn)識(shí)它就不會(huì)在需要的時(shí)候打開(kāi)它。正確的做法是把通路開(kāi)關(guān)定義成DAPM widget讓DAPM去管理。4.2 什么時(shí)候該用DAPM widget什么時(shí)候用kcontrol判斷標(biāo)準(zhǔn)很簡(jiǎn)單這個(gè)開(kāi)關(guān)是否參與音頻通路的自動(dòng)電源管理。如果是某段電路是否導(dǎo)通、某個(gè)混音器輸入是否使能用DAPM widgetSND_SOC_DAPM_MIXER、SND_SOC_DAPM_SWITCH等如果是用戶(hù)手動(dòng)調(diào)節(jié)的音量、用戶(hù)手動(dòng)選擇的輸入源用kcontrol如果是靜音兩者都可以但用kcontrol更直觀因?yàn)橛脩?hù)需要看到靜音狀態(tài)。我見(jiàn)過(guò)一個(gè)典型錯(cuò)誤把Left Output Mixer PCM這個(gè)混音器輸入開(kāi)關(guān)定義成了普通kcontrol。結(jié)果播放時(shí)DAPM不知道要打開(kāi)它聲音出不來(lái)用戶(hù)手動(dòng)打開(kāi)后停止播放再播放DAPM又把它關(guān)了。改成SND_SOC_DAPM_MIXER的輸入后DAPM自動(dòng)管理問(wèn)題解決。4.3 widget與kcontrol的命名對(duì)應(yīng)關(guān)系DAPM widget和kcontrol在用戶(hù)空間的表現(xiàn)不同widget通常不直接暴露除非用dapm調(diào)試接口kcontrol會(huì)出現(xiàn)在amixer里。但它們的名字在驅(qū)動(dòng)內(nèi)部要能對(duì)應(yīng)上因?yàn)閞oute數(shù)組里用名字來(lái)連接widget。比如static const struct snd_soc_dapm_widget wm8960_dapm_widgets[] { SND_SOC_DAPM_MIXER(Left Output Mixer, WM8960_POWER1, 5, 0, wm8960_left_mixer_controls, ARRAY_SIZE(wm8960_left_mixer_controls)), ... }; static const struct snd_soc_dapm_route wm8960_dapm_routes[] { { Left Output Mixer, PCM Playback Switch, Left DAC }, ... };route里的第二個(gè)參數(shù)是widget的輸入名要和mixer controls里的名字對(duì)應(yīng)。這個(gè)對(duì)應(yīng)關(guān)系錯(cuò)了DAPM就建不起通路現(xiàn)象是聲音出不來(lái)或者通路不完整。4.4 用debugfs看DAPM狀態(tài)調(diào)試DAPM最有效的手段是debugfs。掛載debugfs后/sys/kernel/debug/asoc/card/dapm/下面有每個(gè)widget的狀態(tài)。播放時(shí)看哪些widget是On哪些是Off就能判斷通路是否正確建立。mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/asoc/*/dapm/Left\ Output\ Mixer輸出里會(huì)顯示widget的電源狀態(tài)、輸入輸出連接、當(dāng)前是否在活動(dòng)路徑上。這個(gè)信息比猜寄存器值有用得多。我調(diào)音頻通路問(wèn)題時(shí)第一步就是看DAPM狀態(tài)基本能定位到是哪個(gè)widget沒(méi)連上。5. 調(diào)試與驗(yàn)證讓控件真正可控5.1 amixer的常用操作與輸出解讀amixer是驗(yàn)證控件最直接的工具。幾個(gè)常用命令amixer controls # 列出所有控件 amixer contents # 列出控件及當(dāng)前值 amixer sget Headphone Playback Volume # 讀某個(gè)控件 amixer sset Headphone Playback Volume 80% # 設(shè)某個(gè)控件 amixer sset Left Output Mixer PCM on # 開(kāi)某個(gè)開(kāi)關(guān)amixer contents的輸出里每個(gè)控件會(huì)顯示numid、iface、name、type、access、當(dāng)前值。重點(diǎn)看type和accesstype是INTEGER、BOOLEAN、ENUMERATED之一access里有rw表示可讀寫(xiě)。如果某個(gè)控件顯示type不對(duì)或者access是r只讀說(shuō)明info回調(diào)或者put回調(diào)有問(wèn)題。5.2 用alsactl保存和恢復(fù)控件狀態(tài)產(chǎn)品化時(shí)控件狀態(tài)需要在開(kāi)機(jī)時(shí)恢復(fù)。alsactl store把當(dāng)前所有控件狀態(tài)存到/var/lib/alsa/asound.statealsactl restore恢復(fù)。這個(gè)機(jī)制依賴(lài)控件的名字和numid穩(wěn)定。如果你改了控件名字或者增刪了控件舊的state文件會(huì)失效需要重新store。我遇到過(guò)一個(gè)問(wèn)題驅(qū)動(dòng)里控件注冊(cè)順序變了導(dǎo)致numid變化alsactl restore把值設(shè)到了錯(cuò)誤的控件上。解決辦法是保證控件注冊(cè)順序穩(wěn)定或者在state文件里用名字而不是numid來(lái)匹配alsactl默認(rèn)用名字但有些版本會(huì)混用。5.3 常見(jiàn)問(wèn)題排查表現(xiàn)象可能原因排查手段amixer里看不到控件控件數(shù)組沒(méi)掛到component_driver或num_controls不對(duì)檢查component_driver定義看dmesg有無(wú)注冊(cè)失敗日志控件能讀不能寫(xiě)put回調(diào)返回錯(cuò)誤或access沒(méi)設(shè)成rw看put回調(diào)返回值檢查info里access字段設(shè)了值但聲音不變控件沒(méi)連到實(shí)際寄存器或DAPM覆蓋了讀寄存器確認(rèn)值變了看DAPM狀態(tài)聲音有底噪混音器重復(fù)疊加或增益設(shè)置不當(dāng)逐個(gè)關(guān)控件定位看混音器route播放時(shí)控件自動(dòng)變DAPM自動(dòng)管理了該控件把控件改成DAPM widget5.4 一個(gè)真實(shí)的排查案例回到開(kāi)頭那個(gè)左聲道底噪問(wèn)題。排查過(guò)程是這樣的amixer contents看所有控件發(fā)現(xiàn)Left Output Mixer PCM和Right Output Mixer PCM都在值都是on關(guān)掉左聲道的PCM輸入底噪消失說(shuō)明問(wèn)題在左混音器看DAPM route發(fā)現(xiàn)左混音器有兩條輸入一條來(lái)自L(fǎng)eft DAC一條來(lái)自Right DAC用于單聲道轉(zhuǎn)立體聲檢查驅(qū)動(dòng)代碼發(fā)現(xiàn)route里錯(cuò)誤地把Right DAC也連到了Left Output Mixer導(dǎo)致右聲道信號(hào)混進(jìn)了左聲道刪掉那條錯(cuò)誤的route問(wèn)題解決。這個(gè)案例說(shuō)明控件本身沒(méi)問(wèn)題問(wèn)題在route定義。DAPM的route數(shù)組是音頻通路的接線(xiàn)圖接錯(cuò)一根線(xiàn)聲音就不對(duì)。調(diào)試時(shí)要把route和芯片手冊(cè)的通路圖對(duì)照著看。6. 從能用到好用控件設(shè)計(jì)的進(jìn)階經(jīng)驗(yàn)6.1 控件粒度別太細(xì)也別太粗控件粒度是個(gè)權(quán)衡。太細(xì)用戶(hù)空間冒出上百個(gè)控件用戶(hù)懵太粗用戶(hù)想調(diào)某個(gè)具體增益調(diào)不了。我的經(jīng)驗(yàn)是按用戶(hù)會(huì)獨(dú)立調(diào)節(jié)的量來(lái)劃分每個(gè)輸出通路的音量單獨(dú)一個(gè)控件每個(gè)輸入源的選擇單獨(dú)一個(gè)枚舉控件混音器的每個(gè)輸入開(kāi)關(guān)單獨(dú)一個(gè)控件但用DAPM管理全局靜音一個(gè)控件。別把左聲道音量和右聲道音量合成一個(gè)控件除非芯片本身就是聯(lián)動(dòng)調(diào)節(jié)的。也別把播放音量和錄音音量合成一個(gè)它們物理上就是獨(dú)立的。6.2 默認(rèn)值的設(shè)計(jì)開(kāi)機(jī)就能出聲控件注冊(cè)后有個(gè)默認(rèn)值這個(gè)默認(rèn)值決定了開(kāi)機(jī)后聲卡能不能直接出聲。很多驅(qū)動(dòng)默認(rèn)值是0靜音導(dǎo)致用戶(hù)以為聲卡壞了。合理的默認(rèn)值應(yīng)該是通路開(kāi)關(guān)打開(kāi)、音量設(shè)到中間偏上、靜音關(guān)閉。但默認(rèn)值不能亂設(shè)要考慮硬件安全。比如耳機(jī)輸出增益默認(rèn)設(shè)太高可能損壞耳機(jī)或者聽(tīng)力。我的做法是參考芯片評(píng)估板的默認(rèn)配置再根據(jù)實(shí)際產(chǎn)品調(diào)整。默認(rèn)值在控件的info回調(diào)里通過(guò)uinfo-value.integer.min等字段體現(xiàn)或者在probe里主動(dòng)寫(xiě)一次寄存器。6.3 控件與電源管理的配合Codec通常有多個(gè)電源域控件操作可能觸發(fā)電源域切換。比如從待機(jī)喚醒時(shí)要先上電再寫(xiě)寄存器。ASoC的component框架有set_bias_level回調(diào)用來(lái)處理電源狀態(tài)切換?？丶卣{(diào)里不要直接操作電源寄存器交給set_bias_level統(tǒng)一管理否則容易出現(xiàn)電源狀態(tài)不一致。另外put回調(diào)里如果發(fā)現(xiàn)codec處于低功耗狀態(tài)應(yīng)該先喚醒再寫(xiě)。ASoC框架通常會(huì)自動(dòng)處理但如果你用了自定義的電源管理就要自己保證順序。6.4 多codec場(chǎng)景下的控件命名沖突一塊板子上有兩顆codec時(shí)控件名字可能沖突。比如兩顆都有Headphone Playback Volumeamixer里會(huì)顯示兩個(gè)同名控件用戶(hù)分不清。解決辦法是在控件名字里加上codec標(biāo)識(shí)比如CODEC1 Headphone Playback Volume。ASoC的component有name字段可以在注冊(cè)時(shí)用component-name做前綴。這個(gè)細(xì)節(jié)在單codec項(xiàng)目里不重要但多codec項(xiàng)目里不注意就會(huì)踩坑。我建議從一開(kāi)始就養(yǎng)成加前綴的習(xí)慣哪怕現(xiàn)在只有一顆codec將來(lái)擴(kuò)展也方便。6.5 內(nèi)核版本差異從snd_soc_codec到snd_soc_componentLinux 4.10左右ASoC進(jìn)行了一次大重構(gòu)snd_soc_codec被snd_soc_component取代。老驅(qū)動(dòng)里的snd_soc_codec、snd_soc_codec_driver、codec-control_data這些在新內(nèi)核里都變了。移植驅(qū)動(dòng)時(shí)要注意snd_soc_codec→snd_soc_componentsnd_soc_codec_driver→snd_soc_component_driversnd_soc_kcontrol_codec→snd_soc_kcontrol_componentcodec-control_data→component-regmap這個(gè)重構(gòu)影響面很大控件相關(guān)的API幾乎都改了。如果你在維護(hù)老驅(qū)動(dòng)要么整體移植到新框架要么鎖定內(nèi)核版本。別混用新舊API編譯能過(guò)但運(yùn)行時(shí)行為可能不對(duì)。7. 寫(xiě)在最后控件是驅(qū)動(dòng)和用戶(hù)的契約調(diào)了這么多codec驅(qū)動(dòng)我越來(lái)越覺(jué)得音頻控件不只是一堆寄存器封裝它是驅(qū)動(dòng)開(kāi)發(fā)者給用戶(hù)空間的一份契約。用戶(hù)通過(guò)控件名字和取值范圍來(lái)理解這顆codec能做什么通過(guò)amixer來(lái)調(diào)整它。控件設(shè)計(jì)得好用戶(hù)不用看手冊(cè)就能把聲音調(diào)對(duì)設(shè)計(jì)得差用戶(hù)對(duì)著幾十個(gè)控件一臉茫然。我自己的習(xí)慣是每寫(xiě)完一個(gè)codec驅(qū)動(dòng)先用amixer contents把控件列表打出來(lái)假裝自己是個(gè)第一次用這顆芯片的用戶(hù)看能不能憑名字和取值范圍猜出每個(gè)控件的作用。猜不出來(lái)的要么改名要么合并要么補(bǔ)文檔。這個(gè)自檢過(guò)程能發(fā)現(xiàn)大部分控件設(shè)計(jì)問(wèn)題。最后分享一個(gè)實(shí)用技巧調(diào)試階段可以在probe里把所有控件的當(dāng)前值打印一遍和芯片手冊(cè)的復(fù)位值對(duì)照。如果某個(gè)控件讀出來(lái)的值和手冊(cè)不符說(shuō)明get回調(diào)或者寄存器訪(fǎng)問(wèn)有問(wèn)題。這個(gè)檢查花不了幾分鐘但能提前發(fā)現(xiàn)很多隱蔽的bug。 ASoC編解碼器驅(qū)動(dòng)開(kāi)發(fā)：音頻控件類(lèi)型、注冊(cè)與DAPM調(diào)試實(shí)戰(zhàn)
1. 從一次耳機(jī)雜音排查說(shuō)起ASoC控件到底在管什么前陣子幫朋友調(diào)一塊基于i.MX6ULL的工控板音頻部分用的是WM8960編解碼器?，F(xiàn)象很怪系統(tǒng)能枚舉出聲卡aplay也能跑但插上耳機(jī)后左聲道一直有沙沙底噪右聲道正常。一開(kāi)始懷疑是硬件布線(xiàn)示波器量了半天沒(méi)發(fā)現(xiàn)問(wèn)題。后來(lái)用amixer把播放通路的幾個(gè)開(kāi)關(guān)逐個(gè)關(guān)掉發(fā)現(xiàn)只要關(guān)掉Left Output Mixer PCM這個(gè)控件底噪立刻消失。問(wèn)題根因是PCM數(shù)據(jù)在左聲道混音器里被重復(fù)疊加了一次而驅(qū)動(dòng)里這個(gè)控件的默認(rèn)值設(shè)錯(cuò)了。這件事讓我再次意識(shí)到ASoC編解碼器驅(qū)動(dòng)里音頻控件kcontrol才是真正決定聲音長(zhǎng)什么樣的那一層。寄存器配置、時(shí)鐘樹(shù)、DMA這些固然重要但用戶(hù)空間能感知到的音量、通路、靜音、增益全部通過(guò)控件暴露出來(lái)?？丶O(shè)計(jì)得對(duì)不對(duì)直接決定了這顆codec能不能被正常使用。這篇內(nèi)容面向的是已經(jīng)寫(xiě)過(guò)基礎(chǔ)字符設(shè)備驅(qū)動(dòng)、正在往ASoC方向深入的嵌入式Linux開(kāi)發(fā)者也適合那些能跑通聲卡但搞不清amixer里那一堆開(kāi)關(guān)到底對(duì)應(yīng)什么的工程師。我會(huì)圍繞編解碼器驅(qū)動(dòng)中音頻控件的開(kāi)發(fā)把控件類(lèi)型、注冊(cè)流程、與DAPM的關(guān)系、調(diào)試手段這些核心要點(diǎn)拆開(kāi)講盡量把我在實(shí)際項(xiàng)目里踩過(guò)的坑和總結(jié)的經(jīng)驗(yàn)都放進(jìn)來(lái)。需要先明確一個(gè)概念邊界ASoCALSA System on Chip把音頻系統(tǒng)拆成三塊——Machine驅(qū)動(dòng)負(fù)責(zé)把CPU DAI和Codec DAI綁在一起Platform驅(qū)動(dòng)管DMA和CPU側(cè)DAICodec驅(qū)動(dòng)管編解碼芯片本身。音頻控件主要誕生在Codec驅(qū)動(dòng)里少數(shù)在Machine驅(qū)動(dòng)里定義。所以下面討論的控件開(kāi)發(fā)默認(rèn)是在Codec驅(qū)動(dòng)的語(yǔ)境下。2. 音頻控件的四種基本類(lèi)型與選型邏輯2.1 從用戶(hù)能調(diào)什么反推控件類(lèi)型很多人寫(xiě)控件是照著芯片手冊(cè)的寄存器表一個(gè)個(gè)抄抄完發(fā)現(xiàn)amixer里冒出來(lái)幾十個(gè)控件用戶(hù)根本不知道該動(dòng)哪個(gè)。正確的思路應(yīng)該反過(guò)來(lái)先想清楚用戶(hù)空間需要調(diào)整哪些量再?zèng)Q定用哪種控件類(lèi)型去封裝。ALSA的snd_kcontrol_new結(jié)構(gòu)體里iface、name、info、get、put這幾個(gè)字段決定了控件的類(lèi)型和行為。按功能劃分編解碼器驅(qū)動(dòng)里最常用的是四類(lèi)控件類(lèi)型典型用途關(guān)鍵回調(diào)用戶(hù)空間表現(xiàn)音量/增益調(diào)節(jié)PCM、ADC、DAC增益snd_ctl_boolean_mono_info等帶數(shù)值范圍的滑動(dòng)條開(kāi)關(guān)靜音、通路使能snd_ctl_boolean_mono_infoon/off開(kāi)關(guān)枚舉輸入源選擇、濾波器模式snd_ctl_enum_info下拉列表路由混音器通路連接snd_soc_dapm_*由DAPM自動(dòng)管理選型的核心判斷標(biāo)準(zhǔn)是這個(gè)量是連續(xù)可調(diào)的、二值的、還是多選一的。連續(xù)可調(diào)就用SNDRV_CTL_ELEM_IFACE_MIXER配合info回調(diào)返回范圍二值用SNDRV_CTL_ELEM_IFACE_MIXER配合布爾info多選一用枚舉。路由類(lèi)控件比較特殊它不直接暴露給用戶(hù)而是交給DAPM去管理后面單獨(dú)講。2.2 音量控件的范圍計(jì)算別直接抄手冊(cè)音量控件最容易出錯(cuò)的地方是范圍計(jì)算。芯片手冊(cè)通常給的是寄存器值到dB的對(duì)應(yīng)關(guān)系比如WM8960的耳機(jī)輸出增益寄存器0x02的bit[6:0]對(duì)應(yīng)0到127每步0.5dB。但你不能直接把0到127丟給用戶(hù)空間因?yàn)橛脩?hù)看到的是0到127這種裸數(shù)值沒(méi)有物理意義不同通路的增益步進(jìn)不一樣混在一起很亂有些芯片的增益是反的寄存器值越大增益越小。我的做法是在info回調(diào)里把范圍映射成dB值或者至少映射成有意義的百分比。具體實(shí)現(xiàn)時(shí)snd_ctl_elem_info的value.integer.min和max填映射后的值get和put回調(diào)里做雙向轉(zhuǎn)換。舉個(gè)例子如果寄存器0到127對(duì)應(yīng)-17.25dB到30dB步進(jìn)0.375dB那可以這樣處理static int wm8960_hp_vol_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { uinfo-type SNDRV_CTL_ELEM_TYPE_INTEGER; uinfo-count 2; /* 左右聲道 */ uinfo-value.integer.min 0; uinfo-value.integer.max 127; uinfo-value.integer.step 1; return 0; }這里我保留了原始寄存器范圍但在控件名字里標(biāo)注了單位比如Headphone Playback Volume讓用戶(hù)知道這是寄存器級(jí)調(diào)節(jié)。如果要做dB映射就在get里把寄存器值轉(zhuǎn)成dB再返回。兩種做法各有取舍保留原始值實(shí)現(xiàn)簡(jiǎn)單、調(diào)試直觀映射成dB對(duì)用戶(hù)友好但代碼復(fù)雜。我個(gè)人的經(jīng)驗(yàn)是調(diào)試階段保留原始值產(chǎn)品化階段再考慮映射因?yàn)檎{(diào)試時(shí)你更關(guān)心寄存器現(xiàn)在是多少。2.3 枚舉控件的坑字符串?dāng)?shù)組的生命周期枚舉控件用來(lái)做多選一比如輸入源選擇Line In / Mic / PCM。它的info回調(diào)需要返回一個(gè)字符串?dāng)?shù)組這里有個(gè)非常隱蔽的坑字符串?dāng)?shù)組必須是靜態(tài)的或者生命周期覆蓋整個(gè)控件存在期。我見(jiàn)過(guò)有人在info回調(diào)里用局部數(shù)組結(jié)果amixer讀出來(lái)的選項(xiàng)是亂碼或者空。正確的寫(xiě)法是把字符串?dāng)?shù)組定義成static const char *放在文件作用域static const char *wm8960_input_texts[] { Line In, Mic, PCM }; static int wm8960_input_enum_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { return snd_ctl_enum_info(uinfo, 1, 3, wm8960_input_texts); }snd_ctl_enum_info的第二個(gè)參數(shù)是通道數(shù)第三個(gè)是選項(xiàng)個(gè)數(shù)。注意選項(xiàng)個(gè)數(shù)要和數(shù)組長(zhǎng)度嚴(yán)格一致多一個(gè)少一個(gè)都會(huì)導(dǎo)致越界讀。這個(gè)函數(shù)是ALSA提供的輔助函數(shù)比自己填uinfo-value.enumerated.item省事得多。2.4 開(kāi)關(guān)控件與靜音別把兩者混為一談開(kāi)關(guān)控件看起來(lái)最簡(jiǎn)單但靜音和通路開(kāi)關(guān)是兩個(gè)不同的東西。靜音Mute是在信號(hào)鏈末端把輸出拉低通路開(kāi)關(guān)Switch是控制某段電路是否導(dǎo)通。有些芯片兩者都有有些只有其一。寫(xiě)驅(qū)動(dòng)時(shí)要看清楚手冊(cè)別把靜音寄存器當(dāng)成通路開(kāi)關(guān)來(lái)用。另外開(kāi)關(guān)控件的get回調(diào)要返回當(dāng)前實(shí)際狀態(tài)而不是你上次put進(jìn)去的值。因?yàn)樾酒赡芤驗(yàn)槠渌虮热缟想姀?fù)位、DAPM自動(dòng)管理改變了寄存器狀態(tài)。每次get都去讀一次寄存器這是最穩(wěn)妥的做法雖然多一次I2C讀但避免了狀態(tài)不一致。3. 控件注冊(cè)的完整鏈路從snd_kcontrol_new到用戶(hù)空間3.1 注冊(cè)時(shí)機(jī)為什么不能在probe里一股腦全注冊(cè)Codec驅(qū)動(dòng)的probe函數(shù)里通常會(huì)調(diào)用snd_soc_add_component_controls或者把控件數(shù)組掛到snd_soc_component_driver的controls字段上。后者是推薦做法因?yàn)锳SoC框架會(huì)在合適的時(shí)機(jī)統(tǒng)一注冊(cè)。但這里有個(gè)時(shí)機(jī)問(wèn)題DAPM的widget和route必須在控件注冊(cè)之前或者同時(shí)建立好否則控件可能引用到不存在的通路。我一般把控件數(shù)組、DAPM widget數(shù)組、route數(shù)組都定義成靜態(tài)的然后在component_driver里一次性?huà)焐先プ尶蚣苋ヌ幚眄樞?。static const struct snd_soc_component_driver wm8960_component_driver { .controls wm8960_snd_controls, .num_controls ARRAY_SIZE(wm8960_snd_controls), .dapm_widgets wm8960_dapm_widgets, .num_dapm_widgets ARRAY_SIZE(wm8960_dapm_widgets), .dapm_routes wm8960_dapm_routes, .num_dapm_routes ARRAY_SIZE(wm8960_dapm_routes), };ARRAY_SIZE這個(gè)宏一定要用別手寫(xiě)數(shù)字。我見(jiàn)過(guò)有人改了控件數(shù)組但忘了改num_controls結(jié)果多出來(lái)的控件沒(méi)注冊(cè)或者注冊(cè)了越界的內(nèi)存現(xiàn)象是amixer里少幾個(gè)控件或者內(nèi)核直接oops。3.2 控件命名規(guī)范用戶(hù)空間靠名字找控件控件的name字段是用戶(hù)空間識(shí)別控件的唯一標(biāo)識(shí)。amixer、alsactl、各種音頻框架都靠名字來(lái)匹配。命名不規(guī)范會(huì)導(dǎo)致用戶(hù)空間找不到控件音量調(diào)不了同名控件沖突后注冊(cè)的覆蓋先注冊(cè)的自動(dòng)化測(cè)試腳本匹配失敗。ALSA有一套約定俗成的命名規(guī)范核心是**源 方向 功能**三段式比如Headphone Playback Volume—— 耳機(jī)播放音量Capture Volume—— 錄音音量Left Output Mixer PCM—— 左輸出混音器的PCM輸入開(kāi)關(guān)ADC PCM Capture Volume—— ADC到PCM的錄音音量方向詞用Playback和Capture功能詞用Volume、Switch、Route、Mux。別自創(chuàng)命名比如寫(xiě)成hp_vol雖然能注冊(cè)成功但用戶(hù)空間的通用工具可能識(shí)別不了而且可讀性差。3.3 私有數(shù)據(jù)的傳遞kcontrol到codec的橋梁控件的get和put回調(diào)里需要訪(fǎng)問(wèn)codec的寄存器。怎么從kcontrol拿到codec的指針標(biāo)準(zhǔn)做法是用snd_soc_component_get_drvdatastatic int wm8960_hp_vol_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct snd_soc_component *component snd_kcontrol_chip(kcontrol); struct wm8960_priv *wm8960 snd_soc_component_get_drvdata(component); /* 讀寄存器填ucontrol */ ... }snd_kcontrol_chip返回的是snd_soc_component指針在ASoC語(yǔ)境下再通過(guò)get_drvdata拿到驅(qū)動(dòng)私有數(shù)據(jù)。這個(gè)鏈路要記牢因?yàn)閹缀趺總€(gè)回調(diào)都要用。注意早期內(nèi)核版本用的是snd_soc_kcontrol_codec新版本改成了snd_soc_component。移植驅(qū)動(dòng)時(shí)要注意內(nèi)核版本差異別直接抄老代碼。3.4 寄存器訪(fǎng)問(wèn)的原子性put回調(diào)里的讀改寫(xiě)put回調(diào)里經(jīng)常要做讀-改-寫(xiě)讀出寄存器當(dāng)前值改掉某幾位再寫(xiě)回去。這個(gè)操作在并發(fā)場(chǎng)景下可能出問(wèn)題比如兩個(gè)進(jìn)程同時(shí)調(diào)amixer。ASoC框架對(duì)控件的put回調(diào)有加鎖保護(hù)但如果你在put里訪(fǎng)問(wèn)了多個(gè)寄存器或者訪(fǎng)問(wèn)了非控件管理的寄存器就要自己加鎖。我的習(xí)慣是在put里盡量只操作一個(gè)寄存器如果必須操作多個(gè)用snd_soc_component_read和snd_soc_component_write這對(duì)函數(shù)它們內(nèi)部有緩存和鎖機(jī)制。別直接用i2c_smbus_read_byte_data繞過(guò)ASoC的寄存器緩存否則DAPM的狀態(tài)會(huì)和實(shí)際寄存器不一致。4. DAPM與控件的關(guān)系為什么你的控件不生效4.1 DAPM自動(dòng)管理了大部分通路很多人寫(xiě)完控件后發(fā)現(xiàn)amixer里明明把某個(gè)開(kāi)關(guān)打開(kāi)了但聲音還是出不來(lái)。原因往往是DAPM在背后自動(dòng)管理了通路你手動(dòng)開(kāi)的開(kāi)關(guān)被DAPM關(guān)掉了。DAPMDynamic Audio Power Management是ASoC的核心機(jī)制它根據(jù)當(dāng)前的音頻流狀態(tài)自動(dòng)開(kāi)關(guān)音頻通路上各個(gè)widget的電源。一個(gè)widget只有在被需要的時(shí)候才會(huì)通電。比如播放時(shí)從PCM到DAC到輸出混音器到耳機(jī)這條路徑上的widget會(huì)被自動(dòng)上電不在這條路徑上的比如錄音通路會(huì)被斷電。所以如果你把某個(gè)通路開(kāi)關(guān)定義成了普通kcontrolDAPM不認(rèn)識(shí)它就不會(huì)在需要的時(shí)候打開(kāi)它。正確的做法是把通路開(kāi)關(guān)定義成DAPM widget讓DAPM去管理。4.2 什么時(shí)候該用DAPM widget什么時(shí)候用kcontrol判斷標(biāo)準(zhǔn)很簡(jiǎn)單這個(gè)開(kāi)關(guān)是否參與音頻通路的自動(dòng)電源管理。如果是某段電路是否導(dǎo)通、某個(gè)混音器輸入是否使能用DAPM widgetSND_SOC_DAPM_MIXER、SND_SOC_DAPM_SWITCH等如果是用戶(hù)手動(dòng)調(diào)節(jié)的音量、用戶(hù)手動(dòng)選擇的輸入源用kcontrol如果是靜音兩者都可以但用kcontrol更直觀因?yàn)橛脩?hù)需要看到靜音狀態(tài)。我見(jiàn)過(guò)一個(gè)典型錯(cuò)誤把Left Output Mixer PCM這個(gè)混音器輸入開(kāi)關(guān)定義成了普通kcontrol。結(jié)果播放時(shí)DAPM不知道要打開(kāi)它聲音出不來(lái)用戶(hù)手動(dòng)打開(kāi)后停止播放再播放DAPM又把它關(guān)了。改成SND_SOC_DAPM_MIXER的輸入后DAPM自動(dòng)管理問(wèn)題解決。4.3 widget與kcontrol的命名對(duì)應(yīng)關(guān)系DAPM widget和kcontrol在用戶(hù)空間的表現(xiàn)不同widget通常不直接暴露除非用dapm調(diào)試接口kcontrol會(huì)出現(xiàn)在amixer里。但它們的名字在驅(qū)動(dòng)內(nèi)部要能對(duì)應(yīng)上因?yàn)閞oute數(shù)組里用名字來(lái)連接widget。比如static const struct snd_soc_dapm_widget wm8960_dapm_widgets[] { SND_SOC_DAPM_MIXER(Left Output Mixer, WM8960_POWER1, 5, 0, wm8960_left_mixer_controls, ARRAY_SIZE(wm8960_left_mixer_controls)), ... }; static const struct snd_soc_dapm_route wm8960_dapm_routes[] { { Left Output Mixer, PCM Playback Switch, Left DAC }, ... };route里的第二個(gè)參數(shù)是widget的輸入名要和mixer controls里的名字對(duì)應(yīng)。這個(gè)對(duì)應(yīng)關(guān)系錯(cuò)了DAPM就建不起通路現(xiàn)象是聲音出不來(lái)或者通路不完整。4.4 用debugfs看DAPM狀態(tài)調(diào)試DAPM最有效的手段是debugfs。掛載debugfs后/sys/kernel/debug/asoc/card/dapm/下面有每個(gè)widget的狀態(tài)。播放時(shí)看哪些widget是On哪些是Off就能判斷通路是否正確建立。mount -t debugfs none /sys/kernel/debug cat /sys/kernel/debug/asoc/*/dapm/Left\ Output\ Mixer輸出里會(huì)顯示widget的電源狀態(tài)、輸入輸出連接、當(dāng)前是否在活動(dòng)路徑上。這個(gè)信息比猜寄存器值有用得多。我調(diào)音頻通路問(wèn)題時(shí)第一步就是看DAPM狀態(tài)基本能定位到是哪個(gè)widget沒(méi)連上。5. 調(diào)試與驗(yàn)證讓控件真正可控5.1 amixer的常用操作與輸出解讀amixer是驗(yàn)證控件最直接的工具。幾個(gè)常用命令amixer controls # 列出所有控件 amixer contents # 列出控件及當(dāng)前值 amixer sget Headphone Playback Volume # 讀某個(gè)控件 amixer sset Headphone Playback Volume 80% # 設(shè)某個(gè)控件 amixer sset Left Output Mixer PCM on # 開(kāi)某個(gè)開(kāi)關(guān)amixer contents的輸出里每個(gè)控件會(huì)顯示numid、iface、name、type、access、當(dāng)前值。重點(diǎn)看type和accesstype是INTEGER、BOOLEAN、ENUMERATED之一access里有rw表示可讀寫(xiě)。如果某個(gè)控件顯示type不對(duì)或者access是r只讀說(shuō)明info回調(diào)或者put回調(diào)有問(wèn)題。5.2 用alsactl保存和恢復(fù)控件狀態(tài)產(chǎn)品化時(shí)控件狀態(tài)需要在開(kāi)機(jī)時(shí)恢復(fù)。alsactl store把當(dāng)前所有控件狀態(tài)存到/var/lib/alsa/asound.statealsactl restore恢復(fù)。這個(gè)機(jī)制依賴(lài)控件的名字和numid穩(wěn)定。如果你改了控件名字或者增刪了控件舊的state文件會(huì)失效需要重新store。我遇到過(guò)一個(gè)問(wèn)題驅(qū)動(dòng)里控件注冊(cè)順序變了導(dǎo)致numid變化alsactl restore把值設(shè)到了錯(cuò)誤的控件上。解決辦法是保證控件注冊(cè)順序穩(wěn)定或者在state文件里用名字而不是numid來(lái)匹配alsactl默認(rèn)用名字但有些版本會(huì)混用。5.3 常見(jiàn)問(wèn)題排查表現(xiàn)象可能原因排查手段amixer里看不到控件控件數(shù)組沒(méi)掛到component_driver或num_controls不對(duì)檢查component_driver定義看dmesg有無(wú)注冊(cè)失敗日志控件能讀不能寫(xiě)put回調(diào)返回錯(cuò)誤或access沒(méi)設(shè)成rw看put回調(diào)返回值檢查info里access字段設(shè)了值但聲音不變控件沒(méi)連到實(shí)際寄存器或DAPM覆蓋了讀寄存器確認(rèn)值變了看DAPM狀態(tài)聲音有底噪混音器重復(fù)疊加或增益設(shè)置不當(dāng)逐個(gè)關(guān)控件定位看混音器route播放時(shí)控件自動(dòng)變DAPM自動(dòng)管理了該控件把控件改成DAPM widget5.4 一個(gè)真實(shí)的排查案例回到開(kāi)頭那個(gè)左聲道底噪問(wèn)題。排查過(guò)程是這樣的amixer contents看所有控件發(fā)現(xiàn)Left Output Mixer PCM和Right Output Mixer PCM都在值都是on關(guān)掉左聲道的PCM輸入底噪消失說(shuō)明問(wèn)題在左混音器看DAPM route發(fā)現(xiàn)左混音器有兩條輸入一條來(lái)自L(fǎng)eft DAC一條來(lái)自Right DAC用于單聲道轉(zhuǎn)立體聲檢查驅(qū)動(dòng)代碼發(fā)現(xiàn)route里錯(cuò)誤地把Right DAC也連到了Left Output Mixer導(dǎo)致右聲道信號(hào)混進(jìn)了左聲道刪掉那條錯(cuò)誤的route問(wèn)題解決。這個(gè)案例說(shuō)明控件本身沒(méi)問(wèn)題問(wèn)題在route定義。DAPM的route數(shù)組是音頻通路的接線(xiàn)圖接錯(cuò)一根線(xiàn)聲音就不對(duì)。調(diào)試時(shí)要把route和芯片手冊(cè)的通路圖對(duì)照著看。6. 從能用到好用控件設(shè)計(jì)的進(jìn)階經(jīng)驗(yàn)6.1 控件粒度別太細(xì)也別太粗控件粒度是個(gè)權(quán)衡。太細(xì)用戶(hù)空間冒出上百個(gè)控件用戶(hù)懵太粗用戶(hù)想調(diào)某個(gè)具體增益調(diào)不了。我的經(jīng)驗(yàn)是按用戶(hù)會(huì)獨(dú)立調(diào)節(jié)的量來(lái)劃分每個(gè)輸出通路的音量單獨(dú)一個(gè)控件每個(gè)輸入源的選擇單獨(dú)一個(gè)枚舉控件混音器的每個(gè)輸入開(kāi)關(guān)單獨(dú)一個(gè)控件但用DAPM管理全局靜音一個(gè)控件。別把左聲道音量和右聲道音量合成一個(gè)控件除非芯片本身就是聯(lián)動(dòng)調(diào)節(jié)的。也別把播放音量和錄音音量合成一個(gè)它們物理上就是獨(dú)立的。6.2 默認(rèn)值的設(shè)計(jì)開(kāi)機(jī)就能出聲控件注冊(cè)后有個(gè)默認(rèn)值這個(gè)默認(rèn)值決定了開(kāi)機(jī)后聲卡能不能直接出聲。很多驅(qū)動(dòng)默認(rèn)值是0靜音導(dǎo)致用戶(hù)以為聲卡壞了。合理的默認(rèn)值應(yīng)該是通路開(kāi)關(guān)打開(kāi)、音量設(shè)到中間偏上、靜音關(guān)閉。但默認(rèn)值不能亂設(shè)要考慮硬件安全。比如耳機(jī)輸出增益默認(rèn)設(shè)太高可能損壞耳機(jī)或者聽(tīng)力。我的做法是參考芯片評(píng)估板的默認(rèn)配置再根據(jù)實(shí)際產(chǎn)品調(diào)整。默認(rèn)值在控件的info回調(diào)里通過(guò)uinfo-value.integer.min等字段體現(xiàn)或者在probe里主動(dòng)寫(xiě)一次寄存器。6.3 控件與電源管理的配合Codec通常有多個(gè)電源域控件操作可能觸發(fā)電源域切換。比如從待機(jī)喚醒時(shí)要先上電再寫(xiě)寄存器。ASoC的component框架有set_bias_level回調(diào)用來(lái)處理電源狀態(tài)切換?？丶卣{(diào)里不要直接操作電源寄存器交給set_bias_level統(tǒng)一管理否則容易出現(xiàn)電源狀態(tài)不一致。另外put回調(diào)里如果發(fā)現(xiàn)codec處于低功耗狀態(tài)應(yīng)該先喚醒再寫(xiě)。ASoC框架通常會(huì)自動(dòng)處理但如果你用了自定義的電源管理就要自己保證順序。6.4 多codec場(chǎng)景下的控件命名沖突一塊板子上有兩顆codec時(shí)控件名字可能沖突。比如兩顆都有Headphone Playback Volumeamixer里會(huì)顯示兩個(gè)同名控件用戶(hù)分不清。解決辦法是在控件名字里加上codec標(biāo)識(shí)比如CODEC1 Headphone Playback Volume。ASoC的component有name字段可以在注冊(cè)時(shí)用component-name做前綴。這個(gè)細(xì)節(jié)在單codec項(xiàng)目里不重要但多codec項(xiàng)目里不注意就會(huì)踩坑。我建議從一開(kāi)始就養(yǎng)成加前綴的習(xí)慣哪怕現(xiàn)在只有一顆codec將來(lái)擴(kuò)展也方便。6.5 內(nèi)核版本差異從snd_soc_codec到snd_soc_componentLinux 4.10左右ASoC進(jìn)行了一次大重構(gòu)snd_soc_codec被snd_soc_component取代。老驅(qū)動(dòng)里的snd_soc_codec、snd_soc_codec_driver、codec-control_data這些在新內(nèi)核里都變了。移植驅(qū)動(dòng)時(shí)要注意snd_soc_codec→snd_soc_componentsnd_soc_codec_driver→snd_soc_component_driversnd_soc_kcontrol_codec→snd_soc_kcontrol_componentcodec-control_data→component-regmap這個(gè)重構(gòu)影響面很大控件相關(guān)的API幾乎都改了。如果你在維護(hù)老驅(qū)動(dòng)要么整體移植到新框架要么鎖定內(nèi)核版本。別混用新舊API編譯能過(guò)但運(yùn)行時(shí)行為可能不對(duì)。7. 寫(xiě)在最后控件是驅(qū)動(dòng)和用戶(hù)的契約調(diào)了這么多codec驅(qū)動(dòng)我越來(lái)越覺(jué)得音頻控件不只是一堆寄存器封裝它是驅(qū)動(dòng)開(kāi)發(fā)者給用戶(hù)空間的一份契約。用戶(hù)通過(guò)控件名字和取值范圍來(lái)理解這顆codec能做什么通過(guò)amixer來(lái)調(diào)整它。控件設(shè)計(jì)得好用戶(hù)不用看手冊(cè)就能把聲音調(diào)對(duì)設(shè)計(jì)得差用戶(hù)對(duì)著幾十個(gè)控件一臉茫然。我自己的習(xí)慣是每寫(xiě)完一個(gè)codec驅(qū)動(dòng)先用amixer contents把控件列表打出來(lái)假裝自己是個(gè)第一次用這顆芯片的用戶(hù)看能不能憑名字和取值范圍猜出每個(gè)控件的作用。猜不出來(lái)的要么改名要么合并要么補(bǔ)文檔。這個(gè)自檢過(guò)程能發(fā)現(xiàn)大部分控件設(shè)計(jì)問(wèn)題。最后分享一個(gè)實(shí)用技巧調(diào)試階段可以在probe里把所有控件的當(dāng)前值打印一遍和芯片手冊(cè)的復(fù)位值對(duì)照。如果某個(gè)控件讀出來(lái)的值和手冊(cè)不符說(shuō)明get回調(diào)或者寄存器訪(fǎng)問(wèn)有問(wèn)題。這個(gè)檢查花不了幾分鐘但能提前發(fā)現(xiàn)很多隱蔽的bug。