On Mon, Aug 16, 2010 at 08:47:05AM -0700, Ryan Freeman wrote: > Excerpts from Alexandre Ratchov's message of Sun Aug 15 22:55:25 -0700 2010: > > On Sun, Aug 15, 2010 at 10:12:54PM -0700, Ryan Freeman wrote: > > > Excerpts from Ryan Freeman's message of Sat May 02 02:42:32 -0700 2009: > > > > hello ports@ > > > > > > > > attached is an updated port from my original 'random svn checkout' > > > > port, thankfully they finally released a new complete version, 1.36. > > > > > > > > builds and runs/plays great here on i386. > > > > > > > > -ryan > > > > > > bump! just thought i'd revisit this and inform that i still use this > > > port after over a year and through all snapshots, its only become > > > better. present day sees quake3 running smooth as silk on my t41p, > > > next to no sound issues (aucat -l -v 103 -b 1024 -z 512) and > > > i regularly use it to play the urban terror mod. i will reattach > > > for convenience sake, any additional comments at this time? > > > > > > > out of curiousity are you using a MP kernel? It seems that > > sound issues tend to occur mostly on MP machines. > > > > -- Alexandre > > unfortunately no my t41p just uses a good old fashioned single core > intel pentium m processor. i'm really going to have to make a point > to try and aquire an mp-capable machine to test all the ports i > have going on. But, then again, ideally i'd have one of everything > we support ;) does renice(8)ing the process of ioquake3 cause the > issue to get any better or worse on mp? I see no reason for renice(8) to solve the mp problem. AFAIU, it's related to interrupts rather than process scheduling; so changing the scheduling priority is unlikely to help.
> the only reason i ask is for playing urban terror i ended up doing > the following (granted i gave myself passwordless sudo access to > renice, as this workstation is only used by me): > > $ cat ~/bin/urbanterror > sleep 3 && sudo renice -n -5 `pgrep -x ioquake3` & > ioquake3 +set fs_game q3ut4 +com_hunkmegs 256 +com_zonemegs 64 $@ > > ^i found this to reduce issues with the mod getting fps bombs > during play every now and then, but sound is more or less never > and issue. > > where renice(8) really did seem to make a difference (but not perfect) > was my fceux port. everything 'works' video blit is fast but sound > is rather choppy. i renice that process in the same fashion and it > squashed most of the blips bloops and bleeps (well, the unintended ones, > i realize nes sound is mostly just that ;D) > > i definitely didn't see too much issue renicing those processes, as > the only people that should be using these game ports should be those > using workstation-only type setups where there are no other users to > suffer from some jerk running a dri-based game. the game port guy here > will come and strike you with a heavy object for such a thing! keep > those production boxes clean of this crap! ;D > cheers, well, renice(8) may help in some cases and hurt in other cases. It depends on the program works. Renicing a I/O bound process producing audio should slightly prevent other processes from stealing the CPU when it wakes up to produce audio data. On the other hand renicing a cpu bound process would hurt other processes in the audio chain (eg. aucat). Processes using user threads with one ``real time'' i/o bound thread and one ``low priority'' gui thread are unlikely to be much more stable if reniced. Anyway, stuttering is more likely to be fixed by improving the code (of the whole audio chain: program -> kernel -> driver). Renicing mostly hides problems in the code, but that's all we have for the mid-term. -- Alexandre
