企业官网建设流程全解析

简介：这份高通平台 audio 入门资料面向刚接触高通音频子系统的驱动开发与系统集成工程师，也适合需要补充 bringup 经验的嵌入式开发者，重点解决从软硬件框架认知到实际点亮的入门门槛。内容分为 Audio 软硬件系统框架与 Audio bringup 两条主线：前者梳理 CODEC 功能、HW/SW 架构与代码位置；后者按 PIL 加载、SLIMbus 状态、声卡注册、codec 上电时序与复位、软硬件匹配、GPIO 配置、外部芯片集成、audio 通路配置逐项排查，并延伸到 kernel 层 device tree、系统层音频属性、HAL 层 device table 等分层配置。整包共 1 个 docx 文件，约 2.61MB，为图文手册形式，目录完整、章节编号清晰，便于按 bringup 阶段检索对照。已有 2974 人学习，适合作为调试前的流程清单和问题定位参考。

1. Audio 通路：一句「放个音」为什么要在五层软件栈之间来回确认

在高通平台第一次做音频的板子上，最常见的场景不是听到声音，而是敲完cat /proc/asound/cards之后，对着空输出发呆——声卡压根没注册，后面无论 tinymix 还是 tinyplay 全在空转。这个画面很能说明问题：音频从来不是「写个驱动让它响」，它是一条横跨应用处理器、低功耗总线、编解码器和音频 DSP 的长链，任何一段断了，用户侧看到的都是同一个结果：没声音。所以真正值钱的不是记住十几个调试命令，而是建立一条因果顺序——ADSP 起来了吗、总线枚举到了吗、声卡注册了吗、通路点着了吗。搞懂高通平台的 audio 全貌，本质上就是搞懂这条链上每一环的判据长什么样。

2. 硬件这一层：CODEC 与两类低功耗总线怎么把数据变成电压

2.1 CODEC 不是一块「声卡」，它是挂在总线上的一颗从设备

一颗典型的 WCD 系列编解码器内部有几块互相独立的电路：ADC/DAC 阵列负责模数互转，模拟混音器负责把多路输入按增益叠加，MIC BIAS 是给麦克风供电的偏置电源，MBHC 模块专门做耳机插拔和线控按键检测，末级还有 Class-AB 或 Class-D 功放推动喇叭。但从 AP 的视角看，它只是挂在 SLIMbus 上的一个从设备——有固定的逻辑地址（LA）、有一张寄存器表，AP 靠读写信道去「拧旋钮」。

这个视角很关键：你在 tinymix 里看到的每一个 ctl，最终都会落到某个寄存器的某几个 bit 上。改 XML → 改 mixer ctl → 写寄存器，三段中任何一段断了，现象都是无声。同理反过来排查时也成立：声音不对，先确认寄存器到底写没写进去，而不是先怀疑 XML 写得好不好。

2.2 SLIMbus 与 SoundWire：为什么不用 I2C 加 I2S 的老组合

手机板上空间紧张，音频链路最常见的做法是让控制和数据共用一对线。SLIMbus 就是干这个的：一条 clock 加一条 data，按时隙切分通道，控制消息和 PCM 采样可以同时跑在总线上，省掉一组引脚和一组时钟。代价是协议栈复杂——要枚举、要分配逻辑地址、要按时隙配置通道，这也是为什么 bringup 阶段总线状态是必须单独确认的一关。

SoundWire 是更新的一代低功耗总线，支持多 lane、带宽更大，主从模型也更明确。它在高通平台上的典型用法是把带处理能力的智能功放挂上去——这类器件内部有自己的 DSP，需要比 SLIMbus 更宽的寄存器访问和更高的数据吞吐。

一条实用的判据：总线驱动把自己的设备节点挂在 sysfs 下，枚举成功与否看目录就够了。

# SLIMbus：正常至少能看到 controller 和每个从设备一项 ls /sys/bus/slimbus/devices/ # 形如 slim-0-0217:0 的条目，后半段就是从设备的逻辑地址 # SoundWire：master 一定在，slave 要看功放有没有被枚举出来 ls /sys/bus/soundwire/devices/ # 形如 master-0 / slave-0-0217 的条目

/sys/bus/slimbus/devices/下的每一项都是内核已经完成枚举、并把逻辑地址分配下来的从设备。目录为空意味着总线控制器起来了但一个从设备都没应答，这时候查驱动通常是白费力气，应该回头查供电和复位；目录里有 controller 但缺 codec，说明 codec 那边没被唤醒。SoundWire 同理，master-0存在只证明控制器注册了，slave-*才是真正挂上来的器件。

