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