USB Midi timing in the real world
Posted: Tue Jan 27, 2009 6:08 pm
I posted this in a thread on GS regarding how USB midi timing behaves in the real world (meaning including the DAW software) and thought it may be of interest to people here. Basically, the discussion was about how midi timing benchmarking tools (i.e. Miditest) compare to the interface's performance inside the app. To run the tests, I used a MBHP Core module with the Midibenchmark software on a microchip PIC18F542 8 bit micro controller which is pretty decent platform for this sort of testing with a very small latency (20 nS) when looped back to itself. The uC sends a constant stream of midi messages out of the midi out and times how much time it takes for them to come back. For the actual tests, I would route the midi in to the midi out in the software so the result will be the sum of the overhead of the program + the performance of the interface itself.
About the Core Module/Midibenchmark (from the readme):
A MIDI controller event will be sent and should be received "immediately"
is measured with timer3, prescaler 1:8 - this means, that the counter
result has to be multiplied by 8 and 100 nS (@40 MHz) to get the
absolute delay
Note that the delay is always greater than 960 uS, since this is the
initial transfer time of a controller event
The current, minimal and maximum result will be print on LCD
To determine the jitter, calculate: (max-min) / 2
Hardware setup is same cables, same USB port. Software is Midiox, Cubase SX, and Sonar 8.0.2 trial I Dl'd as an alternate package. The Core RAW test is a simple loopback into the Core Module and shows the latency of uC (20 nS) + the length of the midi msg being sent (960 nS)
My machine: Q6600 on Gigabyte GA965-DS3 Rev 1, 3 gigs Corsair TWINX LL ram, Vista32
Pic of the setup:

Results:

The midex had the most options for testing so I ran all possible configurations (TS= Timestamp on, DS= Directsound) as well as one channel as the midi loop with the remaining 7 channels outputting a constant stream of 16th notes at the same time from 7 midi tracks.
If anyone can give me a reason why it is so bad on Sonar and how to fix it i'll re run the tests
About the Core Module/Midibenchmark (from the readme):
A MIDI controller event will be sent and should be received "immediately"
is measured with timer3, prescaler 1:8 - this means, that the counter
result has to be multiplied by 8 and 100 nS (@40 MHz) to get the
absolute delay
Note that the delay is always greater than 960 uS, since this is the
initial transfer time of a controller event
The current, minimal and maximum result will be print on LCD
To determine the jitter, calculate: (max-min) / 2
Hardware setup is same cables, same USB port. Software is Midiox, Cubase SX, and Sonar 8.0.2 trial I Dl'd as an alternate package. The Core RAW test is a simple loopback into the Core Module and shows the latency of uC (20 nS) + the length of the midi msg being sent (960 nS)
My machine: Q6600 on Gigabyte GA965-DS3 Rev 1, 3 gigs Corsair TWINX LL ram, Vista32
Pic of the setup:
Results:

The midex had the most options for testing so I ran all possible configurations (TS= Timestamp on, DS= Directsound) as well as one channel as the midi loop with the remaining 7 channels outputting a constant stream of 16th notes at the same time from 7 midi tracks.
If anyone can give me a reason why it is so bad on Sonar and how to fix it i'll re run the tests