2.3 差分输出与单端输入：这个电路选择决定了软件怎么配

喇叭通常走差分输出：两条线互为参考，外界干扰同时耦合到两条线上，接收端的电压差几乎不变，共模噪声被抵消掉，而且在同样电源下摆幅翻倍，功率更足。麦克风则大多是单端输入——因为耳机接口的物理结构只给了一根信号线和一根地，绕不开。单端以地为基准，地线上的任何波动都会直接叠进信号里，所以 MIC BIAS 供电要加 RC 滤波，走线要远离功放和电源。

这个硬件事实会一路传导到软件：DTS 里 MIC BIAS 电压配错，录出来的声音就是小且底噪大；mixer 里把输入通路选成差分模式而实际焊的是单端接法，录出来要么单声道反相，要么直接没声。我见过不止一次「mic 灵敏度不对」最后查出来是 DT 里micbias电压写成了另一档。

2.4 从原理图到设备树：硬件框架怎么落到具体节点

硬件文档里的「codec 挂在哪条总线、复位脚是哪个 GPIO、供电来自哪路 PMIC」这些信息，最终都要以设备树的形式交给内核。常见的写法长这样：

&slim_msm { status = "okay"; wcd_codec: wcd-codec@217 { compatible = "qcom,wcd9xxx-codec"; reg = <0x217 0>; /* SLIMbus 逻辑地址，来自硬件配置 */ qcom,cdc-rst-n-gpio = <&tlmm 64 0>; /* 复位脚，低有效，probe 时按时序拉放 */ qcom,cdc-micbias-1-mv = <1800>; /* MIC BIAS 电压，单位 mV */ cdc-vdd-buck-supply = <&pm_s4>; /* 主供电，由 PMIC 输出 */ }; }; &sound { compatible = "qcom,msm8xxx-audio-codec"; qcom,model = "msm8xxx-snd-card"; /* 声卡名，HAL 侧要靠它找配置 */ asoc-platform = <&pcm0 &pcm1 &pcm2 &pcm_lowlatency>; asoc-codec = <&stub_codec &wcd_codec>; qcom,audio-routing = "RX1 MIX1 INP1", "RX1", /* 左：DAPM 内部通路 */ "SPK OUT", "SPK PA OUT"; };

reg里的逻辑地址不是随便填的，它由 codec 的硬件 strapping 决定，写错就枚举不到；qcom,cdc-rst-n-gpio指向复位脚，驱动 probe 时会按 databook 要求的时序拉低再释放；qcom,model是声卡名字，用户空间的 HAL 靠这个名字匹配mixer_paths_*.xml，名字对不上，后面的通路配置全部白写。qcom,audio-routing描述的是 codec 内部的 DAPM 连线，它只决定「codec 里哪几级放大器可以串起来」，不等于实际播放时就会走这条路——真正点火是运行时由 mixer 触发的。

3. Bringup 的因果链：从 PIL 到声卡注册，六道关卡为什么必须按顺序过

3.1 第一关 PIL：ADSP 固件没搬上去，后面全是空转

音频 DSP 是一个独立的处理器核，跑自己的固件镜像。AP 启动时通过 PIL（Peripheral Image Loader，新内核里归到 remoteproc/subsys 那套框架）把镜像从文件系统搬进 DSP 的内存，然后唤醒它。这一步没成，AP 发给 DSP 的任何跨核消息都不会有人应答——codec 即使枚举成功、声卡即使注册成功，一打开 PCM 就会在启动会话时超时。

# 看 DSP 是否加载并进入运行态 dmesg | grep -iE "subsys|adsp|q6|apr" cat /sys/class/remoteproc/remoteproc*/state

dmesg里应该能看到子系统加载成功、远程处理器上线的记录；state是running才算真的起来了。如果一直停在offline，先确认镜像文件在分区里存在、签名校验通过，再怀疑硬件。这一步的失败和音频通路毫无关系，但因为现象同样是「没声音」，非常容易被误判成驱动问题。

3.2 第二关 SLIMbus：从设备不应答，probe 会一直卡在延迟重试

