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 .