Sometimes creates really large SYSEX message when it is not

[MikeLoh]

On occasion I seem to get really large sysex messages in callback when actual message is not even close to 600 bytes. We have a system that never has a SYSEX message greater than 104 bytes, yet we can get suddenly extremely large sysex messages.

I am trying to get more data to share, but has anyone else encountered this issue?

[MikeLoh]

All - discovered why I am having this issue and wanted to feed back. No change in RtMidi is required, but an update to documentation may be good.

Basis: Most USB MIDI Class Compliant devices use USB 1.1 Full Speed connections. In USB Full Speed, the bulk packet size can be 8, 16, 32 or 64 bytes in size. However in High Speed USB 2.0, all bulk packets are 512 bytes in size.

Now when initiating RtMidiIn, as with most, I just used default constructor. After further debugging of code I found the issue with the buffering and management, causing corrupted packets being sent up to my routines - connected to the queueSizeLimit default of 100 bytes. In our case we have messages up to 128 bytes, so I needed to instantiate RtMidi with following instead:

#define RTMIDI_INPUT_QUEUE_SIZE 128

    try {
        pMIDIIn = new RtMidiIn(RtMidi::UNSPECIFIED, "HAL Input Client", RTMIDI_INPUT_QUEUE_SIZE);
    }
    catch ( RtMidiError &error ) {
        error.printMessage();
        exit( EXIT_FAILURE );
    }

Now my routines work as expected.

Note: this works for us cause we also manage our SYSEX commands such that only one can be issued at any one time to our device - this is to prevent too much MIDI blocking by SYSEX - un undesirable operation. However if we did allow more SYSEX commands to operate at the same time, our RTMIDI_INPUT_QUEUE_SIZE I suspect would need to be a multiple of the number of allowed simultaneous SYSEX commands.

Anyhow, hope this helps someone.

[garyscavone]

I don't understand this, as RTMIDI_INPUT_QUEUE_SIZE refers to the number of messages that will be stored in the queue, not the size (in bytes) of those messages.

[radarsat1]

Yup, something is weird about this analysis. I wonder if it is not actually related to queue threading issues instead. Large message copies might have different timing characteristics and lead to more contention for access collisions on the FIFO ring. I'll mark this as possibly related to #51. It's almost a year old unfortunately so if @MikeLoh can test more, please re-open.