codec 是总线从设备，自己不能发起通信，全靠 AP 侧的控制器去枚举。枚举成功的标志就是上一章看过的/sys/bus/slimbus/devices/里出现对应条目。这里有个容易让人误判的细节：如果 codec 迟迟不应答，内核返回的是-EPROBE_DEFER，框架会把它挂起来稍后重试，日志里不会打一条醒目的错误，只是静静地反复 defer。很多人 greperror什么都搜不到，就以为没问题。

真正的判据是「目录里有没有」。没有，就别看驱动代码了，直接跳到 3.4 去查电和复位。

3.3 第三关 声卡注册：dai_link 是怎么把三段拼成一张卡的

machine driver 干的事情，用一句话说就是把 CPU 侧的 DAI、平台侧的平台对象、codec 侧的 DAI 用一张 dai_link 表绑在一起，然后调snd_soc_register_card。注册时框架会拿表里的名字去全局找同名对象，任何一个找不到，注册失败。

/* 简化后的 dai_link 结构，真实工程里是几十条的数组 */ static struct snd_soc_dai_link msm_dai_links[] = { { .name = "msm8xxx-slimbus-0-rx", .stream_name = "Slimbus0 Playback", .cpu_dai_name = "slimbus-0-rx", /* BE：物理链路 */ .platform_name = "msm-pcm-dsp.0", /* DSP 侧 PCM 平台 */ .codec_dai_name = "wcd9xxx_rx1_dai", /* 必须与 codec 驱动注册名一致 */ .codec_name = "wcd9xxx-codec", .dpcm_playback = 1, /* 动态 PCM，FE 可以随时改挂到它 */ }, };

cpu_dai_name对应的是后端物理链路（Backend），前缀通常是 slimbus 或 soundwire；真正被应用打开的是前端 PCM（Frontend），比如 MultiMedia1、Voice Call，前端后端之间由 DSP 内的动态路由来连。codec_dai_name必须和 codec 驱动里snd_soc_dai_driver注册的名字逐字符一致，这是最典型的「差一个下划线就失败」的地方。dpcm_playback打开后，前端和后端才允许在运行时任意组合，这是整套通路能被 XML 动态切换的前提。

失败返回值基本能把问题定性：-517（-EPROBE_DEFER）是依赖没就绪，等就行，一直等就是真没起来；-ENODEV是名字对不上，纯软件问题；成功了就在/proc/asound/cards里出现一行。把这几道关卡的判据整理成一张表，排查时按顺序过一遍，比凭直觉猜要快得多。

3.4 第四关 上电时序与复位：差几毫秒，故障就变成玄学

codec 的 databook 会明确写出上电顺序：主供电稳定 → 复位脚保持低电平若干毫秒 → 释放 → 等内部 LDO 和 PLL 锁定 → 才允许访问寄存器。设备树里通常只写「用哪个 GPIO」，具体延时在驱动里按型号给。

血泪经验是：如果复位释放早于电源完全稳定，codec 可能进入一个半死不活的状态——总线上能枚举到，寄存器读出来全是 0 或全是 FF。这种故障最像玄学，同一块板子冷启动能起来、热重启起不来，换一块板子又好了，本质是上电斜率不同导致复位采样点踩在悬崖边上。遇到「时好时坏」的枚举失败，先拿示波器看复位脚和主供电的相对时序，比改十遍驱动有效。

3.5 第五关 软硬件匹配与 GPIO：名字和电平差一点，链路就差一截

打样阶段同一块板子出两版 BOM 是常态，codec 换了型号但 DTS 还写着老 compatible，驱动照样能 probe（因为寄存器大部分兼容），但某些功能会莫名其妙不对，比如耳机检测识别不出来。GPIO 同理：复位脚、功放使能脚、耳机检测脚、MIC BIAS 使能脚，只要有一个方向配反或者默认电平配错，结果都是「差一点就好」。

确认方法很土但有效：把原理图上所有和音频相关的 GPIO 列出来，逐个在/sys/kernel/debug/gpio里对一遍方向和当前电平，再和 databook 要求的静态电平对照。

3.6 第六关 外部芯片与通路配置：出声前的最后一公里

外挂功放、音频切换开关这类器件通常走 I2C 挂在 AP 上，需要三处配合：内核里有驱动并 probe 成功、HAL 的设备表里新增对应条目、mixer path 里有使能它的 ctl。很多「喇叭有底噪但没声音」的案例，最后是功放的使能脚一直没拉起来——因为 XML 里压根没有那一条 ctl。通路配置是 bringup 的最后一公里，也是最容易被当成「反正能响就行」而草草了事的一环，但它恰恰是后面所有无声问题的最大来源。

