[sdiy] Techniques for Multiplying MIDI Clock frequency?

[Richie Burnett]

Interesting discussions about USB MIDI. Something I've been wondering about trying to implement for some time now.

Merry Christmas and happy holidays to all...

-Richie, 



---- Matthew Skala via Synth-diy wrote ----

>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.
>_______________________________________________
>Synth-diy mailing list
>Synth-diy at synth-diy.org
>http://synth-diy.org/mailman/listinfo/synth-diy
>Selling or trading? Use marketplace at synth-diy.org