On Sun, May 28, 2017 at 10:49 PM, Hedde Bosman <sgorpi@xxxxxxxxx> wrote: > Hi Clemens, > > thanks for responding. > > On Sun, May 28, 2017 at 10:16 PM, Clemens Ladisch <clemens@xxxxxxxxxx> 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
