RTP-MIDI Clock Accuracy?

Design Concepts
1

I’ve been thinking recently about some clock drift concerns I’ve had with sending a MIDI clock. My sammichSID has always been a bit drifty with the clock but even my Virus Classic lately can get a bit out of sync on long arpeggiations. This was with both the GM5x5x5 and my firewire-based Saffire Pro40. In fact I think the GM5 may handle it a bit better despite being over USB.

Since RTP-MIDI uses Ethernet, it made me wonder how things would be different from a timing perspective? USB requires polling if I remember right and that could cause drift on a non-realtime OS right? I’m less sure how an ethernet/IP solution would differ here from that standpoint?

The other option I was pondering was a clockbox for the clock master and set my DAW as a slave of that, but I haven’t tested that yet. As I recall the last time I tried that I had some trouble figuring out how to get synths to respond to note data from my DAW and clock data from another source (I don’t think I can even do that with a GM5?)

Any experiences to share given the above?

2

Re-read through the big RTPMIDI thread and it seems like clock issues are much better over ethernet. Doesn’t surprise me too much given it’s faster than USB and sits closer to the chip. I’m still not sure about polling, but I’d imagine that too is considerably better.

Has anyone build an RTPMIDI + MidiBox MIDI I/O interface that could share some thoughts on clock drift? I was looking at the iConnect series of controllers as well if I wanted to avoid building (and it looks like it might have the added bonus of being able to chain my GM5x5x5 to it?).

A hardware clockbox is also what I think I’m after, but if RTPMIDI is able to compensate enough, it might not be needed. Most of the time my Virus Classic is well behaved (not always), but my sammichSID really gets kinda mad about what appears to be drift. Occasionally it’ll drop notes too. I plan on adding more hardware soon, so I expect my problem to get worse, not better.