Re: [seq24-users] timing
Brought to you by:
rcbuse
Menu
▾
▴
Re: [seq24-users] timing
|
From: Ben S. <ben...@fa...> - 2006-09-17 20:58:33
|
On Tuesday 12 September 2006 15:10, Rob Buse wrote: > What does your seq24 console output look like when you run with --stats ? > > Rob Here are the stats with some different setups. In all of these, CPU load from RT processes is about 50%. Interestingly, I can't reproduce the large timing glitches (pauses) by loading the CPU when I run seq24 with --priority. I'm not sure what I did wrong before to cause that. Loading the CPU still causes timing glitches, but they always come with an audio xrun (less weird, but still annoying that non-RT processes can cause RT ones to glitch). Jitter is still audible, e.g. with a pattern of 32nd notes triggering a rimshot sound (I think I have always noticed this). I can hear it with Hydrogen, Zyn, and Pd. Does seq24 send timestamped MIDI events? I guess not, looking at midibus::play() (snd_seq_ev_set_direct( &ev );). If it did, and the programs receiving the events interpreted them correctly, timing could be perfect, right? Changing the RTC priority and max user frequency back to their defaults doesn't seem to change anything, so it seems Florian was right that the RTC has nothing to do with it? In any case, my seq24 timing now seems to be as good as it was before. =================================== unpatched seq24 --stats, NO --priority: Loading CPU causes big pauses in playback. Jitter is pretty bad. These stats are for when no additional CPU load was imposed. stats_avg[4942]us stats_min[4017]us stats_max[22854]us stats_avg[5049]us stats_min[4022]us stats_max[6779]us stats_avg[5017]us stats_min[4011]us stats_max[23678]us stats_avg[5090]us stats_min[4010]us stats_max[23827]us underrun stats_avg[4847]us stats_min[4013]us stats_max[6495]us stats_avg[5092]us stats_min[4013]us stats_max[26468]us stats_avg[4960]us stats_min[4015]us stats_max[20720]us stats_avg[4957]us stats_min[4012]us stats_max[6723]us underrun stats_avg[4881]us stats_min[4021]us stats_max[21296]us underrun stats_avg[5012]us stats_min[4011]us stats_max[21003]us ==================================== unpatched seq24 --stats --priority: This is much better. Loading the CPU with non-RT load doesn't cause timing glitches without accompanied audio xrun. No big pauses. stats (no additional load imposed): stats_avg[4481]us stats_min[4009]us stats_max[6071]us stats_avg[4817]us stats_min[4008]us stats_max[6222]us stats_avg[4676]us stats_min[4008]us stats_max[6207]us stats_avg[4952]us stats_min[4009]us stats_max[6225]us stats_avg[4755]us stats_min[4009]us stats_max[6149]us stats_avg[5023]us stats_min[4008]us stats_max[6152]us stats_avg[4765]us stats_min[4009]us stats_max[6235]us stats_avg[4717]us stats_min[4008]us stats_max[6188]us stats_avg[4675]us stats_min[4008]us stats_max[6102]us stats_avg[4673]us stats_min[4008]us stats_max[6191]us stats_avg[4760]us stats_min[4009]us stats_max[6323]us stats_avg[4518]us stats_min[4009]us stats_max[6090]us stats_avg[4576]us stats_min[4008]us stats_max[6063]us stats_avg[4488]us stats_min[4008]us stats_max[6119]us stats_avg[4674]us stats_min[4009]us stats_max[6079]us stats_avg[4502]us stats_min[4009]us stats_max[6010]us =================================== seq24 patched to run at priority 85, --stats --priority Same, but apparently tighter timing: stats_avg[4060]us stats_min[4009]us stats_max[4584]us stats_avg[4171]us stats_min[4008]us stats_max[4603]us stats_avg[4068]us stats_min[4009]us stats_max[4592]us stats_avg[4090]us stats_min[4008]us stats_max[4626]us stats_avg[4234]us stats_min[4008]us stats_max[4641]us stats_avg[4237]us stats_min[4008]us stats_max[4656]us stats_avg[4218]us stats_min[4008]us stats_max[4667]us stats_avg[4186]us stats_min[4008]us stats_max[4673]us stats_avg[4231]us stats_min[4008]us stats_max[4993]us stats_avg[4211]us stats_min[4008]us stats_max[4702]us stats_avg[4161]us stats_min[4008]us stats_max[4714]us stats_avg[4222]us stats_min[4009]us stats_max[4729]us stats_avg[4205]us stats_min[4008]us stats_max[4740]us stats_avg[4223]us stats_min[4009]us stats_max[4745]us stats_avg[4205]us stats_min[4008]us stats_max[4758]us stats_avg[4233]us stats_min[4008]us stats_max[4775]us > 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=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 > > > >------------------------------------------------------------------------ > >- 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 easier Download IBM WebSphere Application Server v.1.0.1 based > > on Apache Geronimo > > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=12164 > >2 _______________________________________________ > >seq24-users mailing list > >seq...@li... > >https://lists.sourceforge.net/lists/listinfo/seq24-users |
