Add support for Digitakt II

[dagargo]

It's still unknown if the protocol is the same.

USB product definitions for all the possible Digitakt II USB configurations should be added to udev/20-usb-elektron.hwdb.

[nchouba]

is there a chance that this will support Digitak2 ?

[dagargo]

We don't know this yet but i think it could work.

Fortunately, if the Digitakt II uses the same USB packets, it is not difficult to try and see.

Only two things need to be done.

1. Add the USB definitions for Linux and the USB infrastructure to properly detect the device and give permissions to it.
2. Add the definition of the device in a JSON file for Overwitch.

The first part deals with the USB devices just above the kernel level. This information is in the udev directory where a new entry must be added for the Digitakt II.

udev$ head -n 5 20-usb-elektron.hwdb
usb:v1935*
 ID_VENDOR_FROM_DATABASE=Elektron Music Machines

usb:v1935p000A*
 ID_MODEL_FROM_DATABASE=Analog Heat Overbridge

First entry is the vendor (Elektron) and next entries are the devices. Copy a device at the end, give it a name and use the vendor ID and product ID from lsusb.

Don't forget to put your Digitakt II into Overbridge mode before running this command as there are different IDs for the different USB modes.

udev$ lsusb | grep Heat
Bus 001 Device 002: ID 1935:000A Analog Heat

First 4 hexadecimal digits 1935 is the vendor ID; the next 4 000A is the product ID. You need to use these 8 digits to conform the line usb:v1935p000A* that you added in the previous step.

You'll need to install the new rules by running sudo make install from that directory every time you make changes to this file.

The second part deals with the Overbridge definition of the device. This definition includes the ID, the name and the input and output tracks. Follow the explanation here.

Basically, copy the file res/devices.json into the user configuration directory, add a new definition for the Digitakt II and fill the JSON object. The amount of tracks must match the amount that the Digitakt sends and receives. The names are up to you.

Notice the ID is in decimal, so in the example above, the ID for the Analog Heat is 10.

Don't hesitate to ask in case of doubt.

[dagargo]

I'm not sure if the same code is gonna work anymore.

I've just updated my Digitak (not Digitakt II) and it has changed quite a lot in Overbridge mode regarding the USB descriptors.

I'm still investigating this.

On the positive side of things, MIDI seems to be class compliant even in Overbridge mode.

[nchouba]

@dagargo thank you. I followed your instructions, and I run into the below error. As you mentioned, I think it's related to the USB descriptors but might be something else not properly setup in my side.

ERROR:engine.c:727:ow_engine_init: Error while initializing device: LIBUSB_ERROR_BUSY ERROR:jclient.c:703:jclient_init: Overwitch error: can't set usb config

[dagargo]

Fortunately, only 2 lines need to be added to make it work with my Digitakt I at least.

