Weird CPU-usage behavior

[DannyD]

I’m seeing some pretty weird CPU usage.  I have my device buffer size set to 64 and the buffer size on my Lynx card is also set to 64.  My CPU appointment scheme is #3.  File split size is 200MB.  I’m playing QAP with Engine 4 in Adaptive Mode. 

Here’s the weird behavior:  On the first track of an album, the right CPU usage fluctuates in approximately 2-second intervals between 1% and 12%.  On the second and subsequent tracks of the same album, the CPU fluctuates in 2-second intervals between 2% and 50%.  If I hit the NT (next track) button, the CPU-usage resets to 1-12% fluctuations, and on subsequent tracks back to 2-50% fluctuations.

Any thoughts?  Does it matter?

[DannyD]

By the way, the same thing happens without upsampling, but the range of fluctuations is lower: 1-4% for the first song, and 3-14% for subsequent songs.

[PeterSt]

Now that indeed seems strange !

What happens if you set the Split File size to 100, so you'll be sure in the middle of a track there's disk access needed (you'll see it on the large cpu spikes as well), and might it then be so that the 50% behaviour starts at the first peak (which will be after (dunno) 50-60 seconds of playback) ?

If not (which already seems likely because the 200 also will access the disk I think), I'm puzzled ...

[DannyD]

Reducing the file split size doesn't change the behavior. 

I experimented by trying "special" mode instead of "adaptive", and I get the same behavior where the CPU is much lower on the first track than on subsequent ones. The band of fluctuations in cpu-utilization is tighter: 12-15% for song 1 and then 50-54% for song 2-N, but the difference between the first and subsequent tracks is even more dramatic. 

Is this okay, Peter?  The X3PB log in adaptive mode typically isn't typically showing any errors.

[PeterSt]

No Danny, this is FAR from okay. As said, I am puzzled. I wish I had that here, so I could dive into it.
During me cracking my brains, if you have anything (maybe) useful to add, please let it know ...



PS: Do you have anything to compare with (another soundcard) ?

[Telstar]

No Danny, this is FAR from okay. As said, I am puzzled. I wish I had that here, so I could dive into it.
During me cracking my brains, if you have anything (maybe) useful to add, please let it know ...

FYI, I also notice (in y-6 too) some cpu spikes when changing tracks.

But what bothers me ( Peeter, see update in the "awfully slow" thread) is the slowness, the time it takes to start the first track and the gallery behaviour.

[PeterSt]

Hi Telstar,

I'm afraid you are doing that to yourself by asking for the ultra low latency, *and* wanting to use the PC at the same time . It can't be done. In any case it is not related to what Danny has here.

Peter

Edit :
PS: But in the other topic I now see your problems are actually different, as it seems. In any case, it doesn't belong in this topic, ok ?

[GerardA]

Don't know if it's usefull, but now  I am back to Y9-5-6 and the CPU is going crazy too.
Soundcard buffer is at the lowest, Q1 = -4 (lowest possible) and the sound is ok (but normal mode).
At start of playing the display goes black and takes some minutes to reappear.
If  I open taskmanager it takes a long time to open and shows nothing.
After some minutes it shows a lot of 100% spikes on al four cores for the complete period available in the graph.

But the music is ok!

[DannyD]

The behavior I am seeing in special mode is different from what you’ve experienced.  The CPU-utilization graph on the task manager is so consistently odd that it looks like a sewing machine stitch: 1%-12%-1%-13%-1%-12% at 2 second intervals through the entire first song and then the same thing for the second through nth song only the swings are 2%-50%-2%-53%. The music is fine.

Yesterday I tried changing the buffer sizes but the problem was still there, albeit at overall lower CPU-utilization levels with larger buffer sizes.   I checked with Earflappin offline since I know he has roughly the same set-up, and his system is working normally.  He suggested I do a fresh install of XXHE , which I will try later today.

One other thing I will have to try, however painful, is to reinstall 64-bit Windows 7.  I recently installed 32-bit on top of 64-bit in the hope remote desktop (from my macbook) would be more stable.  Of course it didn’t help, and I never noticed this odd CPU behavior with the virgin 64-bit OS. Of course, I never ran .9-y7 either.  And now Peter is threatening a 64-bit version of XXHE, so I guess I'll want to re-install 64-bit anyway.   

[GerardA]

Danny,

I got this weird behavior after playing with the player-priority, Q1 and split-file size.
You tried these?

[DannyD]

Yes, I've tried changing split size and priorities and neither changed this utilization behavior any more than what you'd expect they would.

I just finished the test of re-installing XXHE .9-y7, and I'm getting the same strange behavior.  Next I'll try .9-y6.

[PeterSt]

Danny - Can you try whether "Copy to XX drive" Yes/No makes a difference ?

Also, you may try Performance Monitor (button on the TaskManager "performance" tab) to see what is causing the 50% cpu, once it occurs.

[DannyD]

“Copy to XX drive” doesn’t seem to make a difference.

The biggest CPU-user in Resource Monitor during tracks 2-n is XXEngine3 by a wide margin.   Second is usually System Interrupts. 

I just tried .9-y6 in special mode and the CPU behavior was as I remember it: with a buffer size of 32, the CPU was pretty consistently between 9-11% regardless of track number.   Back to .9-y7 and the same yo-yo usage.  This sort of disproves my premise that it could be related to installing 32-bit Windows 7.  Do you think, however, that it’s worth re-installing 64-bit?

[PeterSt]

No ...
Regarding what you just wrote ... it must be me, somehow. But how ? ... I will try to find it.

Thanks,
Peter

[PeterSt]

The more I think about this, the more I'm convinced this must be me; There is just no logic in the driver behaving differently at a next track, while you don't want to know what is different on my side when a next track is occurring. So, *will* find it.
Don't ask me why this only occurs with you though. But there are so many bugs to "create" ...

Notice that 50% is just something constantly looping (within one core).
Peter


PS: Did you try it all without Wallpaper, OSD Text and OSD Tunning Time ? ... it must be related to that (I think) ...

PPS: This all is Unattended, right ? If so, why not post the X3 and X3PB log files ... Grab them when you're sure the 50% showed for some 20 seconds or so.