4. 通路拼装：Device Tree、HAL 设备表和 mixer_paths.xml 是怎么对上号的

4.1 Device Tree 决定的不是通路，而是「哪些通路是可能的」

qcom,audio-routing里那一串字符串对，描述的是 codec 内部 DAPM 组件之间的连接关系，比如「RX1 混音器的输入 1 接到 RX1」，「喇叭输出接到功放输出」。它只声明可能性，不决定当前走哪条。真正决定运行时路径的是用户空间的 mixer 配置，这也是为什么改了 DTS 之后必须重新编译内核、而改 XML 只要 push 进去重启服务——设计上就是把「可能的拓扑」和「当前的选择」拆成了两层。

这个拆分是有代价的：DTS 里漏写一条路由，DAPM 在运行时就不会把对应的电源域打开，你在 XML 里怎么点都没用，而且不会有任何报错——它只是静静地不生效。所以排查无声问题时，如果确认 mixer ctl 都写进去了还是没声音，就要回头核对 DTS 的 audio-routing。

4.2 HAL 设备表：把「用户选了什么设备」翻译成「哪条后端链路加哪个校准 ID」

框架层传下来的是抽象设备，比如「扬声器」「有线耳机」「听筒」。HAL 需要把它翻译成具体的东西：走哪条后端 DAI、用哪份校准数据。

/* 简化后的设备映射表，实际工程里是几十项的数组 */ static struct hw_device_info { audio_devices_t type; /* 框架层传下来的抽象设备 */ char *backend; /* 对应的后端 DAI 名，要和内核 dai_link 对上 */ int acdb_id; /* 校准数据库里的设备编号 */ } device_table[] = { { AUDIO_DEVICE_OUT_SPEAKER, "SLIMBUS_0_RX", 15 }, { AUDIO_DEVICE_OUT_WIRED_HEADPHONE, "SLIMBUS_0_RX", 16 }, { AUDIO_DEVICE_IN_BUILTIN_MIC, "SLIMBUS_0_TX", 10 }, };

type来自框架层，几乎不会变；backend必须和内核 dai_link 里cpu_dai_name的前缀族对上，写错了 HAL 会去打开一条不存在的 PCM，返回的 errno 是-ENODEV；acdb_id是校准数据库的索引，同一颗 codec 驱动同一路喇叭，接在不同的外壳和腔体上校准参数完全不同，靠这个 ID 区分。新项目加一个设备，本质上就是在这张表里加一行，再去校准工具里给这个 ID 填数据。

4.3 mixer_paths.xml 的结构：一次 path 应用到底改了什么

XML 里每个<path>对应一个使用场景，name是场景名，内部是一串 ctl 名值对。HAL 启动时会用 XML 解析器把整个文件读进内存，建立「场景名 → ctl 列表」的映射；播放时按当前设备查出场景名，再把列表里每一条依次写到 mixer 上。

<path name="speaker"> <!-- 把 RX1 混音器的输入 1 接到 RX1，打开数字通路 --> <ctl name="RX1 MIX1 INP1" value="RX1" /> <!-- 数字音量，范围 0-124，84 大约是 -20dB 左右的位置 --> <ctl name="RX1 Digital Volume" value="84" /> <!-- 打开耳机/喇叭的模拟输出级，这一步决定功放有没有被使能 --> <ctl name="SPK PA OUT" value="1" /> <!-- 外部功放的使能脚，走的是 GPIO mixer 控件 --> <ctl name="Spk Amp Enable" value="1" /> </path>

这四条的顺序是有讲究的：先接通路、再设增益、最后开功放。反过来先开功放再接通路，会出现一个几十毫秒的爆音，因为功放在输入端还没稳定时就被使能了。value的取值范围由对应的 kcontrol 决定，数字音量通常是 0 到 124 的寄存器值，不是分贝，直接抄别人的配置很容易出现「声音特别小」——因为 84 和 100 差着十几 dB。

注意：XML 只管 codec 侧的模拟/数字通路和前端后端 PCM 的绑定，DSP 内部那层动态混音路由是另一套机制，由音频会话在打开时建立。这两层不同步，是「XML 全对但没声音」的经典成因。

4.4 用 tinymix 和 dumpstate 验证 route 真的生效了

