• SONAR
  • MIDI "Jitter" - It Does Exist (p.26)
2007/10/14 02:24:39
harmony gardens
This is a very interesting thread. I haven't really considered this before. I've had instances where anomalies occured, but didn't really know what the cause was, and it doesn't always happen. I will pay closer attention from now on.

Thanks for helping to stretch the old gray matter.
2007/10/14 21:49:51
Jim Wright
OK, I did some (very informal, non-scientific) testing of 3 different MIDI interfaces I happen to own.

My DAW: AMD Athlon 939 X2 4800+, MSI Neo2 Platinum socket 939 motherboard, 2x1G of OCZ RAM, tons of disk storage, EMU 1820M, Matrox 650P video card with 2 LCDs.

The three MIDI interaces used are: Edirol UM550 (USB), EMU 1820M (PCI) and M-Audio Axiom 61 (USB, using MIDI DIN Input on back of keyboard).

The UM550 can act as a MIDI Patchbay as well as a MIDI interface. This is how my gear was connected:
1) Korg keyboard was connected to UM550 MIDI IN #1.
2) UM550 MIDI OUT #1 was patched to EMU MIDI IN #1
3) UM550 MIDI OUT #2 was patched to Axiom USB Input

Sonar (6.2.1) was set up to record each interface to a different MIDI track.
* Track 1 - was Axiom USB MIDI
* Track 2 - was UM550 MIDI IN #1
* Track 3 - was EMU PCI MIDI Input.

Sonar was set for 120 BPM, 960 ppqn.

Test procedure:
A) Enable Record on all three MIDI tracks
B) Disable echo for all tracks
C) Start recording (all three tracks simultaneously)
D) Play notes on the Korg keyboard, (a series of 18 staccato notes, of roughly quarter-note duration - I was not listening to a metronome, just playing free).

Results were as follows:

EMU PCI Both USB Delta

1:02:501 1:02:503 2
1:03:458 1:03:460 2
1:04:478 1:04:478 0
2:01:462 2:01:464 2
2:02:493 2:02:493 0
2:03:501 2:03:503 2
2:04:602 2:04:602 0
3:01:560 3:01:564 4
3:02:670 3:02:670 0
3:03:658 3:03:658 0
3:04:735 3:04:735 0
4:01:739 4:01:739 0
4:02:727 4:02:729 2
4:03:735 4:03:735 0
4:04:800 4:04:804 4
5:01:792 5:01:792 0
5:02:796 5:02:798 2
5:03:752 5:03:752 0
The two USB interfaces (UM550 and Axiom 61) had exactly the same timing for all notes. This surprised me a bit; I thought the Edirol (with 'FPT') might perform slightly better, but this was not true in my very limited test.

As you can see, 10 notes had the same timing with both PCI and USB interfaces. 6 notes were 2 ticks later with the USB interfaces. 2 notes were 4 ticks later with the USB interfaces.

Since 1 tick is about 0.5 milliseconds (@120BPM, using 960 PPQN) - the maximum jitter was about 2 milliseconds (4 ticks). Note that the deltas are even numbers (2 ticks == 1 millisecond, 4 ticks == 2 milliseconds). This is not surprising: the USB frame rate is 1 millisecond, which introduces a subtle quantizing to 1 millisecond boundaries.

To recap this very unscientific test:
  • The PCI interface seemed to have the tightest timing (but wasn't compared against any kind of absolute reference, so it's a somewhat dubious conclusion).
  • The two USB interface performed the same
  • There's no way to know how much jitter was present in the PCI interface stream. There was no reference for comparison, and the source MIDI notes were played freely, not sequenced.
  • There's no way to know the latency of any of these interfaces, from the measurements I took.
  • Both USB interfaces had a maximum jitter of about 2 milliseconds (4 ticks) - on top of whatever jitter was also present in the PCI interface MIDI.
  • USB Jitter was quantized to 1 millisecond boundaries (delta was 1 millisecond or 2 milliseconds, but never 0.5 or 1.5 milliseconds).
  • Iwas recording 3 tracks in parallel. It's possible that this could introduce some extra processing overhead (3 drivers were being tickled at the same time) that would not be present if only 1 driver was in use. In other words -- it's possible that USB jitter would be reduced a bit if only one MIDI interface was being used.
Jitter of 2 milliseconds should be fine for most music and most musicians (although 1 millisecond max jitter is what I and others recommend). If you're experiencing significantly higher MIDI jitter levels -- there's probably something wrong with your system configuration.

- Jim
2007/10/14 21:53:05
pianodano

ORIGINAL: dewdman42

Just for kicks I went to the KVR plugin developer forum and asked a few questions. This is a very interesting thread. PianoDano, pay special attention to the post from JCJR.

http://www.kvraudio.com/forum/viewtopic.php?t=194589




Thanks. I spend time there but over at the Receptor forum. Just found this post this over a musiclab. http://www.musiclab.com/community/forum/viewtopic.php?t=2130
2007/10/14 21:56:56
dewdman42
I can see where RealGuitar or other plugins might be randonmizing which samples are getting played in order to avoid machine gun effect. Using the inverted sum trick will not really tell you if the timing is off, it will only tell you if the audio is at all different.

