[BUG]: MIDI Services slower data transfer speed compared to classic WinMM

[sat-okada]

Windows Version

27954.br_release.250919-1230

Service Installation Method

GitHub

SDK version, if appropriate

1.0.13-preview.13.192

Location

Application using WinMM MIDI 1.0 (Classic API)

Type of bug

Application not working as expected

Steps to reproduce

Report about two type of message.

The first is about Note On/Note Off messages.

1. Install UUT_USB_MIDI_ECHO_NO_PRINTF.uf2 on ProtoZOA
   This works like looping back a message sent from the Host.
2. Connect ProtoZOA to PC.
3. Use USBAUDIO.sys
4. Pocket MIDI loads 65536/131072/262144/524288 Note On/Off messages in System Exclusive window
5. Sends messages
6. Measure the time until all messages returned by loopback are received by Pocket MIDI's MIDI In Monitor
   Comparing with MIDI Services installed and uninstalled, the former takes 1.2 to 1.3 times longer.

The second is about SysEx messages.

1. Connect SEQTRAK to PC via USB.
   This is Full-Speed device.
2. Launch SEQTRAK App
3. Use USBAUDIO.sys
4. Select PROJECT/SOUND MANAGER
   Backup projectBackup process uses SysEx messages, which are sent in SEQTRAK MaxPacketSize (64KB) increments.
5. Measure the time until the progress bar extends to the end and the backup is completed.

Comparing with MIDI Services installed and uninstalled, the former takes 1.6 to 1.8 times longer.
As for SysEx, changing to Usbmidi2.sys slows it down about 2x more.

Expected behavior

MIDI Services installed, same transfer rate as before.

Additional notes

No response

[Psychlist1972]

Thank you for your testing here.

[Psychlist1972]

I am looking into this and have some ideas for how to fix it. One of the biggest issues here is the way we send messages to our MIDI 1 driver.

[Psychlist1972]

Expected behavior
MIDI Services installed, same transfer rate as before.

One more note: With the old MIDI 1 driver, I do expect some overhead with the new service approach. It used to be that MIDI 1 apps were effectively connecting directly to the driver to send and receive messages. That also limited us to not supporting more than one client for a driver. The new approach adds a lot more flexibility, but with the service in place, there's some overhead to talk to the old driver.

For the new driver, we should be able to get to faster performance for both MIDI 1 and MIDI 2 devices as well as lower jitter, even if we're not completely there on day 1.

[Psychlist1972]

Komorita-san has tested my fix to this and found the performance now matches older WinMM as expected. I'm going to apply this throughout the service and SDK, test everything, and then spin an update.