最直接的验证方式是绕过 HAL，手动把 path 里的 ctl 逐条写一遍，看声音出不出来。出来了说明 XML 或 HAL 的匹配逻辑有问题，不出来说明问题在更下层。

# 列出当前所有 mixer 控件及其当前值 tinymix # 手动应用一条通路，语法就是 控件名 值 tinymix "RX1 MIX1 INP1" "RX1" tinymix "RX1 Digital Volume" 84 tinymix "SPK PA OUT" 1 # 播放一段 PCM，-D 是声卡号，-d 是设备号 tinyplay /data/test.wav -D 0 -d 0

tinymix不带参数时输出的是所有控件的快照，重点看三件事：控件的值是不是你写进去的那个（证明写入成功）、控件是否存在（证明 DTS 里那级通路确实注册了）、以及写入之后有没有被别的进程改回去。第三条最容易忽略——如果播放时后台有另一个音频流在跑，它关闭时会把自己那条 path 的 ctl 复原，你的手动配置就被覆盖了，现象是「刚设好有声音，几秒后又没了」。

再用框架层的 dump 确认流到底有没有走到 HAL：

dumpsys media.audio_flinger | grep -A5 "Output thread" logcat -s AudioFlinger AudioPolicyManager audio_hw_primary

前者能看到当前活跃的输出线程和它挂的设备，后者能看到 HAL 打开 PCM、应用 path 的完整过程。如果 logcat 里压根没有应用 path 的记录，问题在 HAL 的路由判断；如果有记录但 tinymix 里值没变，问题在 XML 的 ctl 名和内核 kcontrol 名不匹配。

5. 排查现场：声卡注册失败、无声、无输入的五个翻车记录

5.1 先建立可观测性：寄存器、dmesg、logcat 三处入口

动手改任何代码之前，先确认这三处能看到东西。寄存器层面，总线从设备的读写通常由控制器驱动在 debugfs 下暴露节点，直接 cat 和 echo 就能访问；内核层面看 dmesg 里的 ASoC、codec、总线驱动打点；用户空间看 logcat 里 HAL 的日志。

# 读一个 SLIMbus 从设备的一段寄存器（偏移 + 长度，具体接口随内核版本略有差异） cat /sys/kernel/debug/slimbus/slim-0-0217:0/registers # 写单个寄存器：偏移 值 echo "0x0100 0x1F" > /sys/kernel/debug/slimbus/slim-0-0217:0/registers # 只看音频相关的内核日志，过滤掉无关噪声 dmesg | grep -iE "asoc|slimbus|soundwire|wcd|codec" # 打开 HAL 的详细日志级别 setprop log.tag.audio_hw_primary VERBOSE

寄存器读出来全 0 或者全 FF，说明器件根本没进入可访问状态，此时所有上层排查都是徒劳；能读出合理值但不随写入变化，说明写通道有问题（比如总线时隙没配对）。dmesg 里 ASoC 打完 dai_link 的匹配过程之后如果没有任何后续，基本可以断定卡在某个延迟重试上。这三处入口配合使用，能在一小时内把问题范围从「整个音频系统」缩到「某一颗芯片的某一个引脚」。

5.2 供电磁珠导致声卡注册失败

现象：某入门平台，dmesg 里 codec 驱动反复 probe 失败，返回值是-EIO，总线枚举时有时无；换一块同型号板子就好了。第一反应当然是驱动 bug，改了三天复位延时，没用。

原因：codec 主供电路径上串了一颗磁珠，直流电阻偏大，加上板子上还有一路大电流负载在启动时抢电，codec 上电瞬间电压跌落到欠压阈值以下，内部复位电路反复触发。软件看到的「枚举失败」只是表象。

解决：换低 DCR 的磁珠，或者把 codec 的供电路径和功放分开走；同时在驱动里把复位释放前的延时不依赖固定值，改成轮询电压稳定的方式。这类问题的教训是：只要现象是「换板就好」，就先怀疑硬件离散性，别急着改软件。

5.3 智能功放 BusID 冲突导致只有一边有声

现象：立体声喇叭只有左边响，右边完全没声音；右声道对应的总线上看不到器件。

原因：两颗智能功放的从设备地址由硬件 strapping 引脚决定，产线把两颗料贴成了一样的配置，地址撞车，总线上后注册的那颗被内核直接拒绝。因为总线协议要求地址唯一，冲突时的报错往往很隐晦，只表现为「找不到设备」。

