CPU Usage

[Ian @ un4seen]

I'm fully aware of the fact that the Task Manager has a shittier resolution and update time (if you don't fix it that is, you can choose the speed somewhat at least), so this is why I compared with the "CPU Time" counter reported, which I believe is somewhat more correct?

I would think that "CPU Time" is simply a sum of the snapshots - if the snapshots are inaccurate, "CPU Time" would be too.

I get stutters in the sound even when rendering a scene in for instance 3dsmax or Maya, or encoding an MP3 with Lame using the "higher" thread priority, things that never happened with Winamp.

Increasing XMPlay's buffer length should sort that. (for reference: Winamp's default is 2 seconds)

So, if now Windows reports all this erroneously, what did you do that everyone else always fails to do with their programs to not report a correct usage to Task Manager and perfmon? :
I'm sort of stumped....

I'm not sure why it can give inaccurate CPU readings, but I suspect it's to do with time resolution - Win9x default resolution is 1ms, whereas NT's is 10ms. Maybe that would particularly affect the readings of an app that is doing processing at frequent intervals (eg. a multimedia player).

Anyway, the results I've seen (like the example mentioned in that thread), make me distrust Task Manager CPU readings... even just the way the values bounce up and down suggests that it's a bit hit'n'miss

[Ralesk]

<Tso> I get stutters in the sound even when rendering a scene in for instance 3dsmax or Maya, or encoding an MP3 with Lame using the "higher" thread priority, things that never happened with Winamp.

<Ian> Increasing XMPlay's buffer length should sort that. (for reference: Winamp's default is 2 seconds)

Well, the only thing that changes for me, is that the effects get applied way later.  I myself still get stutters when something eats even just a few extra % of cpu (CD to HDD copies are a bitch here)

[Torkell]

Thanks for caring I tested with perfmon, and I could see the same thing, though it of course shows the decimals, in the case of Winamp. I'm fully aware of the fact that the Task Manager has a shittier resolution and update time (if you don't fix it that is, you can choose the speed somewhat at least), so this is why I compared with the "CPU Time" counter reported, which I believe is somewhat more correct?
I get stutters in the sound even when rendering a scene in for instance 3dsmax or Maya, or encoding an MP3 with Lame using the "higher" thread priority, things that never happened with Winamp.

I tend to get a bad case of the stutters when I'm unzipping a zip file with WinZip, but come to think of it that's stopped since I stuck in a spare SB PCI128. Hmm... *aims BFG 10k in general direction of VIA HQ*

