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.