Ugh! - Software, Music and more…

Today i was wondering about what sequencer provides the best MIDI timing. My test system:

• Athlon XP 2600+ system with 1G of DDR RAM
• M-Audio Delta 66 soundcard on nonshared irq (IRQ handler prio: 80)
• A RTC with IRQ handler prio 95
• softirq-timer/0 prio raised to 95 (improved seq24 results somewhat)
• Linux kernel: 2.6.20-rc5-rt10 (an untainted realtime preemption kernel (full preemption))
• jackd version 0.102.20 tmpdir /dev/shm protocol 16
• A simple jack softsynth (ughsynth) that prints out the jack_frametime difference between incoming midi messages and puts some load on the system by naively integrating (no karplus strong :)) a wavefunction to produce some sound.
• Several midi sequencers:
  - Rosegarden
  - Muse
  - Seq24 (patched to raise the rt prio to 90)
  - got any others?
• A reference midi note generator based on RTC giving tight timing (see below)
• A correct RT priority setup (jackd running at prio 60, soundcard irq at 80. Midi generators running with prio 90)

The test case is producing a steady stream of 16th notes at 120 bpm. The frametime difference reported by ughsynth should be a constant 6000 frames ideally (at 48khz, this is 6000/48000 = 6/48 = 1/8 sec. At 120 bpm this is the speed of 16th).

One word about jack_midi: I have not included any jack_midi sequencers because jack_midi is inherently sample accurate as long as you route midi from jack_midi apps to jack_midi apps only. If you plan to route jack_midi to the outside world or to insert midi events from the outside into the jack_midi graph, then the bridge clients doing the transfer need to take care of timing/timestamping, etc..

The Results (representable excerpts of the ughsynth frame time difference output):

The reference timer (RTC):

diff: 6000
diff: 6000
diff: 6001
diff: 6000
diff: 6000
diff: 6000
diff: 6001
diff: 6000
diff: 6000
diff: 6001
diff: 6000
diff: 6000
diff: 6000
diff: 6000
diff: 6001
diff: 6000
diff: 6000
diff: 6001
diff: 6000

What we see here is rock solid timing. The 1 frametime difference isn’t really tragic and nonaudible (that’s ca. 1/48000 sec jitter).

Seq24 0.8.7 (patched to run high prio)

Seq24 is afaict sleep based and therefore using the system timer.

diff: 5999
diff: 6239
diff: 5759
diff: 5998
diff: 5999
diff: 5999
diff: 5999
diff: 5998
diff: 6239
diff: 5999
diff: 5759
diff: 5999
diff: 6047
diff: 6096
diff: 5997
diff: 5998
diff: 6239
diff: 5999
diff: 5760
diff: 5998
diff: 5999

Doesn’t look that bad either. Though there is jitter going into the 100s of jack frames. At 48khz samplerate, this is about 200/48000 = 2/480 = ca 1/1000 sec. About one ms jitter. Which is audible depending on what kind of material you play.

Rosegarden (RTC time source):

diff: 6000
diff: 6001
diff: 6000
diff: 6000
diff: 6000
diff: 6001
diff: 6000
diff: 6001
diff: 5999
diff: 6001
diff: 6000
diff: 6189
diff: 6092
diff: 6001
diff: 6000
diff: 6000
diff: 6001
diff: 6000
diff: 6001
diff: 5999

Looking good. Except for that 6189 in between. This is what happens when Rosegarden is looping and hits the end of the loop jumping to the start. So timing good, looping bad :)

Rosegarden (System Timer):

diff: 5999
diff: 5998
diff: 6000
diff: 5998
diff: 5998
diff: 5999
diff: 5999
diff: 5999
diff: 5999
diff: 5999
diff: 5998
diff: 6236
diff: 6050
diff: 5998
diff: 5999
diff: 5999
diff: 5999
diff: 5999
diff: 5999

Pretty much identical to above result. Still the loop end to loop start jump produces jitter (see the 6236 sneaked in there).

In both cases this loop-end-to-loop-start jitter becomes worse when using jack_transport (which is not surprising as relocating is a rather slow op afaict)

Muse

The Muse version (0.8.1) in Ubuntu feisty had various problems. GUI updates dog slow, etc. So i tried to build it from source (the 1.0pre1 alpha) but failed miserably..

Will try again in a while..