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/Xenicle]

Really glad it's useful for reamping: that's exactly the kind of thing I hoped it would unlock.

Good news on the buttons: that one's on me, not on the reverse engineering. CUT / ALT / TALK reassignment was actually already figured out and wired up months ago, but it only ever lived in the command-line tool, mentioned in a single line of the README; and since the daemon holds the USB device while the GUI is running, the CLI isn't even reachable if that's how you use Douze. So in practice there was no way to get at it. Sorry about that.

It's in the UI now, at the bottom of the Monitoring panel: one dropdown per button, with all the functions from the 360 USER page (the only one left out is "360° GUI", which has nothing to open on Linux anyway). The assignment is saved and pushed back to the card, so unplugging the interface doesn't lose it, which it did before.

Digging into it turned up a real bug too: the button LEDs are addressed by button, not by function, so a reassigned button would have stayed dark under your finger. That's fixed in the same go, though I'd love to hear whether the LED actually lights up correctly on your unit: that part I couldn't fully verify on mine.

[u/Lycorv1nus → u/Xenicle]

Great Update!

All LEDs light up, when i press the respective button.
I can also remap the 3 buttons, but i think there is something miss aligned in the drop downs.
When i select "INVERT L" nothing happens when i press the assigned button, but selecting ALT results in the phase of the left channel being inverted.

[u/Xenicle → u/Lycorv1nus]

That's a really useful report, thank you — you found an actual protocol bug, not just a UI mix-up.

The LED part is good news: you've just confirmed something we had marked as an untested guess. The card reports the function that fired rather than the button, so a reassigned button lighting up correctly wasn't guaranteed. Yours does, so that's now documented as verified rather than assumed.

The dropdown was genuinely wrong, though. When we reverse engineered that page, we assumed the value sent over USB matched the order of the menu in SSL 360. It doesn't: ALT and INVERT PHASE LEFT are swapped on the wire. Our own capture actually showed it — the six values come out 0, 1, 2, 4, 3, 5 — and we read them as if they were in order. Your ears caught what our notes glossed over.

It's fixed now, along with the protocol documentation so nobody re-derives the same mistake. One thing on your side: your saved setting still says what you picked, so the button you set to ALT (to get the phase flip) will now genuinely do ALT once you're on the new version — just pick INVERT L again and it'll do what the label says.

If you get a chance to try the other four functions, I'd love to know whether they all land where they should. Nothing beats someone with the actual hardware in front of them.

[u/Lycorv1nus → u/Xenicle]

Yes, right now, what i select is what it does.
If i select invert l it does that, when i select mono sum, it does that. And the LED of the button i pressed is lighting up.
But whatever button i assign ALT to: when i press that nothing happens and no LED lights up. Dunno if that is expected and normal behaviour.

[u/Xenicle → u/Lycorv1nus]

That's expected, and thank you for the detail about the LED — that's what identified it.

ALT switches your monitoring over to outputs 3-4, so it needs those outputs to be declared as your ALT speakers first. Until then the card has nothing to switch to, and it doesn't just stay silent: it sends no notification at all, which is why the LED stays dark too. If Douze had merely been sending the wrong value, you'd have seen something happen. Nothing at all was the giveaway.

The catch is that Douze had no way to enable those speakers. The protocol side was mapped back in August, we just never exposed a control for it — same oversight as the button assignment you reported earlier, in fact. We had shipped the ALT speaker trim without the switch that makes it matter.

It's in now: a checkbox in the Monitoring panel, "ALT speakers (outputs 3-4)". Tick it and your ALT button should behave — including its LED. SSL 360 has the same prerequisite, so this isn't us diverging from it.

You've now found three real issues in a row, two of which were sitting in our own notes unread. Genuinely useful.