[BUG] Receive interval between multiple messages in a packet is not stable.

[masahirokakishita]

The receive interval between multiple messages in a packet is not stable.

The included program, notesend.uf2 for raspberry pi pico sends eight Note On messages approximately once every second.
One packet contains eight messages.

sendnote.uf2.zip

When these messages are received with midi.exe, the receive interval between each message varies.
At the shortest, it can be a few usec, and at the longest, it can be over 100 usec.
In the following picture, 999.72msec, 999.99msec and 999.80msec is the packet interval.
177.90usec is maxmum and 8.40usex is minimum.

Since there are eight Note On messages packaged in one packet.
I would like the receive interval to be a stable few usec.
Or is this only a display problem?
Is there an API to receive messages in packets?

USBMIDI2_10.0.1.5_x64
Windows.MIDI.Services.App.SDK.Runtime.-.Developer.Preview.6.1.0.24194.2233-x64.exe
Windows.MIDI.Services.Console.-.Developer.Preview.6.1.0.24194.2233-x64.exe
Windows.MIDI.Services.In-Box.Service.-.Developer.Preview.6.1.0.24194.2233-x64.exe

[Psychlist1972]

In Windows MIDI Services and the SDK, we deal with one UMP message at a time when reading/writing to the queues, and routing. This enables us to easily add features like routing, translation, and more without having to break apart packets of data and reallocate memory.

Getting the data to/from USB is the slower part, so optimizing there in the driver is good to do, which is why Michael put in the multiple message/packet support for outgoing messages (I'd need to look at what actually comes in over USB from the protozoa in this case for incoming messages, however as I don't have the source code for your firmware)

The outlier of 178us could be due to system activity, or perhaps garbage collection in the C# client app. But that's still less than 1/5 of 1 millisecond.

Tens of microseconds is an acceptable delta between messages in my opinion. Do you disagree?

[masahirokakishita]

It is ideal for an app to receive each message in a single packet with no interval between each message.

The outlier of 178us could be due to system activity, or perhaps garbage collection in the C# client app. But that's still less than 1/5 of 1 millisecond.

In the case below, even though it is a single packet message, the last message, 0x97908800 000033C7 is delayed by about 0.5 msec from the first message, 0x40901199 000033C0. I think it's long, but the opinion is divided as to whether this number is a problem.

Tens of microseconds is an acceptable delta between messages in my opinion. Do you disagree?

I'm not sure if this number is acceptable.
To reduce jitter, I could consider using jitter reduction timestamps.
The accuracy of the JR Timestamp is 32 usec.
Will this cause a problem if 170 usec of jitter on the PC side is added when the JR Timestamp is received?
I don't have any know-how about the JR Timestamp, so I can't give you a definite answer.

[Psychlist1972]

We'll need to check this with a C++ app, which will have more consistent performance if this is a client issue.