[sdiy] Techniques for Multiplying MIDI Clock frequency?

[Mike Bryant]

> Another part is that High Speed did not exist when USB-MIDI was designed, so they didn't mention High Speed (and they haven't rewritten the USB-MIDI spec since).

https://www.usb.org/sites/default/files/USB%20MIDI%20v2_0.pdf

This is the one everybody should be following now, not the 1999 one which is deprecated.  Adds MIDI 2.0 but subtle changes to MIDI 1.0 as well



> In those days, nobody could afford to be Mac-only.

On the contrary, most people were Mac only back then, for example Sound Designer and its successors.  It took DigiDesign to release ProTools 3.21 PCI version in 1996/7 to really establish Windows in the studio.  Cubase did support Windows earlier but most people preferred how that ran on a Mac.  Even 25 years later some DJ creation tools are Mac/iOS only.



> I'm not sure what this "high bandwidth" mechanism is, other than the fact that Full Speed is a lot faster than 31.25 kbaud.

Page 18 of the old spec, deleted in the new one as an alternate mechanism is provided



> As M. Skala and I have been discussing, USB-MIDI 1.0 doesn't have to disallow Low Speed because USB in general disallows Bulk over Low Speed (and USB-MIDI requires Bulk).

Totally agree that is what the standard says, but if you actually try it quite a lot of equipment works.  Presumably this is because their 'low speed' implementation is just the full speed implementation with a change of data rate and a few other bodges.  



> One thing to keep in mind is that the Host only talks to one Device at a time, and it talks to the Device at its native speed. There really isn't any support for a Host to talk to, e.g., a USB-MIDI Device at any speed other than Full Speed. The Host can't talk to the hub any faster than it could talk to the Device without the hub.

Sorry but that's not quite true.  If you have a good hub with a well buffered Transaction Translator per port AND a MIDI driver that supports higher rates then you can talk to many devices each at Full Speed.  Each device of course still communicates with the hub at Full Speed, they can't do anything else of course, but the Host sees data arrive from the hub at High Speed.  My driver has been tested using 16 devices all set up to continuously transmit messages at full speed without falling over or losing messages.  That's obviously far in excess of what one is ever going to see in real operation, but gives me confidence nobody will ever lose messages in real operation provided they use an approved hub.



> Other endpoint types like Isochronous literally have to be handled in real time - there's no way to run them faster between Host and Hub than they run from Hub to Device.

That's correct.  No way of speeding these up until devices support High Speed.  I really think MIDI 2.0 should have enforced or at least recommended High Speed was supported, but it didn't.  Presumably too many people still using old processors rather than moving to the STM32F73x or NXP equivalent.



> My most recent project was to write USB Host firmware without an operating system of any kind. It was somewhat annoying because even after the Host was talking directly to the Device successfully, a lot more code had to be added to support a Hub between the Host and Device. That's because most or all Hubs are completely under control of the Host, and cannot handle anything on their own beyond the basic hardware switching and isolation. But this is a new topic for me, and there might be a few details that I missed for USB 3 Hosts. In my case, the chip only supports USB 2.0 so any newer features are irrelevant for compatibility reasons.

It's not that you need the hub for USB 3, which would be pointless, just that decent USB3 hubs, usually using the VL8xx series chips, have a Transaction Translator per port, and so these are the highest performance hubs you're going to meet operating in USB2.