[Feature] Consistent, low latency transmission through USB Driver

[AmeNote-Michael]

Is your feature request related to a problem? Please describe.
The USBMIDI2.sys driver currently does not limit the number of USB packets it can store to transmit. In theory the driver can back log messages, increasing the latency through driver for USB OUT messages. This creates non-predictability for the applications ultimately using the driver.

Describe the solution you'd like
The driver should maitain a minimal buffer depth for servicing the USB data to and from the device.

Describe alternatives you've considered
a 3 or 4 USB Packet storage limit, 1 for currently transmitting, one for processing data to be transmitted and 1 for the next packet to transmit.

Do you wish to contribute a solution?
Yes

Additional context
This comes from evaluation of optimization of device driver architecture. It moves the latency to the Streaming engine which has a large buffer of USB events. This buffer management should also be considered for further performance optimization. The transmission and reception of data from the service through to the physical hardware should be consistent and as low latent as possible.

[AmeNote-Michael]

Regulation of the USB Write (Out) routine to limit writes - PR #683

[Psychlist1972]

This is waiting on the Canary build for confirmation and then AMEI testing

[AmeNote-Michael]

@Psychlist1972 in our opinion, the driver has done what it can for this feature. We make sure we limit the number of active URBs in USB Out. For USB In, we process and pass up messages as fast as we can.

Any further development for this feature will need to be done in higher levels.

Can we remove driver as a dependency?

[Psychlist1972]

@Psychlist1972 in our opinion, the driver has done what it can for this feature. We make sure we limit the number of active URBs in USB Out. For USB In, we process and pass up messages as fast as we can.

Any further development for this feature will need to be done in higher levels.

Can we remove driver as a dependency?

It's marked as "fixed, awaiting public release" until it makes it out into the insider builds. No reason to remove the driver area from it, as you did work there.