开发者用 Claude Code 逆向 RME Fireface UCX 驱动，Linux 下实现完整混音控制

上周，我终于让我的 RME Fireface UCX 在 Linux 上正常工作了。不只是把它当作一个基本的 USB 声卡来用（这一点本来就已经能做到），而是让整 个混音器和效果器部分都能通过一个我可以在听音时一直开着的小型终端混音器来掌控。RME 从未公开过协议，所以我让 Claude Code 和一个 AI 逆向工程工具包替我阅读 Windows 驱动，然后用剩下的一周时间把它的发现与真实硬件逐一核对。最终成果是一份有文档记录的协议，以及一整套你原本只能在 Windows 上获得的东西：一个内核驱动、一个混音器应用，以及围绕它们的工具。除此之外，延迟也很低：通过 PipeWire 在 48 kHz 下往返仅 3.5 ms，这对我的音乐制作环境带来了实实在在的改变。UCX 在 Class Compliant 模式下开箱即用，18 个通道进出全都有。你得不到的是它内部的 DSP。混音器、EQ、动态处理和混响会停留在 RME 的 TotalMix FX 应用最后一次留下的状态，所以如果你想改变路由，就得启动到 Windows。RME 还表示，它自家的驱动模式在延迟上优于 Class Compliant 模式，所以在 Linux 上我在这方面也有所缺失。这在 Linux 音频圈是个熟悉的故事。有很多出色的硬件，其最佳功能都藏在一个永远不会被移植的厂商应用里。驱动本来总是可以有人去写的，但很少有人愿意为一款十年前的接口的某一个型号，在反汇编器里耗上几周。我把 Claude Code 和 REA 搭配使用，后者是一个 MCP server，能让 agent 使用 Ghidra 的反编译器和 rizin 这类正经的逆向工程工具。实际操作中，我可以就驱动提问，Claude 会反编译相关函数、跟踪调用，然后回来告诉我它找到的东西叫什么。从 USB 层往上推进，它找到了驱动发送的请求、音频流是如何建立的，以及 TotalMix 如何编码一次推子移动。在此过程中，它还注意到混音器命令使用的格式与 RME 的 FireWire 接口相同，而 Linux FireWire 音频社区多年前就已经把这些记录下来了。仅这一点就节省了大量时间。Claude 完成了所有在反编译代码中缓慢挖掘的工作，而且它做得非常好。它无法告诉我的是，硬件对这些东西究竟会作何反应，因为二进制文件只显示了 Windows 发送了什么。这个项目涵盖了 RME 为 Windows 提供的许多功能，并为 Linux 重新构建：每一项设置同时也是一个普通的 ALSA control，所以 alsamixer 和脚本也能访问它。而且由于一切都在内核和标准 ALSA 中，PipeWire、JACK 以及所有音频应用都只把它看作一张普通的声卡。我没有自己写任何代码。Claude 写了全部代码，但我作为程序员的经验仍然影响了它是如何被构建的。我推动了声明式设计，即用一个配置文件描述整个设备，配置工具和终端混音器都基于这个描述工作。我还推动了 fuzz testing、clang-tidy 和其他静态分析，以及开启 sanitizer 的构建，以加固代码。所以这一周大部分时间都花在桌前，摆弄不同的音频线缆。我很快就让一些东西跑起来了，但要更进一步，需要大量针对设备的动手工作：转动旋钮、移动线缆、重启设备、在播放音频时让电脑进入睡眠。一个典型的轮次是：用一根线缆把一个输出环回接到一个输入，播放一个轻微 的测试音，改动一项设置，然后让 Claude 观察设备自身的电平表。一次只改一项设置，整个设备就是这样被摸清的。之所以一周就够了，关键在于工作是如何分工的。Claude 做了那些缓慢的阅读工作，而我做了那些需要有人在现场的事情：决定下一步测试什么、移动线缆、聆听。市面上有很多好设备，配着一个封闭的控制应用，而 Linux 用户会很乐意把它的功能全部用上。如果你就是这样的用户，现在是个值得一试的好时机。如果你有一台第一代 Fireface UCX，驱动、ucxtui 混音器以及面向 NixOS 和其他发行版的安装说明都在 github.com/realbogart/fireface-ucx-linux。它是 MIT 许可的，而且到目前为止只在一台设备上测试过，所以我很想听听它在你的设备上表现如何。协议已在仓库中有文档记录。感谢 RME 造出了一款这么多年后依然如此出色、值得付出这一切努力的接口。感谢 snd-firewire-ctl-services 和 oscmix 的作者，我依赖了他们对 RME 命令格式的记录；也感谢 REA，让这类工作变得更易上手。