next »

[moriez]

Hi again,

This one is not critical but ever since using XMP I can get cpu peaks up to about 15% for a while. Memory usage is ok. I just can't put my finger on why this is happening. As far as I can tell it is completely random so it works fine for a week and then oops, there she goes. Before I know it, like some songs or an album later usage is back to normal again.

In an older thread it is suggested to try with default output and DS, try different/latest versions of XMP & ASIO (also native). No difference. It happens to FLAC and MP3 albums with all kinds of encoders. No vis, no library, AFAIK playback only. I am still on XP SP3. Since I started typing this the usage is back to normal again and whatever I try to reproduce it, it stays normal. Untilll..

Well, ideas fellas?

[Dotpitch]

No vis, no library, AFAIK playback only.

So no monitored directories? How many files do you have in your playlist? Have you loaded any funny plugins (like xmp-scrobbler)? Is it checking for updates?

... ever since using XMP I can get cpu peaks up to about 15% for a while. Memory usage is ok. I just can't put my finger on why this is happening.

Is XMPlay simultaneously accessing files on disk? You can easily see this with Process Explorer. Perhaps you can even figure out which thread is using the CPU power.

[moriez]

So no monitored directories? How many files do you have in your playlist? Have you loaded any funny plugins (like xmp-scrobbler)? Is it checking for updates?

No monitored directories.
No playlist. I always right click a folder (album) and play it.
No plug-ins at all so no updates. Even XMP is never checking.

Input plug-ins are:

AAC rev7, ALAC rev3, CD rev10b, DELIX test v8C, FLAC rev8, Monkey's Audio rev2, WavPack rev3, WMA rev13,
WinAmp2 TFMX player v1.25, Archive ZIP archives

Is XMPlay simultaneously accessing files on disk? You can easily see this with Process Explorer. Perhaps you can even figure out which thread is using the CPU power.

Do you mean preloading? Will give this a shot over the weekend.

Thanks!

Edit 1: ProcessExplorer shows that msvcrt.dll is doing the hogging. However, I have no idea what to make of that. Will dig out G00gl0rz

Edit 2: msvcrt.dll is apparently part of the ''Microsoft C Runtime Library.'' I installed the Microsoft Visual C++ Redist package 2010. Uninstalled the one from 2008 that I was on. The version of the dll remains the same though. Will see what happens.

Edit 3: No good. Same behavior in the dll.

[moriez]

Just for my information: is anyone else using version 7.0.2600.5512 of msvcrt.dll on XP or perhaps even in Vista/7?

Also I would like to ask for a clue about why this particular dll could be acting up. What's it's relation to XMP?

[Dotpitch]

Also I would like to ask for a clue about why this particular dll could be acting up. What's it's relation to XMP?

The problem is probably not in the DLL, because that's a really generic library by Microsoft.

Msvcrt.dll is the Microsoft Visual C++ Run-Time for Visual C++ version 4.2 to 6.0. It provides programs compiled with these versions of Visual C++ a typical set of library functions required by C and C++ programs. These include string manipulation, memory allocation, C-style input/output calls, etc. (link)

XMPlay is using that DLL to do something, and that something apparently takes quite some CPU power. Can you see if XMPlay is reading from disk at the same time?

[moriez]

As far as I can see in ProcessExplorer it is not accessing the disk. In summary CPU Usage = 15-20% throughout while Disk Bytes is at 0 most of the time. Disk delta stuff is also 0 most of the time.

[Cris]

Could you post a screenshot of the Threads tab for XMPlay in ProcessExplorer, when the problem appears?

[moriez]

Indeed sir. Bit noob with neat work when it comes to showing pictures but here is:

[Cris]

Looking at that screenshot, my best guess is that at fault (sort of) is the asio4all plugin. Try changing the output to something else (DirectSound, maybe) and see if it happens again.

