XXHighEnd

If I'm using an ATOM-330 based PC running XX there are sometimes pops with low buffer and low Q1 settings. Looking at the task manager I can see a good balanced CPU load over the 2 cores and the 2 hyperthreading cores (every core appr. 5% load). If the pop happens the load of one core increases to 100% load for a short time (as shows Engine3 in process explorer). What could be the reason?

Cheers,
Georg

Hey Georg - I will try to explain it :

The peaks you see are very normal, and are needed to process a next track, or part of it. Notice this is related to your "Split File size" setting (Settings Area). But since you're using an Atom, things may become difficult ...

Generally we can say, the higher the Split File size setting, the less of those peaks you will see, but the more intense (and/or longer lasting) they will be. So, what you'd stribe for is "once per track". Now, there are two reasons you won't be able to achieve that :
1. Too few memory;
2. Too intense to avoid the plop (etc.).

#1 can theoretically be overcome, but it implies #2 to be worse, so, the solution is to decrease the Split File size setting, no matter you should stribe for the large setting; it just won't go for you.

Note : I am thinking of applying "the peaks" somewhat differently, which is related to them now being spread over two cores, and thus interfering with playback. The net result of stearing that to core one, however, may not be better. This is because now (then) the processing will take much longer, that preventing other tasks not being able to continue (the xx other OS tasks still around), and the result may be worse. I must say though that I don't know the effects at this moment, just because I never tried.

