Re: [seq24-users] timing

[Florian S. <mis...@gm...>]

On Monday 11 September 2006 00:44, Ben Saylor wrote:
> Here's an update on my progress with improving seq24's timing on my
> system, in case it someone might find it useful or have any additional
> insights.
>
> The following page has some useful information on priorities and other
> things relating to MIDI timing and audio:
> http://tapas.affenbande.org/?page_id=40
>
> I increased seq24's realtime priority above Jack's by setting Jack's
> priority to 80 and changing line 1009 in perform.cpp from
> 	schp->sched_priority = 1;
> to
> 	schp->sched_priority = 85;

actually there's two places in seq24 where you can make this change. i don't 
know which one of the two is really relevant though. One is around line 1005 
in my version [which might be old - upgrading to 0.8.7 now] and the other is 
around line 1565 [hmm the latter seems to be for input. oh well, might not 
hurt].

> and starting seq24 with the --priority flag (BTW, it would be nice
> if --priority accepted an integer argument for the desired priority;
> that's what I expected to happen at first but found that it was hard
> coded).
>
> I increased the priority and frequency of the RTC (this is what seq24
> uses for timing, right?):
> 	chrt -f -p 98 `pidof "IRQ 8"`
> 	echo 8192 > /proc/sys/dev/rtc/max-user-freq

seq24 doen't use rtc for timing. It uses sleep() variants. So increasing the 
timer frequency of the kernel to 1000hz [from the default 250hz] should have 
more of an effect.

> This seems to have improved MIDI timing.  However, when CPU load is
> somewhat high (~50% in my test setup), switching desktops, launching
> non-realtime applications, and especially moving windows can cause huge
> timing glitches.  The sequence seems to pause and then catch up when I
> stop dragging the window.  While this is happening, the audio continues
> to play, and while enough window-dragging will cause audio dropouts,
> the MIDI timing seems to go bad first, even though I've given seq24 and
> RTC higher priorities than the audio apps.  I don't understand this,
> and I don't understand why the timing should be affected so badly by
> CPU activity caused by non-realtime processes, when all of the audio
> and MIDI stuff has realtime priority.  Here's the output of top, sorted
> by priority:
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
>     9 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
> 2342 root      RT   0 10464  10m 1976 S  0.0  1.3   0:00.38 das_watchdog
>   236 root     -99  -5     0    0    0 S  0.0  0.0   0:00.00 IRQ 8
>  5815 me       -91   0 35736  34m 2584 S  0.0  4.6   0:00.00 jackd
>  5856 me       -86   5 39068  11m 9952 S  0.1  1.6   0:05.58 seq24
>  5816 me       -81   0 35736  34m 2584 S  0.8  4.6   0:12.37 jackd
>  5817 me       -80   0 29500  27m  16m S  0.0  3.7   0:04.44 qjackctl
>  5823 me       -80   5 51372  49m 7464 S 18.3  6.5   4:11.51 zynaddsubfx
>  5828 me       -80   5 61484  59m  26m S  1.4  7.8   0:22.76 hydrogen
>
> Then down below, there's another seq24 thread at priority -2.

Well, seq24 isn't the only part in this puzzle. zynaddsubfx might have 
troubles, too.

I did some tests though with seq24-0.8.7 [with raised priorities to 95 and 94] 
and my ughsynth [which is available on above page, too] vs. my midi_timer 
test programs [available on above page, too. one doing itming per rtc and the 
other sleep based] and ughsynth. ughsynth prints out the time difference in 
jack frames from one midi event to the next. So one can see from the numbers 
how regular the produced sound is. I add some typical output for all 
combinations:

-- midi_timer_rtc vs. ughsynth:

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

This is a very good jitter number. Keep in mind that i compiled seq24 0.8.7 or 
something else in the background during all these tests [1 frame at 48khz is 
about 0.2ms].

-- midi_timer_sleep vs. ughsynth:

diff: 6027
diff: 5972
diff: 6014
diff: 6021
diff: 6019
diff: 6020
diff: 6032
diff: 5972
diff: 6022
diff: 6018
diff: 6013
diff: 6022

a little more jittery, but still acceptable [50 frames at 48khz = ca. 1ms]. 

-- seq24 --priority [0.8.7 with altered prios [95 and 94]] vs. ughsynth:

diff: 6182
diff: 2
diff: 5798
diff: 5992
diff: 6185
diff: 5801
diff: 5988
diff: 6186
diff: 5990
diff: 6187
diff: 5797
diff: 2
diff: 1

looks a bit funky. There's around 300 frames [at 48khz samplingrate that's 
about 6ms] jitter. Plus there's these weird 1 or 2 frame differences [which 
would account for 6000 frames jitter ;)]. Something fishy's going on with 
seq24 these days..

Just for completeness sake, here's some numbers for rosegarden 4.1.2.4

diff: 6000
diff: 6140
diff: 5863
diff: 5999
diff: 6056
diff: 6144
diff: 5802
diff: 5999
diff: 6114
diff: 5888
diff: 6000
diff: 6033
diff: 6146
diff: 5822

which seems to be about in the same league as seq24 [200 frames = 4 ms 
jitter]. The sequencer timer was set to system timer which basically means it 
is sleep based. I didn't bother to setup rosegarden to use rtc which might 
possibly provide better results.

But these sporadic 1 or 2 frame differences between consecutive midi events 
from seq24 is very weird.

Flo

-- 
Palimm Palimm!
http://tapas.affenbande.org