Pianodano said it went from sounding good to sounding terrible......with the timing completely off. I can't believe that randomly using different guitar samples would cause the timing to be so screwed up. If it does, then its still a bug in RealGuitar either way. But I'm more inclined to think that they are not handling the midi timestamps in their plugin correctly.
2007/10/14 22:36:26
pianodano
ORIGINAL: Jim Wright

OK, I did some (very informal, non-scientific) testing of 3 different MIDI interfaces I happen to own.

My DAW: AMD Athlon 939 X2 4800+, MSI Neo2 Platinum socket 939 motherboard, 2x1G of OCZ RAM, tons of disk storage, EMU 1820M, Matrox 650P video card with 2 LCDs.

The three MIDI interaces used are: Edirol UM550 (USB), EMU 1820M (PCI) and M-Audio Axiom 61 (USB, using MIDI DIN Input on back of keyboard).

The UM550 can act as a MIDI Patchbay as well as a MIDI interface. This is how my gear was connected:
1) Korg keyboard was connected to UM550 MIDI IN #1.
2) UM550 MIDI OUT #1 was patched to EMU MIDI IN #1
3) UM550 MIDI OUT #2 was patched to Axiom USB Input

Sonar (6.2.1) was set up to record each interface to a different MIDI track.
* Track 1 - was Axiom USB MIDI
* Track 2 - was UM550 MIDI IN #1
* Track 3 - was EMU PCI MIDI Input.

Sonar was set for 120 BPM, 960 ppqn.

Test procedure:
A) Enable Record on all three MIDI tracks
B) Disable echo for all tracks
C) Start recording (all three tracks simultaneously)
D) Play notes on the Korg keyboard, (a series of 18 staccato notes, of roughly quarter-note duration - I was not listening to a metronome, just playing free).

Results were as follows:

EMU PCI Both USB Delta

1:02:501 1:02:503 2
1:03:458 1:03:460 2
1:04:478 1:04:478 0
2:01:462 2:01:464 2
2:02:493 2:02:493 0
2:03:501 2:03:503 2
2:04:602 2:04:602 0
3:01:560 3:01:564 4
3:02:670 3:02:670 0
3:03:658 3:03:658 0
3:04:735 3:04:735 0
4:01:739 4:01:739 0
4:02:727 4:02:729 2
4:03:735 4:03:735 0
4:04:800 4:04:804 4
5:01:792 5:01:792 0
5:02:796 5:02:798 2
5:03:752 5:03:752 0
The two USB interfaces (UM550 and Axiom 61) had exactly the same timing for all notes. This surprised me a bit; I thought the Edirol (with 'FPT') might perform slightly better, but this was not true in my very limited test.

As you can see, 10 notes had the same timing with both PCI and USB interfaces. 6 notes were 2 ticks later with the USB interfaces. 2 notes were 4 ticks later with the USB interfaces.

Since 1 tick is about 0.5 milliseconds (@120BPM, using 960 PPQN) - the maximum jitter was about 2 milliseconds (4 ticks). Note that the deltas are even numbers (2 ticks == 1 millisecond, 4 ticks == 2 milliseconds). This is not surprising: the USB frame rate is 1 millisecond, which introduces a subtle quantizing to 1 millisecond boundaries.

To recap this very unscientific test:
  • The PCI interface seemed to have the tightest timing (but wasn't compared against any kind of absolute reference, so it's a somewhat dubious conclusion).
  • The two USB interface performed the same
  • There's no way to know how much jitter was present in the PCI interface stream. There was no reference for comparison, and the source MIDI notes were played freely, not sequenced.
  • There's no way to know the latency of any of these interfaces, from the measurements I took.
  • Both USB interfaces had a maximum jitter of about 2 milliseconds (4 ticks) - on top of whatever jitter was also present in the PCI interface MIDI.
  • USB Jitter was quantized to 1 millisecond boundaries (delta was 1 millisecond or 2 milliseconds, but never 0.5 or 1.5 milliseconds).
  • Iwas recording 3 tracks in parallel. It's possible that this could introduce some extra processing overhead (3 drivers were being tickled at the same time) that would not be present if only 1 driver was in use. In other words -- it's possible that USB jitter would be reduced a bit if only one MIDI interface was being used.
Jitter of 2 milliseconds should be fine for most music and most musicians (although 1 millisecond max jitter is what I and others recommend). If you're experiencing significantly higher MIDI jitter levels -- there's probably something wrong with your system configuration.

- Jim


Jim,

I know it would be a lot to ask, but could you maybe do the same test while playing to the metronome at 960ppqn. And repeated again with about 4 or 5 audio tracks running and every midi port you've got enabled? I would love to see if your results are similar to what I see occur. I have a reasonably complex midi setup

My outboard midi setup uses a Maudio 8x8 via USB patched as follows:

