Hi All.
Ark contacted me on our Discord server, which is where we do support for the new Windows MIDI Services stack. Windows MIDI / Audio . There’s also info there in #start-here for how to disable the new MIDI feature if you are completely blocked.
There are a few things in this thread that are important to clarify
- The only drivers that cause service crashing right now are inMusic (AKAI, m-audio, RANE, etc.). We are working with inMusic on getting their drivers fixed. In most cases, you can simply uninstall their drivers and use our in-box drivers. Although we’d love people to use our in-box class drivers now that everything is multi-client, third-party drivers are still supported. We have customer reports of these drivers hanging on close in the past, before the rollout, but that would impact only the single app and could be cleared by unplugging the device. With the new service involved, trying to close these drivers hangs every MIDI device.
- If you use KORG drivers, KORG has already posted recommending that you remove them and use our in-box drivers. These don’t cause service crashes, but the install/uninstall and other helper tools do mess up the registry. If, for example, tools like MIDI-OX cannot see any MIDI ports, this is almost always the reason why. We have info on the Discord server.
- Those drivers have been a problem for the last 20 years and are responsible for why people think you can have only 10 MIDI devices in Windows. It’s because they use the circa-1993 driver model instead of something more modern.
- We even have a tool in the SDK Runtime and Tools download which is used to fix the registry for 64 bit apps. Currently, it does not fix it for 32 bit apps like MIDI-OX, but I will update it to do so.
- The packet size issue in the descriptors is pretty common. We don’t block drivers based on that. It would be nice to see it fixed, but again, not unusual.
- If you change the driver a device is using, you usually need to restart the MIDI service or reboot your PC. This is a limitation we’re working to get around, but right now we do not get the correct notifications from the system for many devices that a device was removed and readded. This doesn’t always happen, but it is common. It’s quite likely what you are seeing here.
- USB Audio Device 1.0 is our combined MIDI 1.0 and USB Audio 1.0 class driver. We’ve fixed a couple SysEx bugs in that, but otherwise, it’s the same driver that has been in Windows for ages.
- USB MIDI2 ACX is the new combined MIDI 1.0 and MIDI 2.0 class driver. It supports class-compliant MIDI 1 and MIDI 2 (UMP) devices, and is faster than the older driver. There are a few devices out there that, because of how their USB descriptors are set up, get automatically assigned to this driver.
- The new driver supports all class-compliant MIDI 1 devices. If it’s not working here, we’d like to know.
- We did harden descriptor checks in Windows 11 close to a year ago for security reasons. However, descriptor failures that block on Windows will block 100% of the time, not randomly, so I don’t think firmware is the issue here, at least not the part generating descriptors.
For any questions related to the new MIDI stack, please join the Discord server Windows MIDI / Audio and see #start-here for where to post and where the information can be found.
Pete
Microsoft