Kontrol S4 MK I
Opened this issue · 12 comments
Hi, i have access to both devices, if you instruct me what to do i can help you make it work.
Hi @IF-Adin - thanks for your post, and volunteering to help. Do you have any C coding experience, or knowledge of USB protocols? Unfortunatly, the work to "add support" for new devices to the Ctlra library is probably the most complex work regarding the Ctlra library in general - it requires access to the hardware and also a techincal knowledge of USB and details of the device.
These "Mark 1" devices talk in NHL (native hardware language), according to info posted here https://bugs.launchpad.net/mixxx/+bug/1432442. Apparently some of the devices are supported by the linux-kernel module, however that won't make them work with Ctlra ( Eg: see the S4 code here: https://github.com/torvalds/linux/blob/master/sound/usb/caiaq/input.c#L526 ). Looking around the code there, it does not look like the S2 Mk1 has support there.
Regards, -Harry
@harryhaaren Sorry i have no real experience with either, but i can follow your instructions, i know my way around the terminal well enough. Alternatively, maybe SSH access could be given.
The current state is that i can use the soundcard of my S4 fully and it works really well via the current kernel. The S2 is owned by a friend of mine who is ok with helping, too. He knows more about linux then i do.
I'd lend you my S4 but i am kind of using it ...
Update; I've gotten access to an S4 Mk1, which has allowed me to prototype some of the USB connectivity and figure out a few issues. Current status is that we can read bytes from the device, and they seems pretty "reasonable" to decode and identify each slider.
The "NHL" although not a standard protocol like USB HID is, is not insane either - just just a different method of encoding bits/bytes using USB Bulk transfers. Having worked with the Mk3 and Mk2 devices, the Mk1 protocol isn't quite as optimized for real-time and live usage - but its by no means an "amateur" job either. If anything, hat tip to NI for moving to USB HID, and for continually improving and innovating on the HW/SW combos they provide - nice work.
Regarding Ctlra support for these devices, it will take a bit of time to finish the input side of the S4, and I haven't started the output LED driving part yet. I guess it'll be similar to the other Mk2 devices (except possibly for the encoding part..) so there's some learning to do there. That's all for now.
@harryhaaren Awesome! Let me know if i can help with any testing.
If there's anything you need me to provide for the S2 Mk1 ahead of time (like HW ID's or anything I can do my end) Let me know!
@IF-Adin; yes I'll push some patches to a branch on here later today probably, I've been decoding buttons all evening so far - about 50% of the way through!
@ronlaws86: they thanks for the offer - So far the S4 is keeping me occupied - but the fact that we have data being read from the device is a good sign - and I expect the S2 Mk1 will have a very similar protocol / encoding to the S4. If you'd like to post some info about the S2 device, a copy/paste of the "usbview" utility output would be useful? Sample output of the S4 Mk1 below
$ sudo usbview # Then select the "S4 Mk1" device on the left pane, shows this on right pane
Traktor Kontrol S4
Manufacturer: Native Instruments
Serial Number: SN-3hpb66rf
Speed: 480Mb/s (high)
Bus: 1
Address: 4
USB Version: 2.00
Device Class: ff(vend.)
Device Subclass: ff
Device Protocol: ff
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 17cc
Product Id: baff
Revision Number: 0.0f
Config Number: 1
Number of Interfaces: 1
Attributes: 80
MaxPower Needed: 500mA
Interface Number: 0
Name: usbfs
Alternate Number: 0
Class: ff(vend.)
Sub Class: ff
Protocol: 00
Number of Endpoints: 2
Endpoint Address: 01
Direction: out
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
Endpoint Address: 81
Direction: in
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
Interface Number: 0
Name: usbfs
Alternate Number: 1
Class: ff(vend.)
Sub Class: ff
Protocol: 00
Number of Endpoints: 6
Endpoint Address: 01
Direction: out
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
Endpoint Address: 81
Direction: in
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
Endpoint Address: 82
Direction: in
Attribute: 1
Type: Isoc
Max Packet Size: 512
Interval: 125us
Endpoint Address: 84
Direction: in
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 0ms
Endpoint Address: 06
Direction: out
Attribute: 1
Type: Isoc
Max Packet Size: 512
Interval: 125us
Endpoint Address: 08
Direction: out
Attribute: 2
Type: Bulk
Max Packet Size: 512
Interval: 125us
Traktor Kontrol S2
Manufacturer: Native Instruments
Serial Number: 235F0D7B
Speed: 480Mb/s (high)
Bus: 2
Address: 4
USB Version: 2.00
Device Class: ef(misc )
Device Subclass: 02
Device Protocol: 01
Maximum Default Endpoint Size: 64
Number of Configurations: 1
Vendor Id: 17cc
Product Id: 1101
Revision Number: 0.1b
Config Number: 1
Number of Interfaces: 4
Attributes: 80
MaxPower Needed: 480mA
Interface Number: 0
Name: snd-usb-audio
Alternate Number: 0
Class: 01(audio)
Sub Class: 01
Protocol: 20
Number of Endpoints: 0
Interface Number: 1
Name: snd-usb-audio
Alternate Number: 0
Class: 01(audio)
Sub Class: 02
Protocol: 20
Number of Endpoints: 0
Interface Number: 1
Name: snd-usb-audio
Alternate Number: 1
Class: 01(audio)
Sub Class: 02
Protocol: 20
Number of Endpoints: 2
Endpoint Address: 01
Direction: out
Attribute: 5
Type: Isoc
Max Packet Size: 240
Interval: 125us
Endpoint Address: 81
Direction: in
Attribute: 17
Type: Isoc
Max Packet Size: 4
Interval: 1ms
Interface Number: 2
Name: (none)
Alternate Number: 0
Class: fe(app. )
Sub Class: 01
Protocol: 01
Number of Endpoints: 0
Interface Number: 3
Name: usbhid
Alternate Number: 0
Class: 03(HID )
Sub Class: 00
Protocol: 00
Number of Endpoints: 2
Endpoint Address: 82
Direction: in
Attribute: 3
Type: Int.
Max Packet Size: 64
Interval: 125us
Endpoint Address: 02
Direction: out
Attribute: 3
Type: Int.
Max Packet Size: 64
Interval: 125us
Thanks @ronlaws86, thats curious. That S2 Mk1 output looks a lot more like the S2 Mk2 than it does the Mk1 output as I posted above! The difference is in the USB Endpoints, you'll see that the "snd-usb-audio" module owns the first parts of the S2 Mk1, while on the S4 it was owned by "ff (Vendor Specific)".
That means a few things - A) its going to be easier to decode, as they're USB HID events, unlike the S4 Mk1 which uses USB Bulk events. B) The design is more like the Mk2 series, so I guess the S4 was developed first, and then the S2 Mk1 was kind-of between the Mk1 and Mk2 in terms of technology used. I find these things curious :)
Thanks for that!
Hey Folks, updated code pushed to this branch; long story short - success and rework required.
https://github.com/openAVproductions/openAV-Ctlra/commits/s4mk1
Details:
- ✔️ Successfully retrieved data from the S4 device, (requires using an "alt setting" USB mode to get the data to be reported)
- ✔️ Decoded data into the buttons/sliders events
- ❗ Audio card access is removed when we read the USB HID endpoint directly, as the kernel cannot access the device at the same time as Ctlra (when they both use the same USB interface).
Next steps
- 〰️ Check if using linux input events is feasible, to leave the device under kernel control, and to provide Ctlra applications with a consistent event model by translating them. This requires some more work as currently Ctlra doesn't read linux-input-events, but this could be added.
- 〰️ Its not sure how many other USB controllers have this exact problem, based on the input from @ronlaws86 above, the S2 Mk1 has already fixed this by splitting the interfaces for the USB audio and the USB HID button/slider/led messages.
There is an open issue for the S2 Mk1 on the github already; #29
I suggest we put all S2 Mk1 information/debug into that thread from now on, and make this thread exclusively for the S4 Mk1, given they're actually quite different devices. I'll rename this ticket now.
It's bizarre how different they are, considering the s2 is just the small brother of the s4. On paper they don't look that different. Makes me wish that NI would have had some sort of standard for their devices on the software side.
Although I can understand your point of view on standardization on the software side... I think it more important to applaud NI for continuing to innovate and improve on the controller hardware->software interaction protocol.
The Mk1 wasn't too nice (USB Bulk transfers, only one interface for Audio + HID). The Mk2 devices (and S2 Mk1..) have USB HID for sliders/buttons etc (via interrupt endpoint - much better), and class compliant usb audio. Then the Mk3 continue with USB HID + Interrupt endpoint but improve the method of reporting pressure-sensitivity (pads like the Maschine has) and the sliders of the Mk3 are "oversampled" providing the SW with more than one value per USB message - this allows for "smoothing" the values over time in software, leading to less "stair-stepped" audio, and a better feel to the device.
And that's only the USB protocol - the hardware itself feels a lot nicer too :)