# 根因分析：重启后「无声」与本机状态对照

本文在已启用 **UCM HiFi** 的前提下，把「重启必现无声 / 手跑 `--fix` 又好」拆成**可验证**的两条链路，并给出比「整栈重启」更轻的验证手段。

---

## 1. 机制 A（本机已证实）：WirePlumber 持久化了**极低的路由音量**

WirePlumber 把每张声卡、每个**输出端口**的 `channelVolumes` 写在：

`~/.local/state/wireplumber/default-routes`

在本机（jack-Kaisa）与历史日志 `kaisa-audio-doctor_local-plan-jack_20260409_130048.log` 中，同一文件里出现：

- **HDMI1**（UCM 端口名在文件里常编码为 `\oOut\c\sHDMI1`）：`channelVolumes=0.062991671264172;0.062991671264172`（约 **6.3%** 线性增益，主观上接近无声）
- **Port1**：`channelVolumes=1.0;1.0`（正常）

冷启动后 WirePlumber **按该文件恢复**各端口的音量；若当前默认输出或某条路由落在 HDMI1 上，就会表现为 **「路由看起来对、就是没声」**。这与 [DEBUG_Reboot_No_Sound_and_Fix.md](DEBUG_Reboot_No_Sound_and_Fix.md) 中的**机制 A**一致，并把「极小音量」落实为**可 grep 的数字**。

**`--fix` 为何能立刻好**：`kaisa-audio-doctor.sh` 的 `apply_fix` 会对当前默认 sink 执行 `wpctl set-volume @DEFAULT_AUDIO_SINK@ 1.0`，相当于把**当前输出**从持久化的低音量里拉出来；若再配合切到 Jack=on 的 HDMI / 重启栈，就会把「错路由 + 低音量 + error 节点」一并收敛。

**更轻的验证（不必先重启栈）**：

```bash
grep -n channelVolumes ~/.local/state/wireplumber/default-routes
wpctl get-volume @DEFAULT_AUDIO_SINK@
```

若 `default-routes` 里某 HDMI 行 `< 0.2` 而你觉得应该能听见，可先：

```bash
wpctl set-volume @DEFAULT_AUDIO_SINK@ 1.0
# 或在声音设置里把对应输出滑条拉高，观察 default-routes 是否被写回合理值
```

**根因追问（仍开放）**：为何 HDMI1 会被写成 ~0.06？可能是 GNOME/滑条与 WirePlumber 路由音量的交互、某次误触、或显示刻度与存储线性值不一致。**产品侧**可在 deb 文档中建议用户检查该文件；**工程侧**可评估是否在登录后只做「路由音量下限裁剪」而非整栈重启（需单独实现与测试）。

---

## 2. 机制 B（日志已见）：某路 HDMI PCM `set_hw_params` 打开失败

`journalctl --user -u pipewire` 中出现：

- `spa.alsa: set_hw_params: 输入/输出错误`
- `alsa_output....HiFi__hw_sofrt5682_2__sink`（pcm=2 / HDMI1）`suspended -> error`

即 **驱动/时序层** 在打开 `hw:0,2` 时失败。脚本里已优先尝试 pcm=3/4 再 2（见 `detect_available_pcm` 注释）。这与 DEBUG 中的**机制 B**一致。

**根因追问**：需内核/SOF/HDMI 音频路径上进一步对照（单线插拔、EDID、HWE 小版本），超出用户态 deb 能「根治」的范围。

---

## 3. `default-nodes` 在说什么（辅助理解）

`~/.local/state/wireplumber/default-nodes` 里常见多行 `default.configured.audio.sink.N=...`，表示曾配置过的默认 sink 候选；**当前真正生效的默认 sink** 仍以 `pactl info` / `wpctl status` 为准。机制 A 的「假无声」可以发生在 **default-nodes 指向 Port1，但某应用或路由仍走 HDMI1 且音量为 0.06** 的组合下，因此排查时 **务必看 `default-routes` 里各端口的 channelVolumes**。

---

## 4. 与交付策略的关系

| 手段 | 针对 |
|------|------|
| 查 / 清 / 修正 `default-routes` 中的低 `channelVolumes` | **机制 A**（用户态、可文档化） |
| `--fix` / 登录 oneshot | **A + B** 一并收敛（重、但稳） |
| 内核/驱动跟进 | **机制 B** 的根本缩小 |

继续「找根本原因」时，建议优先在本机复现一次重启后、无声当下执行 **§1 的 grep**，确认是否仍为 HDMI 某行 `channelVolumes≈0.06`；若是，则**首要根因已落在 WirePlumber 持久化音量**，再决定是否做轻量修复脚本或上游 issue（WirePlumber/GNOME 音量模型）。