[sdiy] Techniques for Multiplying MIDI Clock frequency?

Brian Willoughby brianw at audiobanshee.com
Fri Dec 24 03:19:42 CET 2021



On Dec 23, 2021, at 16:33, Mike Bryant <mbryant at futurehorizons.com> wrote:
> Even with the latest spec, the MIDI Association go out of their way not to specify the USB speed required even in Version 2.0 of the USB Device Class Definition for MIDI devices, but I don't think you could implement most of the features of MIDI 2.0 without USB2.0 or Ethernet.

Part of not specifying the speed is that they've already defined Low Speed to not allow Bulk endpoints, and they defined USB-MIDI to require Bulk endpoints.

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

Also, you might be surprised by the number of operating systems with default USB-MIDI drivers that simply won't acknowledge a High Speed device as USB-MIDI.

For decades, Windows would not recognize a USB-MIDI Device with non-port Entities. Thus, all USB-MIDI devices with built-in Entities like a control surface "lie" about their capabilities and report the non-port features as if they were Embedded MIDI Jacks. I know this because I implemented a Device according to the USB-MIDI Spec that Mac OS X would recognize fully, but Windows would not. Microsoft wanted to support this, but they wanted to test it first, and they couldn't find any commercial devices that implemented that part of the USB-MIDI spec. That's because nobody could successfully release a commercial device with those features because it would mean that the product is not supported on Windows. In those days, nobody could afford to be Mac-only.

In other words, the situation involves more than just USB specifications - it also involves Host support.

> The 1999 spec was written assuming most people were going to multiplex DIN MIDI channels onto a USB link, but I think we've moved on from that nowadays and the high bandwidth mechanism is regularly used.

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.

My first USB-MIDI firmware supported at least three Bulk packets per USB frame, meaning it was roughly three times the speed of Classic MIDI. This was without optimizing the firmware in any way (it probably could have been more efficient), and certainly without changing the Mac OS X driver for USB-MIDI.

If there's a distinct "high bandwidth" mode, then I'd certainly like to learn more about it.


> A lot of kit doesn't even come with a DIN socket on it nowadays, something I've heard Rick Wakeman ranting about :-)
> 
> I've never seen anything official saying MIDI 1.0 isn't allowed over low speed USB.  Low speed USB often implements a superset of the basic spec, including extra endpoints, and so it actually often works with a single device.  But the latency is high.

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

One thing to keep in mind is that USB has several independent layers so that the generic parts can be handled by the same code. On the firmware side, some of the USB protocol is handled in hardware (different amounts for different processor designs), and some is handled in generic firmware source. Only the smallest amount of code is specific to USB-MIDI. Likewise, on the Host, an operating system will handle all USB Devices with a certain amount of generic code, and only when the Descriptors are read is the handling turned over to a specific driver like USB-MIDI.

In other words, it's highly likely that every modern operating system simply will not function with a Low Speed USB-MIDI Device, simply because the Device would be disqualified long before the USB-MIDI driver can get involved.

> My reference to USB2.0 was about using hubs to allow lots of MIDI devices to be connected.  Ideally you need a hub with a Transaction Translator per port which retimes the MIDI data onto the USB2.0 stream.  The MIDI data obviously won't be any faster than when it left the USB MIDI device, but this allows the streams to be multiplexed more efficiently so you don't have any added latency unless you are multiplexing a pretty large number of active ports.

This much is true. A good hub runs as fast as possible, except when handling the transaction with Full Speed or Low Speed Devices. The Translator could allow things to happen on multiple ports at the same time.

> But cheaper hubs actually slow down to the speed of the inputs and multiplexing lots of devices becomes a bad move.  Easiest way to avoid this problem is to buy a USB3.0 hub as they always seem to do things on a per port basis.

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.

I haven't looked at the details, but it's theoretically possible that a hub with Transaction Translation could handle Interrupt endpoints without the Host and then deliver that data faster at a later time, but I've not seen any evidence of this. 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.

Also keep in mind that Full Speed Devices literally cannot communicate any faster than Full Speed, but you probably didn't say otherwise.

> I tend to use a bare metal USB stack for Raspberry Pi CM4s as it handles pluging/unplugging of multiple devices well, something many stacks seem to fall over on, or at least ignore any device once it has been unplugged.

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.

Brian





More information about the Synth-diy mailing list