Re: [seq24-users] timing

[Rob B. <rc...@fi...>]

What does your seq24 console output look like when you run with --stats ?

Rob

On 9/10/2006, "Ben Saylor" <ben...@fa...> 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=3D40
>
>I increased seq24's realtime priority above Jack's by setting Jack's
>priority to 80 and changing line 1009 in perform.cpp from
>=09schp->sched_priority =3D 1;
>to
>=09schp->sched_priority =3D 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?):
>=09chrt -f -p 98 `pidof "IRQ 8"`
>=09echo 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
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easie=
r
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D12=
1642
>_______________________________________________
>seq24-users mailing list
>seq...@li...
>https://lists.sourceforge.net/lists/listinfo/seq24-users