Roland R-5 drum machine 1in - 1 out
Microlynx Sychronizer 2 out Syncs tape machine and DTRS machines via MTC
Tascam DA-78hr master 3in - 3 out Only used for storing menu settings and offets.
Roland MC500MKII seq 4in - 4 out
Roland Juno 106 5in - 5 out
Yamaha TX81z 6in - 6 out
Yamaha P120 piano 7in - 7 out
Yamaha DTExtreme drums 8in- 8out

Maudio 1x1 USB - Korg PA80 arranger 1-16
Korg padkontrol USB
Yamaha Tyros arranger USB1 1-16 USB2 1-16 (or 32 channesl available via both ports enabled)

Yamaha MotifXS USB 1 1-16 only used. Also used as main control surface. The mdi out of this instrument fires the 16 channels on the Receptor. So that setup is: Motif USB>Sonar track>Motif USB>Motif midi out>Receptor.

Tascam IF/FW firewire - Midi 1-16. Controls mixer TC and mixer automation - sometimes used as the control surface
FrontierTranzport via USB

Audio via the Tascam 24 i/o IF/FW via firewire on separate bus.

Sonar 6.2.1

Computer - All services disabled that I can. Dedicated music only.

ASUS P4 3.2ghz. 2gig ram, hyperthreading. Regardless what is said, mine runs Sonar much better with HT enabled.

I just read somewhere that it is recommended (by someone) that ports not used should be disabled. I hope that's not for real. That's a new one on me. I have be totally frustrated for years about the way sonar reorders ports when one on the list is not found. You can imagine how time comsuming it is getting all the ports listed in the correct order if Sonar reoders them.

I had planned to get another Maudio 8x8 for a few more of the keyboards at hand, but I have held off because of the timing problems (be it latency, jitter, me, whatever, I have run into that's bogging me down.

Thanks

Danny
2007/10/14 22:47:24
pianodano

ORIGINAL: dewdman42

I can see where RealGuitar or other plugins might be randonmizing which samples are getting played in order to avoid machine gun effect. Using the inverted sum trick will not really tell you if the timing is off, it will only tell you if the audio is at all different.

Pianodano said it went from sounding good to sounding terrible......with the timing completely off. I can't believe that randomly using different guitar samples would cause the timing to be so screwed up. If it does, then its still a bug in RealGuitar either way. But I'm more inclined to think that they are not handling the midi timestamps in their plugin correctly.



Did I say terrible ? I don't know if anything could make Realguitar sound terrible. I guess what I was trying to say is I can spend several hours tweaking a part to sound so good (to my ears). Freeze it and it can play ok for a few measures and suddenly for no apparent reason, start stuttering ever so slightly. After working on the part for so long, you would have heard the part so many times you know every nuance and easily recognize when something is amiss. It never seems to regain the timing again once the rendered tracked gets fouled up. As I said yesterday, I quit trying here and just put it on tape now. It's one of those time is of the essence things if you know what I mean.

Danny
2007/10/14 22:51:19
brundlefly
Using the inverted sum trick will not really tell you if the timing is off, it will only tell you if the audio is at all different.


If you know that the waveforms in the two tracks are identical (or should be with a non-randomizing synth given a stream if identical MIDI events), then an cancellation errors the can't be cured by balancing amplitudes are due to timing.
2007/10/14 22:54:23
dewdman42
Yes, if you know the samples are supposed to be exactly the same. However how many synths do you konw that would garantee that each time the produced audio output would ge exactly the same? Probably none. And we've already established that RealGuitar is using some alternating sample tricks to avoid machine gun effect. Therefore, you can only take that test with a grain of salt unless you know for sure you are dealing with fixed samples. And that includes...if you route samples through effects than you can't even completely garantee that the output would be identical.
2007/10/14 22:59:49
dstrenz
Jim, Thanks for the quote from 'earthvegaconnection'. So that's what (emulated) means in DXDIAG. All of my midi ports are emulated, so none actually have DirectMusic drivers. I wonder if any sequencer actually uses DirectMusic midi timestamps anyhow...

dewdman, thanks, and I like the new avatar. The old one looked kindof like a shady character. I'm still an old geezer.

Jim, your tests show just about the same results as mine for the 1820m midi ports, so I guess I did nothing wrong. Next test for me will be to repeat the test on a medium size project that contains midi, soft synts, and audio to see if the results are the similar.
2007/10/14 23:00:29
pianodano
ORIGINAL: dewdman42

Yes, if you know the samples are supposed to be exactly the same. However how many synths do you konw that would garantee that each time the produced audio output would ge exactly the same? Probably none. And we've already established that RealGuitar is using some alternating sample tricks to avoid machine gun effect. Therefore, you can only take that test with a grain of salt unless you know for sure you are dealing with fixed samples. And that includes...if you route samples through effects than you can't even completely garantee that the output would be identical.


So what you're saying is there could be minute timing inaccuracies in the samples themslves ?? Then what in your estimation would call up different samples except velocity and therefore unless the velocity changes, why would they played different ? Hope that makes sense.
© 2026 APG vNext Commercial Version 5.1

Use My Existing Forum Account

Use My Social Media Account