diff --git a/src/engine.c b/src/engine.c
index 0374132..9ca9a50 100644
--- a/src/engine.c
+++ b/src/engine.c
@@ -643,6 +643,9 @@ ow_engine_init (struct ow_engine *engine, unsigned int blocks_per_transfer,
   engine->usb.xfr_timeout = xfr_timeout;
   debug_print (1, "USB transfer timeout: %u", engine->usb.xfr_timeout);

+  libusb_detach_kernel_driver (engine->usb.device_handle, 4);
+  libusb_detach_kernel_driver (engine->usb.device_handle, 5);
+
   err = libusb_set_configuration (engine->usb.device_handle, 1);
   if (LIBUSB_SUCCESS != err)
     {

With this you could test the device definition in the JSON file and see if the JACK client appears, has the right ports and works.

However, if the USB MIDI is confirmed to be class compliant in Overbridge mode, all the MIDI related code in Overwitch will not be needed anymore and could be wiped out, letting the MIDI kernel modules do their job.

I'm still thinking on the proper approach to this situation but I would probably be like this.

1. Close version 1.2 as it currently is. Everything is working but the code will no longer be compatible with newer OSes.
2. Plan a 2.0 release with all the new devices with MIDI support outside Overwitch.

I won't support devices with older OSes but version 1.2 will be there in case anybody needs it.

[nchouba]

Amazing thank you, really impressive work.

I have added the kernel detach driver and the error above got fixed. I'm having another error now: overwitch-record -n 0

ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW

when looking at dmesg output I see: usbfs: process 131666 (overwitch-recor) did not claim interface 5 before use

In the engine code I see you claim 3 interfaces but when listing DGII USB interfaces I see 5 of them, 2 of which are class audio. interface_number: 0 class: 255 protocol: 0 interface_number: 1 class: 255 protocol: 0 interface_number: 2 class: 255 protocol: 0 interface_number: 3 class: 255 protocol: 0 interface_number: 4 class: 1 protocol: 0 interface_number: 5 class: 1 protocol: 0

would that be reason? or may be I misconfigured the device audio output?

[dagargo]

I just know the very basics of USB but LIBUSB_TRANSFER_OVERFLOW makes me think the definition of the device in the devices.json file is not right. Too much data is coming in overflowing the buffer.

How many tracks have you defined? Could you post the device here?

Regarding the interfaces, this is what's in use.

• Interface 1, alternate setting 3 is for audio input.
• Interface 2, alternate setting 3 is for audio output.
• Interface 3, alternate setting 0 is for MIDI input and output.

As you noticed, interfaces 4 and 5 are for the class compliant MIDI. libusb requires libusb_detach_kernel_driver to be called before claiming other interfaces. This call will disable the MIDI driver in the kernel.

The interesting thing is that I have a working draft that removes all the MIDI code in Overwitch, does not claim the interface 3 and restores the MIDI driver in the kernel with calls to libusb_attach_kernel_driver.

But let's focus on solving the LIBUSB_TRANSFER_OVERFLOW first.

[nchouba]

here is the device definition, I have experimented with more output tracks, but no luck. { "pid": 2859, "name": "Digitakt2", "input_track_names": [ "Main L Input", "Main R Input" ], "output_track_names": [ "Track 1", "Track 2", "Track 3", "Track 4", "Track 5", "Track 6", "Track 7", "Track 8", "Track 9", "Track 10", "Track 11", "Track 12", "Track 13", "Track 14", "Track 15", "Track 16" ] }

and some logs from verbose run DEBUG:overwitch.c:392:ow_get_device_desc_from_vid_pid: Device with PID 2859 found DEBUG:overwitch.c:254:ow_get_usb_device_list: Found Digitakt2 (bus 001, address 005, ID 1935:0b2b) DEBUG:overwitch.c:392:ow_get_device_desc_from_vid_pid: Device with PID 2859 found DEBUG:engine.c:644:ow_engine_init: USB transfer timeout: 10 DEBUG:engine.c:544:ow_engine_init_mem: Blocks per transfer: 24 DEBUG:engine.c:1385:ow_engine_load_overbridge_name: USB control in data (32 B): Digitakt II DEBUG:engine.c:1405:ow_engine_load_overbridge_name: USB control in data (16 B): 0041 1.03A DEBUG:jclient.c:218:jclient_set_sample_rate_cb: JACK sample rate: 48000 DEBUG:resampler.c:626:ow_resampler_set_samplerate: Setting resampler sample rate to 48000 DEBUG:jclient.c:828:jclient_run: Using RT priority -828408246... DEBUG:jclient.c:830:jclient_run: Registering ports... DEBUG:engine.c:1211:ow_engine_start: Starting h2o MIDI thread... ERROR:jclient.c:674:set_rt_priority: Could not set real time priority DEBUG:engine.c:1224:ow_engine_start: Starting audio and o2h MIDI thread... ERROR:jclient.c:674:set_rt_priority: Could not set real time priority DEBUG:jclient.c:208:jclient_set_buffer_size_cb: JACK buffer size: 1024 DEBUG:resampler.c:613:ow_resampler_set_buffer_size: Setting resampler buffer size to 1024 ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW Digitakt2 @ 001,005: o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000, avg. 1.000000

[dagargo]

All tracks need to be mono and other tracks are missing for sure. I don't know exactly how many but I've seen some videos where they claim that Digitakt II has 42 output tracks and 2 input tracks.

I couldn't find a document explaining this but based on the images and videos I've watched this is what you should try.

{
  "pid": 2859,
  "name": "Digitakt II",
  "input_track_names": [
    "Main L Input",
    "Main R Input"
  ],
  "output_track_names": [
    "Track 1 L",
    "Track 1 R",
    "Track 2 L",
    "Track 2 R",
    "Track 3 L",
    "Track 3 R",
    "Track 4 L",
    "Track 4 R",
    "Track 5 L",
    "Track 5 R",
    "Track 6 L",
    "Track 6 R",
    "Track 7 L",
    "Track 7 R",
    "Track 8 L",
    "Track 8 R",
    "Track 9 L",
    "Track 9 R",
    "Track 10 L",
    "Track 10 R",
    "Track 11 L",
    "Track 11 R",
    "Track 12 L",
    "Track 12 R",
    "Track 13 L",
    "Track 13 R",
    "Track 14 L",
    "Track 14 R",
    "Track 15 L",
    "Track 15 R",
    "Track 16 L",
    "Track 16 R",
    "Delay L",
    "Delay R",
    "Reverb L",
    "Reverb R",
    "Chorus L",
    "Chorus R",
    "Pattern L",
    "Pattern R",
    "Input L",
    "Input R"
  ]
}

[dagargo]

This is probably better. Same amount of tracks but main output pair first instead of that weird "pattern" tracks before the inputs.

{
  "pid": 2859,
  "name": "Digitakt II",
  "input_track_names": [
    "Main L Input",
    "Main R Input"
  ],
  "output_track_names": [
    "Main L",
    "Main R",
    "Track 1 L",
    "Track 1 R",
    "Track 2 L",
    "Track 2 R",
    "Track 3 L",
    "Track 3 R",
    "Track 4 L",
    "Track 4 R",
    "Track 5 L",
    "Track 5 R",
    "Track 6 L",
    "Track 6 R",
    "Track 7 L",
    "Track 7 R",
    "Track 8 L",
    "Track 8 R",
    "Track 9 L",
    "Track 9 R",
    "Track 10 L",
    "Track 10 R",
    "Track 11 L",
    "Track 11 R",
    "Track 12 L",
    "Track 12 R",
    "Track 13 L",
    "Track 13 R",
    "Track 14 L",
    "Track 14 R",
    "Track 15 L",
    "Track 15 R",
    "Track 16 L",
    "Track 16 R",
    "Delay L",
    "Delay R",
    "Reverb L",
    "Reverb R",
    "Chorus L",
    "Chorus R",
    "Input L",
    "Input R"
  ]
}

[nchouba]

thank you, what you shared makes a lot of sense. I have tried both but unfortunately I still get the same error.

[dagargo]

A couple of things to mention.

You seem to not be using a RT kernel. This value comes from JACK. This should have nothing to do with the LIBUSB_TRANSFER_OVERFLOW.

DEBUG:jclient.c:828:jclient_run: Using RT priority -828408246...

Please, post here the full output of overwitch-cli -vv till the LIBUSB_TRANSFER_OVERFLOW error appears. I want to check a couple of things that don't appear in the log above.

[nchouba]

Yes, I forgot to mention, I'm not using the RT kernel. here's the logs:

overwitch-cli -vv DEBUG:overwitch.c:392:ow_get_device_desc_from_vid_pid: Device with PID 2859 found DEBUG:overwitch.c:254:ow_get_usb_device_list: Found Digitakt II (bus 007, address 003, ID 1935:0b2b) DEBUG:overwitch.c:392:ow_get_device_desc_from_vid_pid: Device with PID 2859 found DEBUG:engine.c:644:ow_engine_init: USB transfer timeout: 10 DEBUG:engine.c:544:ow_engine_init_mem: Blocks per transfer: 24 DEBUG:engine.c:557:ow_engine_init_mem: o2h: USB in frame size: 168 B DEBUG:engine.c:558:ow_engine_init_mem: h2o: USB out frame size: 8 B DEBUG:engine.c:567:ow_engine_init_mem: o2h: USB in block size: 1208 B DEBUG:engine.c:569:ow_engine_init_mem: h2o: USB out block size: 88 B DEBUG:engine.c:577:ow_engine_init_mem: o2h: audio transfer size: 28224 B DEBUG:engine.c:579:ow_engine_init_mem: h2o: audio transfer size: 1344 B DEBUG:engine.c:1385:ow_engine_load_overbridge_name: USB control in data (32 B): Digitakt II DEBUG:engine.c:1405:ow_engine_load_overbridge_name: USB control in data (16 B): 0041 1.03A DEBUG:dll.c:162:ow_dll_host_init: Initializing host side of DLL... DEBUG:jclient.c:218:jclient_set_sample_rate_cb: JACK sample rate: 48000 DEBUG:resampler.c:626:ow_resampler_set_samplerate: Setting resampler sample rate to 48000 DEBUG:jclient.c:828:jclient_run: Using RT priority -775979446... DEBUG:jclient.c:830:jclient_run: Registering ports... DEBUG:jclient.c:835:jclient_run: Registering output port Main L... DEBUG:jclient.c:835:jclient_run: Registering output port Main R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 1 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 1 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 2 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 2 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 3 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 3 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 4 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 4 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 5 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 5 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 6 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 6 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 7 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 7 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 8 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 8 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 9 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 9 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 10 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 10 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 11 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 11 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 12 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 12 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 13 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 13 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 14 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 14 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 15 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 15 R... DEBUG:jclient.c:835:jclient_run: Registering output port Track 16 L... DEBUG:jclient.c:835:jclient_run: Registering output port Track 16 R... DEBUG:jclient.c:835:jclient_run: Registering output port Delay L... DEBUG:jclient.c:835:jclient_run: Registering output port Delay R... DEBUG:jclient.c:835:jclient_run: Registering output port Reverb L... DEBUG:jclient.c:835:jclient_run: Registering output port Reverb R... DEBUG:jclient.c:835:jclient_run: Registering output port Chorus L... DEBUG:jclient.c:835:jclient_run: Registering output port Chorus R... DEBUG:jclient.c:835:jclient_run: Registering output port Input L... DEBUG:jclient.c:835:jclient_run: Registering output port Input R... DEBUG:jclient.c:853:jclient_run: Registering input port Main L Input... DEBUG:jclient.c:853:jclient_run: Registering input port Main R Input... DEBUG:engine.c:1211:ow_engine_start: Starting h2o MIDI thread... ERROR:jclient.c:674:set_rt_priority: Could not set real time priority DEBUG:engine.c:1224:ow_engine_start: Starting audio and o2h MIDI thread... ERROR:jclient.c:674:set_rt_priority: Could not set real time priority DEBUG:dll.c:56:ow_dll_overbridge_init: Initializing Overbridge side of DLL... DEBUG:jclient.c:208:jclient_set_buffer_size_cb: JACK buffer size: 1024 DEBUG:resampler.c:613:ow_resampler_set_buffer_size: Setting resampler buffer size to 1024 DEBUG:resampler.c:136:ow_resampler_reset_buffers: Resetting buffers... DEBUG:resampler.c:117:ow_resampler_clear_buffers: Clearing buffers... DEBUG:dll.c:174:ow_dll_host_reset: Resetting the DLL... DEBUG:resampler.c:199:ow_resampler_reset_dll: DLL target delay: 1872 frames (39.000000 ms) ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW DEBUG:resampler.c:402:ow_resampler_compute_ratios: Starting up resampler... Digitakt II @ 007,003: o2h latency: -1.0 [-1.0, -1.0] ms; h2o latency: -1.0 [-1.0, -1.0] ms, o2h ratio: 1.000000, avg. 1.000000

[nchouba]

I have produced the below log from playing around with rust nusb. endpoint address: 131 In, interval:1 packets_per_microframe:1 max_packet_size:1012 transfer_type: Interrupt

it seems that max_packet_size = 1012. When setting a multiple of 1012 as buffer size, I managed to receive packets using rust nusb crate. any number other then that it fails. Now I'm not sure how to map every packet to different audio channel. 1012 is a divisor of 44, shall I assume there is 44 channel ?

[dagargo]

1012 is a divisor of 44, shall I assume there is 44 channel ?

Trying that wouldn't hurt, would it? Add the tracks to the JSON definition and see.

I watched the Exploring Syntakt OS 1.30 and Digitakt II with Overbridge // Live Dispatch video and the track "Pattern" is here but not here.

Take a look at this for more information about the higher level packets.

Perhaps, with the new devices, the unknown section at the top had changed its size or is not used anymore. (I believe this is the low level Overbridge messages.)

https://github.com/dagargo/overwitch/blob/7e4743acb5dc1e1d00301c48b7e6df7cd8396ac9/src/engine.h#L73-L145

The package is defined here.

https://github.com/dagargo/overwitch/blob/7e4743acb5dc1e1d00301c48b7e6df7cd8396ac9/src/engine.h#L221-L227

[szszoke]

I'm about to try the new Overbridge update on Windows.

I will report back on the number of channels that I see.

[szszoke]

I am attaching some screenshots.

I see the 16 tracks with panning, so those must be stereo tracks. That makes 32 mono channels for the tracks.

Then I see the Delay, Reverb and Chorus channels without panning but the VU meter still has two bars so they must be stereo. That means 6 additional mono channels. The total is 32 + 6 = 38 so far.

Then there is the main output which is two more mono channels. 38 + 2 = 40.

And then there is the external input, which is two more mono channels as well. That makes 40 + 2 = 42 output channels.

Both the OB app and the OB manual suggests that there are 4 stereo inputs: D.7 DIGITAKT II CHANNELS

If we go with that then there are 42 output channels and 8 input channels, or a total of 50.

I remember that when the Syntakt came out, it actually had fewer channels than what the manual or the OB app suggested so I don't know if we can trust the manual.

[szszoke]

I am not sure if it matters but the USB descriptors look different.

Digitakt USB descriptors

Elektron Digitakt II Manufacturer: Elektron Music Machines Serial Number: 000000000001 Speed: 480Mb/s (high) Bus: 1 Address: 20 USB Version: 2.00 Device Class: ef Device Subclass: 02 Device Protocol: 01 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: 1935 Product Id: 0b2b Revision Number: 00.01 Config Number: 1 Number of Interfaces: 6 Attributes: c0 MaxPower Needed: 0mA Interface Number: 0 Name: (none) Alternate Number: 0 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 0 Interface Number: 1 Name: (none) Alternate Number: 0 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 0 Interface Number: 2 Name: (none) Alternate Number: 0 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 0 Interface Number: 3 Name: (none) Alternate Number: 0 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 2 Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 82 Direction: in Attribute: 3 Type: Interrupt Max Packet Size: 64 Interval: 125us Interface Number: 4 Name: snd-usb-audio Alternate Number: 0 Class: 01 Sub Class: 01 Protocol: 00 Number of Endpoints: 0 Interface Number: 5 Name: snd-usb-audio Alternate Number: 0 Class: 01 Sub Class: 03 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

Digitakt II USB descriptors

Elektron Digitakt Manufacturer: Elektron Music Machines Serial Number: 000000000001 Speed: 480Mb/s (high) Bus: 1 Address: 17 USB Version: 2.00 Device Class: ef Device Subclass: 02 Device Protocol: 01 Maximum Default Endpoint Size: 64 Number of Configurations: 1 Vendor Id: 1935 Product Id: 0b2c Revision Number: 00.01 Config Number: 1 Number of Interfaces: 6 Attributes: c0 MaxPower Needed: 0mA Interface Number: 0 Name: (none) Alternate Number: 0 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 0 Interface Number: 1 Name: usbfs Alternate Number: 3 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 83 Direction: in Attribute: 3 Type: Interrupt Max Packet Size: 368 Interval: 125us Interface Number: 2 Name: usbfs Alternate Number: 3 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 1 Endpoint Address: 03 Direction: out Attribute: 3 Type: Interrupt Max Packet Size: 88 Interval: 125us Interface Number: 3 Name: usbfs Alternate Number: 0 Class: ff Sub Class: 00 Protocol: 00 Number of Endpoints: 2 Endpoint Address: 02 Direction: out Attribute: 2 Type: Bulk Max Packet Size: 512 Interval: 0ms Endpoint Address: 82 Direction: in Attribute: 3 Type: Interrupt Max Packet Size: 64 Interval: 125us Interface Number: 4 Name: (none) Alternate Number: 0 Class: 01 Sub Class: 01 Protocol: 00 Number of Endpoints: 0 Interface Number: 5 Name: usbfs Alternate Number: 0 Class: 01 Sub Class: 03 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

[dagargo]

I've just created the fix-overbridge-cc-midi branch to work on this issue and on #66.

66 is needed for the Digitakt II to work.

[szszoke]

I am comparing the USB endpoints of the DT1 and DT2. They both have the same descriptors but two endpoints on the DT2 have a larger max packet size.

One endpoint is 0x83 which went from 368 to 1012 bytes and another is 0x03 which from 88 to 256 bytes.

0x83 is for data coming from the DT. 0x03 is for data going towards the DI.

I cannot see a correlation between the packet size and the number of channels between the two devices.

[dagargo]

I don't think the error is related to the incorrect inputs but that is surely wrong.

This is a Overbridge-to-host transfer error. But perhaps it's caused by the incorrect inputs and we don't see the relation. Keep in mind that this was caused by the code at master not the code in fix-overbridge-cc-midi.

ERROR:engine.c:322:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW

Have any of you tested this configuration?

  {
    "pid": 2859,
    "name": "Digitakt II",
    "input_track_names": [
      "Main L Input",
      "Main R Input",
      "Delay L Input",
      "Delay R Input",
      "Reverb L Input",
      "Reverb R Input",
      "Chorus L Input",
      "Chorus R Input"
    ],
    "output_track_names": [
      "Main L",
      "Main R",
      "Track 1 L",
      "Track 1 R",
      "Track 2 L",
      "Track 2 R",
      "Track 3 L",
      "Track 3 R",
      "Track 4 L",
      "Track 4 R",
      "Track 5 L",
      "Track 5 R",
      "Track 6 L",
      "Track 6 R",
      "Track 7 L",
      "Track 7 R",
      "Track 8 L",
      "Track 8 R",
      "Track 9 L",
      "Track 9 R",
      "Track 10 L",
      "Track 10 R",
      "Track 11 L",
      "Track 11 R",
      "Track 12 L",
      "Track 12 R",
      "Track 13 L",
      "Track 13 R",
      "Track 14 L",
      "Track 14 R",
      "Track 15 L",
      "Track 15 R",
      "Track 16 L",
      "Track 16 R",
      "Delay L",
      "Delay R",
      "Reverb L",
      "Reverb R",
      "Chorus L",
      "Chorus R",
      "Input L",
      "Input R"
    ]
  }

[szszoke]

I have and I just get a barrage of ERROR:engine.c:295:cb_xfr_audio_in: o2h: Error on USB audio transfer: LIBUSB_TRANSFER_OVERFLOW error messages.

[szszoke]

My DT1 works fine on the same USB port and via the same cable so at least it should not be an issue with my system configuration.

[szszoke]

The error is also present on fix-overbridge-cc-midi. I just don't MIDI errors.

[szszoke]

We get 8832 bytes from the DT1 which is 24 368 or in other words 24 the packet size of the 0x83 endpoint.

By applying the same logic, I would expect to have 24288 bytes coming from the DT2 but it is only 2112 instead.

[szszoke]

Ignore that. I forgot that I made some changes to my devices.json file.

[nchouba]

I think there are 21 blocks sent in 0x83 for DTII. I see 21252 bytes in the interrupt response through wireshark, 21252/1012 = 21, does that make sense?

[szszoke]

audio_in_blk_len seems to come out too high. It is 1208 for the DT2 but it is 368 for the DT1. I was actually able to make the errors disappear by reducing the number of output channels to 35. That way audio_in_blk_len was 1012 The only sound I got was noise from a single channel, but there were no errors at least.

[dagargo]

devices.json updated.

@szszoke, there is no relation between Max Packet Size and the transfer size at usblevel AFAIK.

The library takes care of this and splits a high level transfer into as many USB packet transfers as needed.

But... https://libusb.sourceforge.io/api-1.0/libusb_packetoverflow.html

You mention 1012 but I don't see that number in the device descriptors.

[szszoke]

@dagargo 1012 is mentioned here:

sudo lsusb -v -d 1935:0b2b

``` Bus 001 Device 020: ID 1935:0b2b Elektron Music Machines Elektron Digitakt II Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 239 Miscellaneous Device bDeviceSubClass 2 [unknown] bDeviceProtocol 1 Interface Association bMaxPacketSize0 64 idVendor 0x1935 Elektron Music Machines idProduct 0x0b2b Elektron Digitakt II bcdDevice 0.01 iManufacturer 1 Elektron Music Machines iProduct 2 Elektron Digitakt II iSerial 3 000000000001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x0107 bNumInterfaces 6 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 0 bInterfaceCount 4 bFunctionClass 255 Vendor Specific Class bFunctionSubClass 0 [unknown] bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0058 1x 88 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x03f4 1x 1012 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0020 1x 32 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0058 1x 88 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0100 1x 256 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 [unknown] bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 1 Interface Association: bLength 8 bDescriptorType 11 bFirstInterface 4 bInterfaceCount 2 bFunctionClass 1 Audio bFunctionSubClass 1 Control Device bFunctionProtocol 0 iFunction 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 0x0009 bInCollection 1 baInterfaceNr(0) 5 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 5 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 1 Audio bInterfaceSubClass 3 MIDI Streaming bInterfaceProtocol 0 iInterface 0 MIDIStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 0x0041 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 1 Embedded bJackID 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 2 External bJackID 2 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 1 Embedded bJackID 3 bNrInputPins 1 baSourceID( 0) 2 BaSourcePin( 0) 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 2 External bJackID 4 bNrInputPins 1 baSourceID( 0) 1 BaSourcePin( 0) 1 iJack 0 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (Invalid) bNumEmbMIDIJack 1 baAssocJackID( 0) 1 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (Invalid) bNumEmbMIDIJack 1 baAssocJackID( 0) 3 Device Status: 0x0100 (Bus Powered) ```

[szszoke]

I can confirm what @nchouba has found that there only seem to be 21 frames sent. This is also true for the DT1. I guess this depends on how many frames is asked for by OB/OW.

[szszoke]

I did some more thinking and testing.

We have 1012 bytes for a frame. He first 2 bytes are for a fixed header. The second two are for the frame counter. That leaves us with 1008 bytes. The calculated frame size by OW is 168 bytes. OW is calculating with 7 frames but I figured that was too much.

I tried to play around with OB_PADDING_LEN and OB_FRAMES_PER_BLOCK

OB_PADDING_LEN	OB_FRAMES_PER_BLOCK	Overflow errors	Sound from main outputs
0	6	no	disted sound even when nothing playing
168	5	no	distorted sound but it seems to resemble what is actually playing
336	4	no	distorted sound but it seems to resemble what is actually playing

The channel names do not seem to reflect the actual channels that can be heard. I need to do more digging.

[dagargo]

A few things to mention.

I've pushed 71ec6c6c244c4f3d149365758b18f0cec9131484 to print the actual transfer length in case of error.

This is an explanation for the log and the calculated sizes.

This is the amount of channels times the sample size (4 B).

DEBUG:engine.c:557:ow_engine_init_mem: o2h: USB in frame size: 168 B
DEBUG:engine.c:558:ow_engine_init_mem: h2o: USB out frame size: 8 B

This is block header (32 B or 4 B plus OB_PADDING_LEN) plus 7 times (7 frames) the frame size.

DEBUG:engine.c:567:ow_engine_init_mem: o2h: USB in block size: 1208 B
DEBUG:engine.c:569:ow_engine_init_mem: h2o: USB out block size: 88 B

This is the previous value times the amount of blocks.

DEBUG:engine.c:577:ow_engine_init_mem: o2h: audio transfer size: 28224 B
DEBUG:engine.c:579:ow_engine_init_mem: h2o: audio transfer size: 1344 B

[szszoke]

The calculated USB block size for the DT1 is the same as the packet length for the 0x31 USB endpoint but for the DT2 it ends up being larger. When I tweaked things to get that number to 1012 then the overflow errors went away but even then the sound is very distorted.

[szszoke]

@dagargo xfr->actual_length seems to be 0 so the lines you added print 0 B. xfr->length seems to hold non-zero values.

[szszoke]

I missed this log line (there are a lot of them):

DEBUG:resampler.c:263:resampler_o2h_reader: o2h: Audio ring buffer underflow (0 < 16800). Replicating last samples...

[szszoke]

I also noticed that If I just play a trig, some of them don't make any sound but some of them do, and those start out more like noise but near the end they sound very close to what they should be sounding.

[dagargo]

I think I've understood you both now. Looks that you're right and wMaxPacketSize is the Overwitch block size. I never realized about it!

The amount of tracks can be inferred then from the block size.

Digitakt (368 B):

>>> (368 - 32) / 7 / 4
12.0

Digitakt II (1012 B):

>>> ((1012 - 32) / 7) / 4
35.0

Digitakt II input (256 B) matches too.

Perhaps some tracks are 16 bits and other 32 bits or even 24 bits. However, the frame size should be 140 B.

Enough for today.

[szszoke]

I am comparing data packets of silence and then the individual tracks playing. 8 additional bytes after the 28 bytes of padding don't seem to respond any way when I am playing some tracks.

The next 8 bytes light up however when I play track 1. Then the next 8 bytes light up when I play track 2.

This to me suggests that the outputs from the tracks are 4 bytes for each channel.

I will test all the channels just to confirm.

[szszoke]

I had to do some extra checks with panning the tracks to left and right to make sure but based on what bytes are changing when individual tracks are played some tracks send 4 bytes per channel and some send 3 bytes per channel.

Track 1- 6 has 4 bytes / channel. Track 7 - 16 has 3 bytes / channel.

There are some sections that never go back to zero when I am not playing anything so I'm guessing they are not containing any audio.

I am attaching a ZIP file with my captured packets.

dt2_packets.zip

[dagargo]

@szszoke and I have been working a solution to make the Digitakt II to work with Overwitch. We have tested and it's fully working now.

@nchouba, could you please give it a try and report here?

Once you confirm this, I'll merge the branch into master.

[dagargo]

The solution is in the fix-overbridge-cc-midi branch, which has been rebased.

[nchouba]

wow, you are really amazing guys it works :). just curios about the change, is the first 14th channels require a bit shift?

[dagargo]

is the first 14th channels require a bit shift?

Yes, it's exactly that. The remaining channels are 3 bytes only.

[dagargo]

Branch merged into master.