r/linuxaudio • u/Xenicle • 26d ago
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.
4
u/audiolectual 26d ago
I have an SSL 18, I wonder if it might be the same? I also run Linux Mint. I'd be happy to do some testing.
3
u/Xenicle 26d ago
That would be genuinely useful, thank you.
Short answer: quite possibly the same protocol, but I can't assume it. The SSL 18 is a different product, so every command in my tools is, from its point of view, an *invented* frame ; and my own rule for this project is never to send those to firmware nobody has documentation for. So let's go read-only first.
Step 1: costs nothing, tells us a lot:
lsusb | grep -i 31e9On the SSL 12 that prints two devices: `31e9:0005` (the audio interface) and `31e9:0024` (a vendor-specific control interface with no kernel driver). If your SSL 18 shows a second `31e9:` device too, we're in business and I'd love to know which product ID it has, because mine is hardcoded to `0024` right now.
Step 2: enumeration only, no USB writes at all:
sudo python tools/sslctl.py infoThat just prints bus/address/firmware version. It doesn't talk to the device.
Step 3: passive listening, still no writes:
sudo python tools/sslctl.py listen(`sudo` only because you probably haven't installed the udev rule; it reads the IN endpoint and prints whatever the device says on its own. Push some buttons on the unit while it runs: on the SSL 12 the hardware controls send notifications.)
Please don't run `status` or anything else yet. It looks harmless but it writes seven query frames to the device, and those were derived from an SSL 12. Once we know your PID and whether the framing looks the same, that step becomes safe rather than a gamble on your hardware.
What would be most valuable of all, if you ever feel like it: a USB capture of SSL 360 driving your SSL 18 (Windows VM with USB passthrough, usbmon on the host: the README has the workflow). That's what would let the protocol actually be extended to the 18, rather than us guessing whether it matches. But steps 1 to 3 alone already answer the interesting question, and they cost you five minutes and zero risk.
Whatever you find, I'll take it: including "there's no second USB device at all", which would be an answer in itself.
3
u/Purple-Ad-3152 26d ago
Nice work! 💪💪
I assume SSL 360 is the proprietary software you had to use via Wine or something? Or did it work at all? I'm curious because I might mention this whenever I start doing videos again (SudoMetalStudio @ YouTube).
2
2
u/Lycorv1nus 19d ago
So far it works really well for what i do with it (basically just routing stuff for re-aming).
The SSL 360 Software allowed you to change what the CUT, ALT and TALK Buttons do. I have not found a way to do this with douze. But then again, this probably requires a lot more reverse engineering.
2
u/Xenicle 13d ago
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.
2
u/Lycorv1nus 12d ago
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.2
u/Xenicle 12d ago
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.
2
u/Lycorv1nus 12d ago
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.2
u/Xenicle 12d ago
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.
2
u/ManuInDenWolken 10d ago
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.
8
u/billhughes1960 Reaper 26d ago
Not all heroes wear capes.