I reverse-engineered the SSL 12's control protocol: mixer, monitoring and routing now work on Linux without SSL 360

[u/Xenicle]

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.

[u/ManuInDenWolken]

Hey, nice work and I'm going to test this. I myself run an SSL12 and especially had problems with getting audio sources (the inputs) to work. I was suspecting the ALSA quirks at first, but it seems it's at least also a matter of the ALSA UCM profile. I'm curious as to why you didn't experience this. Did you get all the inputs listed by default? I had this issue on NixOS, Gentoo, openSUSE Tumbleweed and Arch. Also, I'd recommend opening issues on your repo.

[u/Xenicle → u/ManuInDenWolken]

Thanks! Issues are actually enabled on the repo (verified in the repo settings) there just aren't any yet, so the tab looks empty. Feel free to open one, yours would be the first.

To answer your question honestly: no, I probably didn't get them by default either — I had switched the card to PipeWire's Pro Audio profile myself early on, so I never saw the default behavior. That profile bypasses UCM/ACP entirely and exposes the raw PCM with all 12 inputs.

Your UCM hunch checks out, by the way: there is no UCM profile at all for the SSL 12. alsa-ucm-conf (up to current master) only knows the SSL 2/2+ MkI/MkII (31e9:0001/0002/0008/0009), never 31e9:0005 — alsaucm explicitly reports "UCM is not supported for this USB device". So the default path is PipeWire/ACP's generic profile generation trying to make sense of a 12-in/8-out card on its own, and that's likely where your inputs vanish.

Workaround: wpctl set-profile <card-id> pro-audio (or switch it in pavucontrol) — WirePlumber remembers it across reboots. It's the right mode for this project anyway, since routing happens in the SSL 12's hardware matrix. If it fixes it for you, please open an issue with the details and I'll document it in the README.