[alsa-devel] RawMIDI behaviour with MidiFace 4x4

[Kalvas, Taneli]

>> By looking at the receiving end bytes it looks exactly like that has happened.
>
> This pretty much proves that this is a bug in the device firmware.
> 
> You might try contacting Miditech ...

I have sent an email to them, but as we all know, most probably they are not going to even answer me. 

This is a common problem with many devices across several brands of devices and influences not only Linux but also other systems (see for example a  list by wabbiguy at http://forum.highlyliquid.com/archive/index.php/t-500.html). There seems to be some user space software, which provide the same type of delay that I used to work around this problem. In my opinion this should not be done in user space, even though I tested that it works. I am going to propose something wild: What do you think about a possibility for a customized driver for this class of hardware (I mean usb compliant midi interfaces with broken output ring buffer)? If the kernel driver would use timing utilities to regulate the speed of data written to the device, this could provide a dirty fix for this type of hardware. It wouldn't be the first driver workaround for broken hardware. Does this sound doable? I think a relatively small amount of code could provide a fix for several different devices and therefore increase their value for their users.

>>>> Is there a way to connect two programs via a virtual RawMIDI port so
>>>> that I could test without using the hardware?
>>>
>>> Load the snd-virmidi module, and connect two of its ports with aconnect.
>>
>> I did this and by using the virtual ports the behaviour is more
>> reasonable, but still not as expected. Everything works ok as long as
>> the message length is less than or equal to the buffer size (4096).
>> With message sizes larger than that the writing end still claims it
>> has sent everything, as it should do because the port is opened in
>> blocking mode. On the reading end I can see that some data is missing
>> and xruns are reported.
>
> Oops, using snd-virmidi this way also goes through the sequencer, which
> does not do blocking.
> 
> There is no other way to get a virtual RawMIDI port.
> 
> However, the driver was tested with lots of other devices, and huge
> SysEx messages have this problem only with your device.

Ok. You have me convinced.

Taneli