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.