解决：核对两颗功放的 strapping 电阻，把地址区分开；同时在工厂测试流程里加一条总线枚举检查，避免批量出货之后才发现。

5.4 speaker 无输出：通路开了，但功放没使能

现象：声卡注册正常，tinymix 能看到所有控件，播放时 dmesg 显示 PCM 已经跑起来了，但喇叭一点声音都没有。

原因：外部功放的使能走的是一个 GPIO 类型的 mixer 控件，XML 里漏了这一条。因为 codec 内部的输出级是打开的，所以从寄存器看一切正常，只是最后一级放大没通电。

解决：在对应 path 里补上使能控件，并且注意顺序放在通路建立之后。这类问题的通用排查手法是：把 path 里所有 ctl 列出来，逐个问「这一条如果没写，现象会是什么」，答案里凡是「没声音」的，都值得在 bringup 阶段做一次单条删除验证。

5.5 mic 无输入：录到的是静音，不是没录到

现象：录音有文件、有时长，播放出来是静音；tinymix 里 TX 通路看起来都开了。

原因：MIC BIAS 电压配置与所用麦克风不匹配，驻极体需要约 2V 左右，MEMS 麦克风通常需要更低，配错之后麦克风要么不工作要么输出极小。另一种可能是输入通路的单端/差分选择与实际接法相反，信号被差分接收端当成了共模噪声抵消掉。

解决：按器件手册改 DT 里的 micbias 电压档位；用tinycap直接录一段原始 PCM 看波形幅度，确认是「极小」还是「完全没有」，这两个结果指向的原因完全不同。

5.6 改了 mixer_paths.xml 却没效果

现象：改完 XML push 到板子上，重启也不生效，声音还是老样子。

原因：三种典型情况——推到了错误的路径（系统里同时存在多份同名 XML，实际加载的是另一份）、HAL 进程没重启（配置在进程启动时一次性读入内存）、或者你改的那条 path 根本没被当前场景命中（设备类型判决走的是别的分支）。

解决：先用logcat确认 HAL 实际加载的是哪个文件的路径；改完必须重启对应的音频服务进程，不能只重启应用；最后在日志里确认命中的 path 名和你改的是同一个。改配置类问题最高效的排查方式永远是「先证明它被读到了」，再谈内容对不对。

6. 设计取舍：为什么通路放在 XML、校准数据放在 DSP 侧

6.1 三层配置各自的职责边界

把同一件事拆到 DTS、HAL 设备表、XML 三层，看起来繁琐，但每一层解决的是不同粒度的问题：DTS 描述的是硬件拓扑，换板子才改；设备表描述的是抽象设备到物理链路的映射，加外设才改；XML 描述的是具体场景下的通路组合，调音、改行为都在这一层。拆开之后，最常见的那类修改只需要重启一个用户态进程，不用重编内核，这在量产阶段调通路时非常关键。代价也很明显——三层之间靠字符串匹配，名字对不上不会有编译期检查，只能靠运行期日志，所以静默失败特别多。

6.2 校准数据为什么放在 DSP 侧而不是编进内核

不同外壳、不同腔体、不同批次的喇叭，频响曲线差异很大，校准数据必须能随硬件版本更新，而内核镜像的更新成本高得多。把校准数据做成独立文件、由 DSP 在会话建立时按设备 ID 去索引，好处是改一个参数只需要换一个文件，坏处是多了一层「ID 对不上就静默用默认值」的隐患——表现就是声音能出来但明显不对，音量偏小或者频响发闷。我的习惯是每次新增设备，先在 HAL 日志里确认实际请求的校准 ID，再去核对数据文件里有没有这个 ID，两步都过才算配完。

6.3 我自己的验证顺序

从那以后，我每次碰一个新的音频板子，都会强制走一遍固定顺序：先看 DSP 状态，再看总线枚举，再看声卡注册，然后用 tinymix 手动把一条最简单通路（通常是听筒）打通，最后才碰 HAL 和 XML。这个顺序的价值在于每一步都有一个二值判据，过不去就停在那一步，不会出现「同时怀疑三个地方」的局面。手动打通听筒这一步尤其不能省，它是把「硬件 + 内核」和「用户空间配置」彻底分开的分水岭，越早做越省时间。

希望帮到你。

本文还有配套的精品资源，点击获取