Detailed:
XMPlay itself is not even dependent of the Visual C++ Runtime, so on it's own, it shouldn't cause any problems related to msvcrt.dll (since that library wouldn't even be loaded). So whatever it is, it must be a 3rd party plugin. And looking at the screenshot, besides msvcrt, the only active threads are in asio4all.dll. Also, asio4all seems to try to unregister something, which could mean that it's stopping some threads of its own, which is also consistent with the current function call in msvcrt (endthread).
So all in all, this should be your starting point: if those CPU spikes really annoy you, start by removing the asio4all plugin, then go from there.

[moriez]

Thanks for that Cris.

I tried DS for a short time and the same thing occurred not long after with just slightly less pressure on the cpu. At the moment I have the default/microsoft output set and so far no peaks. Could this mean that the soundcard drivers are causing it? Will keep testing.

[Cris]

If you experience peaks again, you can post a new screenshot (the same as above). As I said, the above ideas were just guesses based on that screenshot. Those guesses might very well be wrong. New screenshots (from different XMP settings) might give some more clues though.

[moriez]

Here we go. Also with the other outputs the dll has to put in more work than I would like. At least we can outrule ASIO4ALL now.

DirectSound


Default/Microsoft output

[Ian @ un4seen]

Going by the "CSwitch Delta", that looks like the display updating thread using the CPU. That thread refreshes things like the level display and vis window (if open). What skin are you currently using, and does changing skin make any difference?

It also looks like you have added the "Boost" option to your XMPLAY.INI file, to give XMPlay higher priority? That's probably not making much difference unless the system is busy, but you could try removing it to see if it does make any difference.

[moriez]

Hi Ian,

Most of the time XMP remains in tray so my guess is nothing needs to updated as far as visuals are concerned. Correct?
I'm using the Lithe skin by Keltic Danor. I will go default for now and see if that does the trick. And you're right, Boost=1 is set. God knows, how you can tell When the skin changing doesn't fix it I'll set it to 0 for a while eventhough I have tried this before.

[Dotpitch]

And you're right, Boost=1 is set. God knows, how you can tell

xmplay.exe base priority is 13 (high) instead of 8 (normal).

[moriez]

Aah, k 

I am starting to think that the prob may indeed be the skin. So far haven't had any peaks. Needs some more days of testing though. Will keep you posted.Update: it's almost certain that it's the Lithe skin causing it. Have not used it since one week and not even one spike has occurred. I am happy that there's a bad guy to point a finger at. For a final verdict I feel I have to wait a couple of weeks.

[Dotpitch]

When you were still using Lithe, how long did the CPU hogging last? Did it disappear on track changes?

[moriez]

Could last for just a few minutes or for most of an album. Very different. And yes, I do believe that on track change it would collapse before rising. Would have to test that ugly Lithe again to make sure

[Ian @ un4seen]

One thing that stands out about the Lithe skin is that it uses a large (9MB) bitmap for the position knob/slider, but if that is the cause of the problem it shouldn't happen when XMPlay is minimized, as the position knob/slider shouldn't be updated then. Are you sure the problem did occur even when XMPlay was minimized, eg. might it have been in the tray without being minimized?

[Pike84]

Eh... If it's in the tray, isn't it minimized by default? If not, maybe it should be .

[Dotpitch]

Eh... If it's in the tray, isn't it minimized by default? If not, maybe it should be .

True, except when you have 'Always in tray' ticked.

[moriez]

One thing that stands out about the Lithe skin is that it uses a large (9MB) bitmap for the position knob/slider, but if that is the cause of the problem it shouldn't happen when XMPlay is minimized, as the position knob/slider shouldn't be updated then. Are you sure the problem did occur even when XMPlay was minimized, eg. might it have been in the tray without being minimized?

I am not sure at all because I don't minimize first but just click on the tray button to hide and show. The position knob/slider I never see because it runs in mini-mode all the time. The only things that move in mini-mode panel is the round position indicator on the left, the song title and track time. I will test Lithe again so we can draw some conclusions on the sucker. Right now, I have it set the way it was before: not minimized in tray.

[Pike84]

Eh... If it's in the tray, isn't it minimized by default? If not, maybe it should be .

True, except when you have 'Always in tray' ticked.

Ah, silly me... I even use "Always in tray" myself .

I haven't thought about it before, but my suggestion is actually valid. Could there be an option to make XMPlay be minimized automatically, whenever it loses focus?

[edit]Wrong thread for suggestions, but oh well...

[moriez]

It's still hard to get a hold of. In this latest test it only happened when XMP has focus. When in tray, whether minimized first or not, the peak drops. Also when it's peaking and I switch to another skin it drops but immediately returns when I choose Lithe again.

[Ian @ un4seen]

Does it happen when the Lithe skin is in normal and mini modes? The mini mode has a much smaller position bitmap, so if it is the bitmap size causing the problem, then I guess that should reveal it, ie. if it only happens in normal mode.

[moriez]

Happens in both modes. Usually I only make use of mini-mode.

[Dotpitch]

Do you have a particular track that always causes the peak CPU usage?

[moriez]

Unfortunately not. That's what makes it so hard to clear it up. The randomness. Or at least, I still think it is at random.

[Dotpitch]

Then I'd say it has to be something more than just the position indicator.

[Ian @ un4seen]

Happens in both modes. Usually I only make use of mini-mode.

OK. Perhaps it's related to the fact that a multi-state "knob" bitmap is being used for the position slider at all, not just the size of the bitmap. I don't think there are currently any other skins using that feature to make comparisons with, but here's a modified version without any position knob/slider in mini-mode...

   www.un4seen.com/stuff/Lithe-test.xmpskin

Does the problem still happen in mini-mode with that?

For reference, what Windows version and video card/chipset are you using, and are you using the latest driver for the video card?

[moriez]

Cheers. Will try it out. I am on XP SP3 with a Nvidia Geforce 6800. Not using the latest drivers. I gave up on these regular updates which added nothing but I will try latest if Lithe-test acts up.

Btw, I don't want to put a strain on you guys to fix this at any cost but if it's out of curiosity or helpful to the community I'm happy to contribute. The Royale Vista skin is an excellent replacement Lithe-test results in the exact same behavior even with latest drivers.

[Ian @ un4seen]

I wonder what it could be then, as there doesn't appear to be anything else out of the ordinary about the Lithe skin. One other thing to check... when the problem happens, is the title display scrolling? If so, you could try disabling the "Scroll long titles" option (in the "Titles" options page), and see if that makes any difference.

[moriez]

is the title display scrolling? If so, you could try disabling the "Scroll long titles" option (in the "Titles" options page), and see if that makes any difference.

Well well, heeere we go. You've nailed it with that one! That's the culprit! Still, I can't put my finger on when exactly. When it peaks on a long songtitle one moment it doesn't with another long songtitle the next moment. I leave it to you analytical minds but this is definitely a ''breakthrough'' and sufficient as far as I am concerned