Here are the known limitations.
- There’s probably a limit to the number of devices you can operate at the same time. There is code in the HCD (host controller driver) to reuse the fixed resources, but it has not been extensively tested. MCCI has a test tree of 30+ hubs and 90+ mass storage devices that we use for enumeration testing; once we have clear instructions that I can give our test lab so we can set up Win10 here on a Pi, we can at least run tests and record problems.
- Even if multiple devices work, it is certain that performance will decrease if you have more than a few devices active. Only 8 transfers can be active on the USB bus at one time. We attempt to rotate the operations through the hardware, but for use cases like video conferencing while recording to a USB SSD (think of Zoom, for example), things may get quirky. (Video conferencing while recording needs high-bandwidth isoch in for the webcam, usually; audio is 2 channels for IN and OUT, mass storage has a channel for the data transfer… it seems possible, but there are also channels for hubs, HID class, controls on audio, etc.)
- webcams may have issues.
- audio works but again has not been really stress tested (looking for pops, etc.) Making audio work is “hard real-time” – we have to service the hardware and schedule new stuff every 125 us.
- although I wrote Windows portion of the code very defensively, it’s possible that there are BSODs lurking, especially because of the inevitable differences between the MCCI implementation and the Microsoft implementation. (Our core code is portable and OS agnostic; all the WIndows-isms are at the edge. Microsoft wrote to their APIs. This results in much different synchronization patterns and callback patterns to the client drivers.)
Most of the above can probably be fixed. But it probably requires my time, because I did all the low-level Windows work, and I have severe constraints.
Feel free to report issues here (or go to the MCCI support portal to get an official ticket number.)