[alsa-devel] Steinberg MIDEX8 driver attempt

[Hedde Bosman]

On Sun, May 28, 2017 at 10:49 PM, Hedde Bosman <sgorpi at gmail.com> wrote:
> Hi Clemens,
>
> thanks for responding.
>
> On Sun, May 28, 2017 at 10:16 PM, Clemens Ladisch <clemens at 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