I reverse-engineered the SSL 12's control protocol: mixer, monitoring and routing now work on Linux without SSL 360
SSL ships no Linux software for the SSL 12. Audio works out of the box (UAC2), but everything SSL 360 controls — internal mixer, monitoring, phantom power, loopback, routing — is unreachable. The card ends up a fixed-function box.
So I captured the USB traffic between SSL 360 and the card, mapped the control protocol, and wrote the tools:
https://github.com/xenicle/douze
- sslctl — CLI for the gain matrix, monitoring, preamps (48V/HPF/inst/polarity), loopback, headphone buses
- Douze — local web GUI (127.0.0.1) with the matrix, live meters, profiles - Douze FX — VST3 host that drops plugin chains into the PipeWire graph, one process per strip; a strip can publish its own virtual mic or sink, so any app picks it up as a normal device
The control interface is a separate vendor-specific USB device behind an internal hub, with no kernel driver — plain bulk endpoints, so everything is user-space (pyusb). No decompilation, no vendor code.
-> The protocol docs and all 25 captures are CC0 / public domain. A documented protocol is a fact about hardware, not a literary work — I'd rather it ended up in a kernel driver than stayed in my repo, so there's no attribution requirement at all. The code is AGPLv3 (JUCE).
-> Caveat worth stating up front: this is verified on exactly one card, mine, firmware bcdDevice 1.44. I use it daily and the protocol is mapped end to end, but I don't know if another unit behaves identically. If you own an SSL 12 I'd love to hear whether `sslctl status` returns something sane — that's the one thing I genuinely can't test alone.
Not affiliated with SSL; trademarks are theirs.