[sdiy] Techniques for Multiplying MIDI Clock frequency?

[mskala at northcoastsynthesis.com]

On Thu, 23 Dec 2021, Brian Willoughby wrote:
> On Dec 23, 2021, at 19:06, mskala at northcoastsynthesis.com wrote:
> > I've seen over 40 poll/NAK sequences per frame (maybe over 70; both
> > numbers are in my memory but I'm not sure the faster one was actually with

> What operating system was serving as the USB Host?

That was my own PIC24 host code, with no operating system as such.  The
device on the other end of the connection was an Akai "MPK mini" USB-MIDI
keyboard.

> My USB-MIDI Device firmware experience is with the PIC18 8-bit MCU with
> a 48 MHz clock.

Probably very similar hardware to what I'm working on, then; I think
Microschip uses basically the same IP block for the USB peripheral on
PIC18 and PIC24.

> I believe that USB allows multiple 64-byte Bulk packets per USB frame.

Yes, and I've seen that working in practice, although many devices will
return a whole lot of NAKs between successful packet transfers, with the
speed of actual data traffic they can support being much less than a
maxed-out bus could carry.  Flash memory sticks in particular seem to be
quite bursty - they may return a few packets at maximum bus speed, then
just NAK for a few milliseconds before waking up again.

> My goal for supporting a Hub was to provide cheap isolation (I'd rather
> burn out a $4.99 Hub than my custom USB hardware), and also to allow for
> some way to save and restore custom settings on a USB memory stick
> without literally removing the controller Device from the Host USB jack.

Interesting point about the isolation.  That's a possible advantage of
using a hub, that I hadn't thought of.

> Given their prevalence, it seems like a very useful feature to be able
> to Host USB-MIDI controllers.

I hope so!  It's also a hole in my product line - up to now I've been
having to tell customers "Well, you'll need to get a controller or
interface from someone else to play this module."

> documentation teams for the hardware versus the firmware, so there
> should be enough documentation for you to provide all of the firmware
> ... I just wouldn't recommend working that hard.

Already done, so that's no longer a big question for me.

> I wasn't convinced that I *needed* to support a Hub, but I wanted to see
> how hard it would be. So, I allocated a finite amount of time to

Seems like a sensible approach.

> I think it would be fair for you to say that your product supports a
> Hub, but only with Devices attached that are already supported without
> the Hub. I guess that could be a problem if you support a mouse and/or
> keyboard, because then that support would go away with a Hub.

I do have support for mouse and (typing) keyboard, so the limitation would
have to be a little more complicated.  But it may be something to look at
for some future firmware version.

> sampling rate is 125 kHz, and that works out to only a 976.5625 Hz
> packet rate. Although the Host USB clock is not locked to the Device
> sample rate, it's still true that the Host wants about 1,000 packets per
> second. This means that 1 out of every 42+2/3 frames has a 0-byte
> Isochronous packet instead of a 384-byte packet. Everything still
> manages to work out, because USB was designed for this.

Almost like NTSC frame drop.

> p.s. To get back to the subject... any of these 8-bit or 16-bit or
> 32-bit processors should be able to handle incoming MIDI clock, lock in
> a Timer channel, and multiply the frequency for rock-solid output
> timing. Because the TM4C129x has 8 full UART peripherals, I've been
> tempted for several years to design an 8-input, 8-output MIDI merger
> than properly handles MIDI clock between everything (although that could
> be a mess if you don't have a way to turn off conflicting clocks).

It would probably call for some kind of out-of-band control to specify
which clocks to trust and which not to.

-- 
Matthew Skala
North Coast Synthesis Ltd.