jack
60b7cd389f
Add a more detailed --verify flow to capture Jack/ELD/subdevices, route per sink, and collect kernel error windows. Improve --fix with readiness gating, retries, and connected-only selection; document single-monitor pcm mapping behavior and ignore local logs/artifacts. Made-with: Cursor
4.0 KiB
根因分析：重启后「无声」与本机状态对照
本文在已启用 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 中的机制 A一致，并把「极小音量」落实为可 grep 的数字。
--fix 为何能立刻好：kaisa-audio-doctor.sh 的 apply_fix 会对当前默认 sink 执行 wpctl set-volume @DEFAULT_AUDIO_SINK@ 1.0，相当于把当前输出从持久化的低音量里拉出来；若再配合切到 Jack=on 的 HDMI / 重启栈，就会把「错路由 + 低音量 + error 节点」一并收敛。
更轻的验证（不必先重启栈）：
grep -n channelVolumes ~/.local/state/wireplumber/default-routes
wpctl get-volume @DEFAULT_AUDIO_SINK@
若 default-routes 里某 HDMI 行 < 0.2 而你觉得应该能听见，可先：
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 音量模型）。