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