All 'n all "we" are working towards two contradictions :
a. Achieving the lowest latency possible because of better sound quality (never mind how, but it is so), that requireing more processing capacity;
b. Using small boards (small cabinets) with so far less processing capacity (like an Atom just has (far) less processing capacity.

Let me add to this that XXHighEnd goes over the top from all directions, because it's not only playing from memory, that requiering the processing in peaks, but it's also using the ultra low latency (unheard of really), which is a contradiction within itself;
For a normal processor this goes, but for an underpowered processor this is too much asking.

But I'll try to change some things in a next version, in order to let it go in all cases.
In the mean time, play with your Core Appointment Schemes which *really* matter in this case, set the Thread Priority to Real Time and the Player Priority to Low, and when you have found the "least disturbing" setting, lower your Split File size to the point you hear no pops at all.
And, assuming you are using KS Adaptive Mode (which is really the advise at this moment), you may observe the X3PB log file for the Buffer Errors decreasing, while you changed settings. Notice that they may emerge just at those peaks you see.
Lastly, notice that buffer errors around a peak because of loading a track part are different from those at loading a track, *unless* you shut off the Wallpaper and OSD Text, then they can be interpreted as the same (refreshing the Wallpaper is one of the most heavy tasks, and that only happens at track boundaries (a few seconds before the end of a track), or when you change the digital volume.

HTH !
Peter

Ok, I tried, but what I wanted to do is already in there : Core Appointment Scheme 1. This moves the load activity to the first Core and playing keeps on happening on the second Core.

But does that help you ?

Peter

I have been playing with this a bit myself now, but even if it avoids the pops etc., it is not said you are going to like it. Because remember, while all the "other" activities now (Scheme-1) nicely go to the first core, it takes relatively ages to preproces stuff (you just cut out 50% of the available capacity). So, YMMV !

Peter

I found a solution in the mean time - I need speed, speed, speed. I tried all combinations but always had similar problems. I found the help in some overclocking forums and that's what I did:

• Disable the two hyperthreading cores via BIOS
• Overclock the ATOM 330 to 2.1 GHz. That works fine if there is only XXHighend playing. I determined core cpu temperatures of about 45 °C, 85°C is specified by Intel
• Spend some extra PCI latency for the Juli@ via BIOS
• Use Scheme-1
• Set split memory to 12 MBytes

Until now I'm happy with double sampling / arc prediction for 16/44.1 and 24/96. Thanks a lot for your experiments.

 :scratching: I forgot to write that the system is right now very sensitive of electrical interferences from the power side.

Cheers,
Georg

Just one question :


Was this the advice ("That works fine ...") or your observation ?

Just for my understandings. Thanks,
Peter

I got two of ATOM-330 based PC's. I modified both as written above and found a problem with the second one. I had to decrease the CPU clock to 2 GHz because the installed RAM was too slow :( Apart from that the systems are working stable.

Georg 

There is a little strange behaviour: Sometimes the first title from a playlist plays flawless but the second title (and the following titles) are interrupted by memory load frequently. If stopping the replay of the second title and starting the second title again, all works fine - until the next title of the playlist. What could be the reason?

Georg

You are not using Anti Imaging, right ?
And is this with Attended ? (just the answer is sufficient, you don't need to try the other mode)

Yes, it's attended but I'm using double with arc prediction.

Georg

Looks similar to this one I think : Weird CPU-usage behavior (http://www.phasure.com/index.php?topic=1145.0).

But what do you exactly see with this "memory load" ? (I could also ask what you mean by this).
Can't you post a screencopy of the graph of it ?

I made two screenshots: The first shows the right behavior the second the interrupted playing. There is an additional constant load in the second cpu core. The music playing is interrupted when the performance peak arises in the first cpu core. I can hear another characteristic symptom: There is a little relay build in the Beresford DAC which disrupts the output if it is searching for the correct sampling frequency. It is clicking exactly at that time - he SPDIF output ist disturbed. 

I found the problem from the other topic (Weird CPU-usage behavior). Can that be your case too ? (Attended and not show Wallpaper)
It doesn't look like it, but who knows.

Do you run Attendedly ? (sorry if you already told it)

I followed the tread with DannyD and my problem is solved too with this workaround  :thankyou:

Georg

Aha ! That's more than what I have hoped for. Especially since your graph looks completely different from mine (and what I expect from Danny's) -> Spikes.
Anyway, it is solved for the next version.

Just one additional question : how do you manage to have such a low memory useage ? I mean, XXHighEnd may just manage to use that few, but where's your OS necessities ? or is the Atom enforcing this ?

Thanks,
Peter


PS: For me Scheme-1 doesn't work well. Not with a 100MB or so split size. The boundaries are just audible then. So my theories may not match reality. And to keep in mind : you may reconsider your settings now the cpu is more normal.

Ha ! Actually, I think you just saved my day !!

Ok, this is maybe more talking to myself, but it is also informative I think;

I have been working the whole day to find out whay may cause those stupid peaks, while from the program point of view there can't be peaks. Look below for an example of KS Special Mode 22 samples latency (into a 128 samples buffer).
Also, the types of nice graphs vary with all kind of things you can vary with yourself. Now :

At analysing everything by means of cpu usage in the program itself, it is my conclusion from there that the amount of cpu used can not be registered at all times, thus, asking for it in a fixed interval, won't show updates other then at *another* fixed interval which is outside my view. And, I already notice that what we see from the cpu graph by the OS (like below picture) in fact shows the same. So :
The OS is (very) periodically too busy with other things, to update "my" cpu usage.

... But not so with an Atom processor ...

At least, that is what I now think;
The problem you had (with the Wallpaper and stuff) in fact is a very constant loop, and your Atom shows this as a constant loop. In my case though it shows as spikes, similar to the graph below. But it ain't spiking !

And thus, what we see (for the "normal" Intel) just is not reality. It also explains why in between the peaks a virtual "no cpu usage" shows, which to my believe is sheer impossible with 22 samples latency to begin with. Nope, it is the average we should watch for, and the peaks are just "fake". In total they will be correct, but not what we see in real time.

I hope this solves a kind of psychologial problem for myself, because I can't stand those peaks, them clearly implying that I'm doing something wrong (like the Wallpaper thing was such a real life example of it).

Peter 8)

The cpu chips are more complex systems than ever before. From my point of view it is not possible to "reengineer" the behaviour. It could be interesting (but costly :( ) to build up a chip with the components only which are necessary for computing the datastream. But that is another project  ;)

Georg

I did things as usual - disabling everthing what is not necessary. The only unusual I did was disabling hyperthreading.

Georg

An observation here if I may that could be clouding some judgements.

The amplitudes of these peaks we are seeing are influenced by the refresh rate of the graph. Go to the "view" menu, and drop refresh rate to low , assumming you were in "standard" by default, and notice the peaks drop considerably. Increase the rate to "fast" and observe the peaks are now more intense.

The mere act of having the CPU Usage graph active is causing those spikes as has now been surmised. Could it be implied that not having the CPU monitor running at all would flatten the peaks even more ? There is good cause to suggest that may be so.

Use the graphs as an indicative tool for sure, but the absense ( or presense ) of clicks and plops should be your final indicator that things are OK or not.

Cheers,

Russ

Hahaha ... but no ... My graph already is on the highest spead. And after a day of peeking into everything I really know a bit about the internals (ok, I think).

Btw, what also is funny to observe, is that when at last the cpu data is updated (how much is used is written to the specific area(s)), there are buffer errors. 100% consistent behaviour. The time when it's done is also 100% consistent, as is the graph of it (from lump to lump is several seconds).
But ! don't let yourself confuse by this remark, because the logging of it all (which plainly happened per sample here) takes so much away that buffer errors become a standard.

But thank you for your observations Russ, and to a certain extend you are right of course.

For your fun (etc.) below a part of a list I created dozens of. Each line shows a moment of new cpu usage data. The right column shows how many samples have passed since. As you can see this is a very fixed interval to begin with (the 44032 entries). And try to keep in mind how small of a time unit 1 sample represents, and thus how accurately (in the time domain) the cpu data is updated. Now also see the large numbers; this represents the time the cpu data was *not* updated. Suddenly it takes a 100 times longer before it's done and as you can see this spans some 2 seconds. Exactly the span between the top of the peaks ...
Because of the buffer errors occur in the exact same period as the cpu data won't get updated, it tells me that the OS thinks it is high time to at last do some tasks for other clients, after some 2 seconds (watch out, this is another 2 seconds as those mentioned before) of spending time on "me".

Btw, if you grasp this a bit, you now may understand better how in Vista the services automatically were shut down, which ... now I think of it, never happened in W7. Pitty.

Peter


PS: I learned a lot of this, and maybe ... just maybe there's a new Mode in my head.
:swoon:

hehe ... I did write in a "get out" clause that it "might" cloud judgements  :whistle:

Without the benefit of your extra logging features it is hard to judge exactly what is happening behind the scenes, but your logging extract had shed another light on that now. Interesting.

I've attached a CPU usage graph of my system FYI and comparison. I also get those regularly intervalled spikes as you can see.

Setting as per in signature.

Cheers,

Russ ( loves waking up to new versions )