[alsa-devel] Steinberg MIDEX8 driver attempt
Dear Alsa developers,
I've owned a MIDEX8 for some years now and am now attempting a driver for it. The current results can be found at https://github.com/sgorpi/midex8 I've started with a libusb implementation, and when that worked moved to a kernel driver.
it looks a bit like the standard usb midi class, but it requires some periodic (i guess timer) messages on endpoint 0x02, and control (or just LED) messages on EP 0x06 and responses on EP 0x86. Therefore, I've took quite some inspiration from the sound/usb/midi.c driver.
In general, it seems to work now for simple cases, but I'm having a few issues, that might be due to my lack of knowledge on the USB subsystem, or something else. In the (simplified) libusb test in the above repository, I do not seem to have these issues.
Issue 1: Not all (interrupt) urbs that are submitted will complete (within 25 ms at least). Wireshark doesn't show the packets being sent out, and the completeion handler never gets called for those urbs, but also no errors are given by usb_submit_urb. This happens mainly with the timer messages, and my current solution is to unlink the urbs that haven't completed within 25ms. However, I feel there is something going wrong there. If I do not send urbs on the midi-in endpoint, I do not see any missing urbs... Do I have to mutex anything for a shared urb queue or so?
Issue 2: Sometimes after sending a few messages, an empty urb shows up in wireshark. However, in code, there's an if-statement that should allow only messages of length > 0 to be submitted (line 568, if (num_read > 0)). Might this have to do with issue 1?
Next to those are some other minor issues, but I'd like to get these two sorted out first, before improving on the driver some more.
If you could give me any advice on the above issues that would be highly appreciated! (And in case you have another list that focuses on USB related questions, that is welcome too).
With kind regards, Hedde
Hedde Bosman wrote:
I've owned a MIDEX8 for some years now and am now attempting a driver for it. [...] it looks a bit like the standard usb midi class, but it requires some periodic (i guess timer) messages on endpoint 0x02
Why "requires"? What happens if you do not send them?
Not all (interrupt) urbs that are submitted will complete (within 25 ms at least).
And why would that be a problem?
Sometimes after sending a few messages, an empty urb shows up in wireshark. However, in code, there's an if-statement that should allow only messages of length > 0 to be submitted (line 568, if (num_read > 0)).
Try adding a check before the actual usb_submit_urb() call, but nothing would protect against your code accidentally changing the transfer_buffer_length of an active URB field later.
Might this have to do with issue 1?
Not unless you have mixed up input and output URBs.
Regards, Clemens
Hi Clemens,
thanks for responding.
On Sun, May 28, 2017 at 10:16 PM, Clemens Ladisch clemens@ladisch.de wrote:
Hedde Bosman wrote:
I've owned a MIDEX8 for some years now and am now attempting a driver for it. [...] it looks a bit like the standard usb midi class, but it requires some periodic (i guess timer) messages on endpoint 0x02
Why "requires"? What happens if you do not send them?
Without sending those, the midi in does not seem to work.
Not all (interrupt) urbs that are submitted will complete (within 25 ms at least).
And why would that be a problem?
I am not sure about the inner workings of the device. However, it seems to be a timing signal, that might be used to time-stamp midi in packets. I haven't been able to determine the exact impact, but did notice that sometimes the midi-in stops responding. If that is related, I cannot tell.
Sometimes after sending a few messages, an empty urb shows up in wireshark. However, in code, there's an if-statement that should allow only messages of length > 0 to be submitted (line 568, if (num_read > 0)).
Try adding a check before the actual usb_submit_urb() call, but nothing would protect against your code accidentally changing the transfer_buffer_length of an active URB field later.
I will try and report back later.
Might this have to do with issue 1?
Not unless you have mixed up input and output URBs.
afaik I did not. I am looking for better ways to debug though.
Regards, Clemens
Regards, Hedde
On Sun, May 28, 2017 at 10:49 PM, Hedde Bosman sgorpi@gmail.com wrote:
Hi Clemens,
thanks for responding.
On Sun, May 28, 2017 at 10:16 PM, Clemens Ladisch clemens@ladisch.de wrote:
Hedde Bosman wrote:
I've owned a MIDEX8 for some years now and am now attempting a driver for it. [...] it looks a bit like the standard usb midi class, but it requires some periodic (i guess timer) messages on endpoint 0x02
Why "requires"? What happens if you do not send them?
Without sending those, the midi in does not seem to work.
Not all (interrupt) urbs that are submitted will complete (within 25 ms at least).
And why would that be a problem?
I am not sure about the inner workings of the device. However, it seems to be a timing signal, that might be used to time-stamp midi in packets. I haven't been able to determine the exact impact, but did notice that sometimes the midi-in stops responding. If that is related, I cannot tell.
Sometimes after sending a few messages, an empty urb shows up in wireshark. However, in code, there's an if-statement that should allow only messages of length > 0 to be submitted (line 568, if (num_read > 0)).
Try adding a check before the actual usb_submit_urb() call, but nothing would protect against your code accidentally changing the transfer_buffer_length of an active URB field later.
I will try and report back later.
Even with such a check before usb_submit_urb, I still see an empty urb appear on the timing endpoint (after which the midi in doesn't work anymore). What seems to happen (during operations) is the following: 1. Several midi-in urbs are queued on EP 0x82, one is requested and awaiting completion 2. After some time that midi-in urb is completed (due to a CC) 3. Another queued midi-in urb is requested (after 1.2 ms) 4. After 0.07 ms, a spurious timing-out urb appears on EP 0x02 (the timing signal) with zero length data. (both are endpoint 2 but in different directions) 5. Midi in stops working.
This happened even after adding a spinlock on any operations on EP 0x82 and 0x02 ... I'm lost here.
Might this have to do with issue 1?
Not unless you have mixed up input and output URBs.
afaik I did not. I am looking for better ways to debug though.
Regards, Clemens
Regards, Hedde
Hi all,
After many testing, the empty URB problem seems to be caused by testing in VirtualBox, but I didn't investigate in detail... Using the MIDEX driver without any virtualization seems to work just fine (tested with Renoise, Bitwig and nmEdit (nomad) for the Nord Modular).
Meanwhile I did change the code to be more in line with the ALSA USB midi driver (wrt midi message handling and URB buffer allocation) and to follow style rules.
I'd love to hear experience from other MIDEX8 users. And if one has a MIDEX3, please send me some USB traces of windows interacting with it, to see if it is the same as the MIDEX8.
With kind regards, Hedde
On Sun, May 28, 2017 at 11:38 PM, Hedde Bosman sgorpi@gmail.com wrote:
On Sun, May 28, 2017 at 10:49 PM, Hedde Bosman sgorpi@gmail.com wrote:
Hi Clemens,
thanks for responding.
On Sun, May 28, 2017 at 10:16 PM, Clemens Ladisch clemens@ladisch.de wrote:
Hedde Bosman wrote:
I've owned a MIDEX8 for some years now and am now attempting a driver for it. [...] it looks a bit like the standard usb midi class, but it requires some periodic (i guess timer) messages on endpoint 0x02
Why "requires"? What happens if you do not send them?
Without sending those, the midi in does not seem to work.
Not all (interrupt) urbs that are submitted will complete (within 25 ms at least).
And why would that be a problem?
I am not sure about the inner workings of the device. However, it seems to be a timing signal, that might be used to time-stamp midi in packets. I haven't been able to determine the exact impact, but did notice that sometimes the midi-in stops responding. If that is related, I cannot tell.
Sometimes after sending a few messages, an empty urb shows up in wireshark. However, in code, there's an if-statement that should allow only messages of length > 0 to be submitted (line 568, if (num_read > 0)).
Try adding a check before the actual usb_submit_urb() call, but nothing would protect against your code accidentally changing the transfer_buffer_length of an active URB field later.
I will try and report back later.
Even with such a check before usb_submit_urb, I still see an empty urb appear on the timing endpoint (after which the midi in doesn't work anymore). What seems to happen (during operations) is the following:
- Several midi-in urbs are queued on EP 0x82, one is requested and
awaiting completion 2. After some time that midi-in urb is completed (due to a CC) 3. Another queued midi-in urb is requested (after 1.2 ms) 4. After 0.07 ms, a spurious timing-out urb appears on EP 0x02 (the timing signal) with zero length data. (both are endpoint 2 but in different directions) 5. Midi in stops working.
This happened even after adding a spinlock on any operations on EP 0x82 and 0x02 ... I'm lost here.
Might this have to do with issue 1?
Not unless you have mixed up input and output URBs.
afaik I did not. I am looking for better ways to debug though.
Regards, Clemens
Regards, Hedde
participants (2)
-
Clemens Ladisch -
Hedde Bosman