[sdiy] Techniques for Multiplying MIDI Clock frequency?

[Brian Willoughby]

On Dec 24, 2021, at 09:42, Mike Bryant <mbryant at futurehorizons.com> wrote:
>> 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

I suspect that USB-MIDI 1.0 will be with us for a while. It's a *huge* market.

>> 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 was referring only to hardware manufacturers, not software developers.

In that era, all software was Mac-only or Windows-only. You basically picked the platform and developed software exclusively for that platform. Cross-platform successes were incredibly rare.

In the hardware world - especially USB - companies basically always targeted both Windows and Mac. I can count on one hand the number of companies that designed hardware only for Mac when using an interface that was available for both Mac and Windows. Few companies could afford to ignore the potential sales to Windows users who could just plug in their hardware.

>> 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

Thanks. I never noticed the Transfer Bulk endpoint option before.

Given that Windows doesn't support non-Jack MIDI Entities, and literally refuses to recognize and connect with a USB-MIDI Device that even mentions a non-Jack Entity in its Descriptors, my gut instinct is that Windows does not support Transfer Bulk endpoints, either. But I am a bit cynical.

Are you aware of any USB-MIDI Device product that implements Transfer Bulk endpoints?

If so, which operating system releases actually support this?

... and which MIDI software supports the feature?

>> 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.

I can believe it. One of the nice things about USB is that it is neatly compartmentalized into separate layers. Even though Low Speed is "supposed" to be a separate thing, it's probably true that the OS drivers would have to go out of their way to enforce this. In other words, it might be easier to just ignore the restrictions and allow the independent layers to work together.

>> 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.

I imagine that this would have to increase the latency, because the entire packet would have to be received by the Hub before it could be re-transmitted at the higher speed.

I have a hunch that this wouldn't work for Isochronous, but I can see how it might work quite easily with Bulk.

>> 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.

There are *a ton* of USB-capable chips out there, and the price range goes well below what an STM costs. One of the design goals of USB was to make *cheap* possible. i.e. the larger your manufacturing quantity - think: millions of units - the more sensitive the CPU cost becomes.

Plus, if you make something require USB 3.0 then the hardware won't work on old computers. That can sometimes be a sizable market - difficult to ignore.

>> 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.

I need to learn about the Transaction Translator.

Thanks,

Brian