▲

[JimVonMoon]

OS: Windows 98 SE
CPU: P2 350MHz
CPU usage: (according to SYSMON.EXE)
- no vis - about 7% while playing 128kbps mp3
- vis - dunno, I'm not using this things

...and I must say that I feel perfectly good with this results. I use my compy mainly for internet (IRC, email, usenet, www and such stuff), programming, spreadsheets and word prosessing. I have got lots of unused CPU power and this 7% result suites me fine.

[Pike84]

Hmmm... I'm not sure if people get this CPU drain correctly (if I do ). When I see Xmplay in the task manager and the respective percentage, it means Xmplay is using that amount of CPU power of ALL drainage.. so if the Xmplay's percentage would be 100, that would only mean Xmplay used all CPU power of all CPU power in use at that time - not that all CPU power would be in use (of Xmplay in this case).

So I can't really tell right away, how much Xmplay consumes of my total CPU capability. The task manager does tell how much CPU is used at any time, but other tasks add to that too. Even if Xmplay was the only program running, there's always "system idle process", which in my case at least, takes most of the CPU power in use (around 90%), while the total CPU drain with XMplay running, is around 10%.

Sounds complicated? With me explaining it brilliantly?? No, I'm not sure if anyone gets my point, but think about it

[Ralesk]

In NT/2k/XP ("NT" from now on), there is an idle thread with process ID 1.  This uses up the unused CPU power, and gives amounts of CPU times to the other processes.  From my view it seems similar to UNIX's idea of having init as the parent-of-everything process.

Uh.  So in NT you measure percentages from the whole.  I'm not really sure if the numbers are anywhere accurate in the bogus multitasking of win9x.

[Ian @ un4seen]

So, I gather there's no "looking into" this one eh? Oh well...I guess it'll make me start calling the otherwise excellent XMPlay a resource hog. Nothing works as good as a couple of nice application insults, wouldn't you say?

The thing is I'm not sure there is really anything to look into, regarding CPU usage atleast (I don't have Q3, so can't look into that )... I'm pretty confident that XMPlay has amongst the lowest CPU usage of any player, especially when minimized (time/level/vis displays are not updated then).

I think what you're seeing is down to Task Manager (or rather the way NT-based systems measure CPU usage). For example, when you say "Winamp never even took more than 1% on my Celeron 400@510 MHz", I can assure you that was not really the case - Winamp 2.8 (with no extra plugins in action) takes almost 3% CPU playing an MP3 on my XP1700 setup.

From what I can see in this thread, the Win9x users (ie. using WinTop rather than Task Manager) are reporting lower CPU usage for XMPlay than Winamp. And from personal experience, WinTop is a much more accurate judge... see this thread, for more info on why Task Manager is not to be trusted
http://www.un4seen.com/music/YaBB.cgi?board=bass&action=display&num=1030698202

Regarding the Q3 problems, my guess would be the same as BoggyB's. I've never tried Q3, but have not had problems running XMPlay with any other games. Do you get the same problems with other games? What about if you try XMPlay+Q3 on your other computers?

[Tsorovan]

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.

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.

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

[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...