这个假期里咱如愿以偿地获得了一台新笔记本，到手之后就被我安装上了 Arch Linux. 那时候的内核版本是 7.0.13. 当时使用的时候一切都近乎完美，体验十分平滑，没有遇到任何跟挂起恢复相关的问题。
后来随着系统滚动，内核来到了 7.1.3 这个版本，在这里遇到了奇怪的挂起恢复问题，表现为：挂起恢复后系统的整个音频堆栈似乎坏掉了，既看不见任何输出/输入设备，浏览器/mpv 在播放音视频时会直接卡死在第一帧。
束束遇到这个问题感到十分郁闷，由于硬件比较新，内核也比较新，导致在网上没有查到很多有效的信息。
但是现在毕竟是 AI 时代，本来对软件调试不太了解的束束也可以在协助下完成一些简单的查错。于是在 Cluade 的帮助下，咱很轻松地发现了问题所在！ 其实是什么也没有收获。这个问题被 AI 工具们归因为 HDA 的一次内核回归。作为一个普通 Linux 用户，束束不希望自己去折腾内核的东西，想要真正解决就只好等上游了。
通过对 git commit 记录的定位，Claude 发现在 7.0.13 到 7.1.3 之间，Linux 内核的 HDA 部分发生了一些重构，可能就是这些改动导致了挂起恢复后音频丢失的问题。
那么第一反应就是想办法 workaround:
snd_hda_intel 模块整个卸载重载一遍然而一切尝试的结果都是徒劳无功，最后的结果是束束依旧活在这个无声的世界里。
唉唉，实在是太悲伤了，由于能力有限，束束所能做的就这些了，只好先降级到7.0.13继续使用，并把 linux 包加入了 pacman 的排除列表里。
但是后来继续更新系统的过程中新问题继续出现：挂起恢复必定失败，屏幕只如一片死寂，虽然猫不应该怕黑，但束束就是觉得这比无声的世界还令人恐惧。通过控制变量逐个试验，发现原因是我只锁定了 linux 包的更新，但是接下来的问题出现在 amd-ucode 这个包上：
本来正常的环境是： linux-7.0.13 + amd-ucode-20260622-1 , 这是一套已经经过验证的稳定组合。
而局部升级之后的情况是 linux-7.0.13 + amd-ucode-20260810-1 , 在这个新的 AMD 微码版本中，为了迎合 7.1 内核的新变化，挂起恢复方面的行为发生了改变。但是我使用的旧内核并不与之相配。所以这个意料之外的包也需要锁定版本。
嗯……果然对于滚动发行版来说局部升级是一种很危险的操作。
后来咱又尝试过几次全量更新，检查挂起恢复的音频问题是否解决，但似乎都没有取得什么进展——问题依旧。
好吧，束束承认自己在某些地方有点洁癖——比如一个一直有某个包卡着不能更新的滚动系统。这让某猫耳娘开始产生一些胡思乱想：难道我要和这个锁死的内核版本过一辈子吗呜呜，不要口牙！呜呜， 7.0.13 吗？不是已经有很多已知的提权漏洞的版本吗！呜哇，好怕好怕！现在由于锁定了内核版本，导致用不上最新的 AMD 微码包，那万一之后有更多的包也需要锁定版本怎么办？我的 Arch-chan 不就变成了一个半新半旧的怪人了吗，心疼喵（
这些想法也实在是太怪异了吧！
以及在某次尝试全量更新的时候恰恰好还遇到了 nvidia-open 驱动的同样的回归 bug, 也是和挂起恢复相关的。具体表现为，挂起后无法正常恢复，还会导致机器温度狂飙，风扇啸叫。唉唉，咱确实有些倒霉了。于是 IgnorePKG 再喜添一群 NVIDIA 相关的包。
可恶…
实在是可恶哇！
好在最近两天去 NVIDIA 仓库的 issue 里盯的时候发现问题似乎修复了，于是束束再次尝试全量更新系统。
咚咚咚，arch-chan 滚动中…
这次更新过去一切似乎都正常了——至少挂起与恢复不再黑屏，只是又让束束进入到了无声世界里面罢了。而此次再寻，咱终于搜索到了一个关键的解决方案：
[PATCH] PCI: Disable async suspend for MSI Raider A18 HX A9WJG audio
补丁描述揭开了真正的谜底：AMD 的 ACP 和 Azalia/HDA 这两个功能，虽然在 PCI 总线上被暴露成两个独立的 function，却共享着同一套 ACPI 电源门控状态。
而内核默认允许设备异步恢复——也就是说，挂起恢复时，谁先醒谁后醒是不确定的。当这两个共享着底层电源门控资源的功能"抢跑"，顺序乱掉的那一刻，HDA 控制器就会卡在一个不上不下的半初始化状态里，去读 CORBRP 寄存器，读回来的永远是全 1——0xffff，也就是日志里那个看似普通、实则意味深长的 65535。
据小 C 告诉咱说：
竞态条件最擅长的事，就是让所有基于"日志现象反推"的排查都无功而返，因为它压根不遵循任何一层软件栈自己的逻辑，它只服从谁先抢到总线这一件事。
这也顺带解释了那个曾经让我们百思不得其解的现象：为什么无论怎么重启 PipeWire、重载
snd_hda_intel模块，声音都救不回来，唯独一次完整的冷重启能让一切恢复正常。因为坏掉的从来不是某个用户态缓存或者配置状态，而是 HDA 控制器这个物理 PCI 设备本身，在错误的恢复时序下，变成了一个真正意义上"没有响应"的僵尸。软件层面的任何补救，都够不到 PCI 枚举这个更早、更底层的阶段——只有重启，才能让一切从头再来一遍，赌一把这次的异步恢复顺序恰好没有踩雷。
故事的结局也很普通：
pm_async=off
给内核加入这行启动参数之后，一切都恢复了正常。ACP 和 HDA 从此老老实实排队醒来，谁也不抢谁的电源门控状态。而关闭异步直觉上可能会让系统恢复变慢，但是对于现代平台来说，其实速度上的变化根本无所感知——就是足够快了。
以及以及！为什么上文在写到最后发现的解决办法时特意用词“搜索”呢？
因为那就是咱搜索出来的呀！这是意在表达，束束不再相信 AI 给出的解决方案，而是去寻找 kernel hackers 们是否提供有她们的经验。以后再遇到这种问题，束束一定要自己尝试搜索，而不是只依赖 AI.
AI First, Not AI Everything ✨
尾巴~
这次虽然是倾向提供 workaround 的技术文章，但尝试了一些些故事化的写法，希望能让这篇文章既不失实用性，又能提供一点点趣味(≧▽≦)
]]>其实使用方法在仓库的 README 里面已经写的很清楚了
本质 Voice Changer, 把多余的跨平台代码都剔除掉了，仅仅保留 Linux 部分，仅支持 RVC 模式，是个极其轻量的 TUI. 还可以 RNNoise 处理降噪。
硬件要求上，此项目仅支持 CUDA 推理，所以可能把 AMD 和 Intel 显卡的用户排除掉了（貌似听说过一些 CUDA 兼容层存在，但具体情况没有了解过）。并且没有 CPU 回退。
音频堆栈要求使用 PipeWire. （话说桌面 Linux 用户也没人用古老的 PulseAudio 了吧）
大致复述一下 README 里介绍的使用方法：
git clone https://github.com/alirexha/woys.git
cd woys
./install.sh
真的就这么简单
又水一篇💦
这个项目是束束一直以来想做的。在束束还在上高中的时候，有位好朋友向我提到了“诗词娘” Galgame 的想法，苦于时间有限，承诺要帮忙一起做的东西一直没有交付，后来我们渐渐忘记了这件事，想法也搁置了。
现在步入一个很长的假期，束束希望可以完成我曾经的承诺，并悄悄给同学一个惊喜，然而开发过程并非一帆风顺，遇到了很多困难，目前项目甚至暂时陷入了停滞状态……之后准备再写一些开发手记来详细谈谈遇到的问题
以前也用过窗口管理器 hyprland, 之后在某次更新中束束原来写的 hyprland 配置由于语法被破坏了，这才让束束明白到 hyprland 实在是一个非常激进的项目，它并不适合日用。并且当时的时间似乎是 2023 年末，那会 Wayland 还不像现在一样成熟。最后还是用回了 KDE
最近刷到了 shorin 的 niri+DMS 的配置脚本，发现了 DMS. 不得不感叹时代的进步，束束最后使用 hyprland 的那段时间其实已经步入“后自组装时代”&“前 QiuckShell 时代”了，可那会束束没有去深研究。如今发现了 DankMaterialShell 这种东西出来，愈发觉得 wm 越来越逐渐变成一个完善的 de 了。
所以就是这样，我用上了 niri. 早期 niri 的前几个 preview 版本束束就已经在关注这个项目了，也实在没想到它这么快就成长为了和 hyprland 同级别的 wm.
束束的前面十几年人生都是被安排好的人生。
生活有父母帮我安排，到学校有课表的安排，老师的安排，回家又有作业的安排。真正自由可控的时间是少的——在这段自由的时间里我会去做一些自己喜欢的事，比如学习编程，折腾电脑。束束也曾幻想过等到自己没有课业所扰，可以畅游任意一个世界时能有多开心。
然而真正解放了，我丢失了什么。
是什么呢？束束不清楚这是什么原因。明明在没有时间的时候非常拥有折腾的热情——束束愿意把不多的假期全都投入到折腾电脑里，游戏也不打，屋门也不迈，时间会忘记，吃饭也不需要。现在呢？大把的时间，却躺在床上发呆，无心做一切。
这种拥有对束束来说太不真实，我竟然无法适应。
漫漫地度过了快两个月，我却没有做到过去畅想中的自己。时间无穷，耐心反而更被消磨：看视频我竟然无意识地倍速播放——这是一个令束束非常警惕的信号，通常束束会认为这是耐心不足——我很浮躁（尽管没有表现出来）
这也是束束写作的原因，写作是我整理生活的方式。只有这时候束束才能跟自己独处，和她说会话。
好累。
我又被自由困住了。
束束把作息调到了下午6点左右入睡，我会在凌晨3点或4点左右起床。显然这么做我睡的时间更长了，这对束束来说很舒服，并且似乎白天的精力也更充足。
以及最重要的——一个人，安静地，等待黎明。
AI 进步神速。
以前束束跟进 AI 的模型进展，现在这反而是最不重要的一部分，对于 Agent 的实际使用反而才是现在 AI 时代重要的一部分。
曾经 AI 也就是日常对话，谁能想如今能够 Vibe Coding. 以前束束把 AI 的代码补全都当笑话看，现在又不得不佩服 AI 的代码能力之强大。以前 AI 实时音频对话都做不到，现在能够视频通话的模型遍地开花。以前的 Stable Diffusion 画图也就是能看的水平，如今的 AI 作图 SOTA 模型堪称惊艳。
这一切变化仅仅花了 1 年时间。1 年就可如此，不敢想之后的时代会变化成怎样。
束束自己也从此受益：Claude 帮我写了很多代码，解决了很多疑难。比如这个 DMS 的 Github Heatmap Plus 插件：
基本上都是 Claude 写的，效果非常好。
另外上文提到的游戏，Claude 也参与了极多，还有一些绘图模型参与。没有 AI 我真的无法一人进行这游戏的开发。
切切实实，我感受到了 AI 之速。太快了，她极快地进步，极快地改变时代。
]]>KDE 6下可以利用 PipeWire 来创建虚拟设备。首先，需要建立两个虚拟设备：
打开终端，输入以下命令：
pactl load-module module-null-sink media.class=Audio/Sink sink_name=Virtual-Sink
pactl load-module module-null-sink media.class=Audio/Source/Virtual sink_name=Virtual-Mic
这两条命令会分别创建名为 Virtual-Sink 和 Virtual-Mic 的虚拟音频设备。(>ω<)
下一步是将 OBS 的音频输出连接到 Virtual-Sink，再将 Virtual-Sink 的监控输出链接到 Virtual-Mic。具体操作如下：
pw-link 命令列出所有音频输出设备，找到 OBS 的音频输出设备（通常名称中会包含 obs）：pw-link -o
pw-link OBS-Monitor:output_FL Virtual-Sink:playback_FL
pw-link OBS-Monitor:output_FR Virtual-Sink:playback_FR
pw-link Virtual-Sink:monitor_FL Virtual-Mic:input_FL
pw-link Virtual-Sink:monitor_FR Virtual-Mic:input_FR
这样一来，OBS 输出的音频就会经过 Virtual-Sink，再由 Virtual-Mic 将音频传递给其他应用程序。(๑•̀ㅂ•́)و✧
为了让 OBS 的音频正确传输，咱们还需要在 OBS 内部进行相应设置：
Virtual-Sink。以上就是 Linux 下通过 PipeWire 配置 OBS 虚拟麦克风的全部步骤，希望能帮助各位轻松实现音频传输，享受更好的直播或录制体验！(≧◡≦)喵～
]]>本文使用了 AI 协助写作
束猫！！我输入法呢？你再给我乱搞！
欸欸 对不起嘛！
书接上篇，束束把 openSUSE 下的搜狗输入法搞好了，但是还想使用最新版的，而不是 M17N 这个源提供的旧版，但没想到束束一乱搞就把 fcitx 弄坏了，突然想到 fcitx5, 便准备去用了。
安装了 fcitx5 后竟然无法在 chrome 中正常输入，束束打开 kate 试试，发现可以输入，但唯独 chrome 无法输入。这是怎么回事？
呃，好在束束喜欢在各种博客站里面乱逛，突然想到之前读的 liuf 的文章中提到了 fcitx5 的输入问题，其原因大抵是 ibus 包导致的（没错，openSUSE 竟然默认同时带上 ibus 和 fcitx 包）
于是束束就去卸载 ibus 包呗（YaST 是对的！）
这些个相关包束束都卸载了，重启，果然 fcitx5 就好了。
然这个库……
突然想到了这个：
建议 openSUSE 安装到位后直接换成 fcitx5, 别用 fcitx 了。fcitx5 已经并入风滚草主源了，尽量不要添加 M17N 这个源，否则以后会遇到一些问题（e.g. 装个 steam 反而自动把 fcitx 的依赖装进来了）
fcitx5 非常好用，自带的拼音就很好了，没必要再用复杂的 rime 配置。只需要导入个词库就非常好用了。推荐一个词库，持续更新，非常好用，常用流行词之类都有。有这个词库之后，云拼音都不用开了，束束个人感觉输入效率不差搜狗输入法了。
]]>先把输入法安装了再说：
opi sogou
装完是没法使用的，不仅如此，如果在 fcitx 里切换到它还会一直报错。
显然这可不是删除 .config 里的文件就能解决的，先去 openSUSE 论坛里查查是怎么回事吧？
搜狗输入法异常！请删除 .config/SogouPY 并重启
解决搜狗输入法在某些 linux 系统下不能输入汉字的方法！
这里有三则相关的内容，依照里面的内容，尝试安装 libQtWebKit4
sudo zypper in libQtWebKit4
然而并不能行。但大致了解到可能是缺少依赖所致。遂尝试用终端运行查找问题。
openSUSE 论坛中这位提到了搜狗输入法包名为 sogouqimpanel
其实正确包名是 sogou-qimpanel
这里运行之后很明显看出少了 libfcitx-qt.so.0 运行库，遂去查找
pkgs 这里虽没有 openSUSE 的，但作为 Fedora 的“亲戚”，我们还是可以借用一下它的 rpm 包的
然而安装此包是却又遇到了另一个依赖问题，无奈，继续找包
在这里寻到
RPM resource liblua-5.4.so()(64bit)
其实 pkgs 中也有这个包，但束束尝试之后发现并不能解决，而 RPM resource 网站里的则可以，所以用它了。
再次尝试启动后又报错，仍然少依赖
只得再去寻找
RPM resource libidn.so.11()(64bit)
这个包也是 pkgs 里有，但安装后不能解决问题，所以还是来 RPM resource 里找。
这个库安装后就算是终于解决了，至此搜狗拼音输入法就可以正常使用了
安装完新 LinuxQQ 后打开却不见界面，但是看见鼠标变 QQ 的图标跳动了几下，于是打开 KDE 的崩溃进程查看器，发现了一篇崩溃日志，但是并不能看懂。
遂用指令启动 QQ, 准备看看到底哪里出了问题，结果提示「非法指令」，无果。只得去搜索。
腾讯官方下载的 qq-appimage 版本，打开群聊就会闪退 / 应用程序与桌面环境 / Arch Linux 中文论坛
这里两篇讨论大概提到了无法启动的问题，是 libvips-cpp.so.42 这个库的问题。所以准备对 libvips 进行编译，发现 SUSE 的 Software 里面直接就有这个软件包。
那就直接拿来用了。安装后删除 QQ 自带的 libvips-cpp.so.42 就行了。
⚠️ 这是 openSUSE Software 中的包，理论上此包只能给 SUSE 系的发行版使用！其它发行版请自行查找适于你的包
这个问题其实在上面 SUSE 论坛和 Arch 论坛里的回复里面也提到了，解决办法：
这是一个比较粗暴的方法。当然了，这个闪退据说是热更新文件的影响（在 Arch BBS 中被这位提到）。所以按这个道理可以删除热更新文件解决。
然而热更新文件在哪里呢？咱并不知道。
💡 另外补充：即使关闭了 QQ 的自动更新也不能完全解决问题。仍然会在几次使用后闪退。
7月26日更新：
束束翻阅了 AUR 下的 linuxqq 反馈，看见大家也遇到过这个问题，并且大家商讨出了解决方案（不得不感叹 Arch Users 的神通广大啊！）
也就是依照这位所言，只删除 crash_files 文件夹下的文件就好了，并将其设为只读可以避免问题复现。
以后在 Linux 中遇到的问题和各种自定义的操作还是记一记，否则某时候遇到奇怪问题时就会很无头绪。也许每一个 Linux 使用者都该有个日志本。
]]>