Kalvas, Taneli wrote:
I have tested the system by connecting the output port to an input port on the hardware and having another program output the received bytes on stdout. My observations:
- As long as the buffer size is 276 bytes or less it gets sent ok
- Larger buffer sizes cause corruption and roughly 300 bytes of received.
This sounds as if the device has a buffer size of 256 bytes, but does not actually check if the buffer is full, and always accepts more data.
Does later data overwrite data that should have been sent earlier?
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 ...
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.
Regards, Clemens