Re: [seq24-users] timing

[Ben S. <ben...@fa...>]

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;
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

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.

On Monday 21 August 2006 08:58, Ben Saylor wrote:
> Whoops, I meant to send this to the list.  I will check on the kernel
> frequency when I get back to my computer.
>
> Rob Buse wrote:
> > Ben-
> >
> > What frequency are you running the kernel at ?  I would suggest
> > 1024Hz.
> >
> > Rob
> >
> >> Hi,
> >>
> >> For some reason Seq24's timing isn't what it used to be on my
> >> computer...  This is after a fresh install of Debian on a new hard
> >> drive, but I installed exactly the same kernel I had before. 
> >> Realtime priority is working fine with Jack.  I'm planning to do
> >> some research on this issue, but does anyone have any pointers to
> >> common causes of timing issues with ALSA MIDI or seq24 in
> >> particular?
> >>
> >> Thanks,
> >> Ben