Quake3 + XMPlay was totally unplayable on a P3 700 w/Sound Blaster PCI128 (I know, it's not my computer and a GF2MX. Q3 + Winamp is fine. Doesn't matter which output stuff I use in the player.

As I said, the only thing I can think of is that XMPlay and Quake 3 Arena are conflicting over use of the hardware. Try setting Quake to use a different sound system if possible (i.e. not DirectX)?
Ian, can you tells us just what XMPlay plays the sound through (DirectX/WinAPI) and what settings it opens the channel with (Exclusive/Co-op)? I'm guessing co-op as I can have two copies playing at the same time with no problems.

So, if now Windows reports all this erroneously, what did you do that everyone else always fails to do with their programs to not report a correct usage to Task Manager and perfmon? :
I'm sort of stumped....

Erm... you can't report an incorrect usage to Task Manager. Task Manager is not asking the programs how much CPU they are using, it's asking windows and using the same API calls as other performance monitors (including the one hidden in the MMC). BUT it is only reporting an average, as it would be unfeasible to have instant updates (would use up too many clock cycles). I've seen the same jump pattern on my PC sometimes, and I think that's just down to the update speed (only every 500ms on high).
There are other things to look at here. What thread priority is XMPlay using for its playing thread. It could be that the reason WinAmp doesn't stutter is its playback thread has an above-normal priprity, so it doesn't lose clock cycles. Any ideas, Ian?

[Ralesk]

<Bog> What thread priority is XMPlay using for its playing thread.

Last I heard playing used normal, displaying used low.  Starting the program as high priority changes the "glitches": xmplay seemed to be a bit less likely to drop in the middle of a song, but more likely to crack one right after starting to play.

xmplay.exe -iamhighonw33d

should make it start on high  (Was req'ed by me, actually )

[Ian @ un4seen]

<Tso> I get stutters in the sound even when rendering a scene in for instance 3dsmax or Maya, or encoding an MP3 with Lame using the "higher" thread priority, things that never happened with Winamp.

<Ian> Increasing XMPlay's buffer length should sort that. (for reference: Winamp's default is 2 seconds)

Well, the only thing that changes for me, is that the effects get applied way later.  I myself still get stutters when something eats even just a few extra % of cpu (CD to HDD copies are a bitch here)

Increasing the buffer length will only help if the break is caused by XMPlay not being able to update the buffer quickly enough (ie. not getting enough CPU), which sounds like what's happening in Tsorovan's case. If increasing the buffer length doesn't help at all, then I suspect the problem could be hardware/driver related.

Ian, can you tells us just what XMPlay plays the sound through (DirectX/WinAPI) and what settings it opens the channel with (Exclusive/Co-op)? I'm guessing co-op as I can have two copies playing at the same time with no problems.

XMPlay uses the Windows Multimedia drivers (waveOut). There's no "co-op" mode in the API, but most soundcards/drivers can play multiple channels, which allows multiple apps to use the device at the same time.

There are other things to look at here. What thread priority is XMPlay using for its playing thread. It could be that the reason WinAmp doesn't stutter is its playback thread has an above-normal priprity, so it doesn't lose clock cycles. Any ideas, Ian?

The mixing thread is at the highest priority (time critical), the rest runs at normal priority.

[Torkell]

Well, I dug out my copy of Quake 3 Arena and played it for about an hour just now, with XMPlay running and visible on my other monitor (If you don't have a multi-monitor setup then you don't know what you're missing).

Most of the time it ran fine, responding to global hotkeys and playing with no stuttering. Ocassionally, XMPlay would drop out completly for a few seconds, but only when I was looking back through the logs at what the bots said after the match(my all-time favourite is when one said "I respect a shot like that BoggyB" just after I railed the thing ).

I put that down to XMPlay not being able to get enough CPU. When actually playing the only noticeable defect was the display not updating properly, but what do you expect with Quake at the same time?

My system is:

• Windows 2000 Professional Build 2195 Service Pack 3
• 3D Prophet KYRO 4500
• SoundBlaster PCI128
• AMD Duron 800
• VIA-based motherboard
• A whole load of things running at the same time (i.e. mail, web and ftp servers - this is a development machine)

XMPlay (v2.5) settings:

• 96000Hz 16bit with 1s buffer
• Auto-amp, sensitive clipping, spline interpolation
• Equalizer on some songs
• MP3 and Ogg plugins loaded
• *NO* vis running (that *would* kill it)
• SilverXP GUI *visible*
• OGG-format songs in playlist (128kbps)

Thanks Ian for that thread info. If the playback thread's priority level is critical, there should be no problems with playing it. Was this in all versions, or just recently (note to Tsorovan: have you got the latest version of XMPlay)?

Tsorovan: have you checked your DirectX install (use dxdiag)? That might be causing a problem.

[Tsorovan]

DirectX install is OK. This even happened on a fresh install of WinXP, and as it all happens on 3 different OS:es (albeit with more or less the same kernel) I'm confident to say it's ruled out.

As I said, the only thing I can think of is that XMPlay and Quake 3 Arena are conflicting over use of the hardware. Try setting Quake to use a different sound system if possible (i.e. not DirectX)?
Ian, can you tells us just what XMPlay plays the sound through (DirectX/WinAPI) and what settings it opens the channel with (Exclusive/Co-op)? I'm guessing co-op as I can have two copies playing at the same time with no problems.

Tried. Also, I guess I forgot to mention it clearly, but Q3A stutters even more than XMPlay, and not only sound. Reported FPS is okay, but gameplay is totally hackish. Same thing with UT1. Buffer settings doesn't do -- pardon the french -- shit.

Oh and yeah, this is with v2.5.

I'll try to find some kind of serious profiling software and run some tests...will report my findings.

[Torkell]

Played Quake 3 Arena again for an hour or so yesterday, with XMPlay running and playing a mixture of OGGs, MP3s and various format MODs (I had a few MO3s in there as well). It droped out ocassionally, but only at the match-end screen in single-player. This one's got me stumped.

:idea:: have you got the latest patch for Quake? I think I'm running 1.7, but I'll have to go and look.

Something else: You know I said that XMPlay had stopped stuttering? I was wrong. Managed to do it while copying some files. Same machine as in previous posts, copying from Direct-CD enabled CD-RW in a DVD-ROM drive to a NTFS drive, XMPlay stuttered like mad on MODs, only did it a little with MP3s, and hardly stuttered with OGGs. My CPU usage went through the roof when I was doing that, and it wasn't streaming of the CD, but the light was flikering int time to the stuttering. Maybe it's to do with something on a hardware level? Anyone manage to reproduce this?

[Ralesk]

Same with me, BoggyB...  I think the problem is in the OS

[Pike84]

Woohoo! I will have to worry about this even less than I already did, cause I'll soon be a happy owner of a 2.4Ghz P4

[Tsorovan]

Just a thought BoggyB...do you by any happenstance have vsync on or com_maxfps set to something other than 0?

I'm one of those fps nuts and I have ~300-350 fps when running around and I might think these CPU "spikes" lowers the fps pretty much hence the stuttering, but I'm not sure and I can't test right now as I'm not at home. I will report my findings with the fps limited (though I still say there's something else wrong as NO other player app does this -- but at least I would get an explanation for these symptoms).

[Tsorovan]

I'm using 1.27g I think. Not that I think it's Q3A's fault, but I've said that a lot of times now :)

[Torkell]

Just a thought BoggyB...do you by any happenstance have vsync on or com_maxfps set to something other than 0?

Never heard of it. Will check and report back.

I'm one of those fps nuts and I have ~300-350 fps when running around and I might think these CPU "spikes" lowers the fps pretty much hence the stuttering, but I'm not sure and I can't test right now as I'm not at home. I will report my findings with the fps limited (though I still say there's something else wrong as NO other player app does this -- but at least I would get an explanation for these symptoms).

Er... 300+ fps might just be a *little* OOT. 30 fps is enough to give you a good game, especially if going down to 30 fps means you can run it at something insane like 1280x1024x32. If com_maxfps does what I think it does (i.e. limit fps), then try setting it to about 50.

[Tsorovan]

Err..oh boy, not this discussion again :)

This is actually outside the scope of this forum and my patience...I'll just say that optimally, you would want the fps to be synced with your mouse refresh rate, which in the case of USB is 125 Hz. I (and I'd wager most people unless they have someweird bad eyesight) would easily notice the difference between 60 and 120 fps, not to mention 30 and 60. Lots of people start comparing with movie/television which has 24/24.997 (pal)/29.997 (ntsc) fps, but then you forget about motion blur. Let's just leave it at that. Yes, 300 fps is not really more useful than 125 fps but it has a certain psychosomatic effect :)

[Tsorovan]

Good news! With 2.6, the performance problems are gone. I'm not sure what you did Ian, but you sure did something :D

Oh, I was thinking of something that can help the number of UI updates -- get rid of the tenth of seconds counter in the time display, it would result in a tenth as much UI updates per second, if you don't have a level meter in your skin that is (yay!?). Just a thought...

[Zarggg]

I actually like the 1/10th second counter... :p

[Ian @ un4seen]

Me too ... also the mod position, mpeg frame and ogg page counters would appear dead slow if the rate was cut.

Still... good to hear your problem's gone.

[Tsorovan]

Well, it couldn't be hard to make it dynamically change according to what time display you're using but I dunno...how about an option? Options are nice :) But aye, the main problem is gone, and I commend you for it! (Can't hurt being a tad sycophantic now can it? :D)

[Torkell]

Just had to post this:

Gah!  Tenths are good! *baps Retro*


*giggle*

[Tsorovan]

Tenths are for sportsmen and other assorted neurotics :)

[Zarggg]

Yes.  Yes they are.  And that's why we want them.

[Torkell]

:idea: You know, Ian could always have an "opt-out" facility for tenths for those of us who would like to reclaim a bit more CPU power. It won't hurt anyone to stick an option in an INI file...

*looks at previous posts*

*forsees flame war over tenths*

Erm... nice posters... nice posters <growling noise in background>

[Brightguy]

There already has been some discussion about the tenths a while back:

Tenths of second; deleting file (suggestions)

Personally, I like them.

[Tsorovan]

Do you guys also have seconds shown in timestamps in for example IRC and ICQ clients? :)
Alright, alright, I'll stop nagging. For now. Rest assured I'll revisit this later.

[Zarggg]

Do you guys also have seconds shown in timestamps in for example IRC and ICQ clients?

Well, my Trillian timestamp is set as [yyyymmdd.hhmmss], so yes.