[alsa-devel] Steinberg MIDEX8 driver attempt

[Hedde Bosman]

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 at gmail.com> wrote:
> 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