CPU Load and Sound Quality

[PeterSt]

If you don't perceive differences, then your system must be way under par. Let's not forget that XXHighEnd is all (100%) about this, and the differences are huge (by means of countless settings combinations).

Btw, the CPU load is a virtual 0% at 32/768 (16x upsampling from Redbook in real time).

[PeterSt]

PS: I could have said that a tad nicer. So apologies.

But it also seems blunt to just say that you are wrong or something. So there must be a reason, which net (!) comes down to what you perceive from it. Btw, any processing (like DSP stuff) tends to kill the nuances, so there is reason #1, but it wasn't clear to me whether you are using that in this "test".

Obviously with your Ambio stuff you will be using that, so ...

 

Anyway, constructively meant.

 

But why did you come up with this in the first place ?

 

PPS: I can't get the video to play ...

 

[PeterSt]

2 hours ago, firedog said:

Didn't say Archi was infallible. Can you show his measurements are wrong? 

 

Wrong is a big word. Insufficiently detailed is another.

 

 

Here is my running time cursor again (shown many times since 2009). This repeats exactly once per second. It shows the difference of two situations of the same playback software (in a separate EXE), one with a separate GUI program showing the running cursor (this does not play audio) and one without that GUI (the audio still playing, in that separate program).

The vertical scale comprises of sample values, best resolution being the screen pixels (zoomed at will). If the maximum spread would be 50 pixels (plus/minus hence peak to peak), then this can be seen as a value of 50 out of 65536 (this is 16 bits playback here). Maybe someone can do the math on how much dB this would be, and whether any Archi-program would be able to show it. Mind you, which program also will average;  you can clearly see that the average is close to zero, because of the excursions going both sides (plus and minus) on about a sample per sample basis. Such a program would show nothing (IMO).

 

Notice that the red line is the reference (in this case the audio playing without the GUI / cursor program running) and that the wobbling in the left part is the ADC noise vs. the playback noise against that reference. And notice that both the reference recording and the observed recording, obviously contain inherent noise. So two recordings of the same situation would show the wobbling line only. But if one of the two has an even slightest difference for CPU load (or whatever load for that matter) it shows against the other.

DAC and ADC clocks are (and have to be) shared. Notice that the shown differences at least partly can exist because of the ADC itself being influenced by noise coming over the clock line and other (also backdoor) connections. But since this is all so easily audible, I would not count too much on that influence-alone.

Back at the time I always checked for bit-perfectness of any software situation by means of capturing the digital output of the one PC on the digital input of a second PC, and next compare the files after trimming the start and end.

 

I have documented many speaking examples of differences between bit perfect players against each other, all 100% repeatable if only the situation remains the same.

 

 

Without too much elaboration, my documented text going with this one is :

 

Knowing that Q1=4 seems more reliable, Compare12 the most clearly shows that in between Q1=4 and Foobar a pattern is present. It is mild though.

Note : Q1 is a dial in XXHighEnd with 34 different values back at the time. Today it can have 1700 different values. It implies a CPU "resonance" because it deals with the size of  a certain internal buffer (which can be from close to 1 sample to 23M samples or so).

And this is ONE dial. Quite many more exist, each influencing an other part of the (OS) playback system. And they all do their job in conjunction, hammering on a crucial single CPU core, or more of them, depending on what I want to achieve with it.

There is no real science in this that I can discover after so many years by now (going back to 2006), but from empirical finding quite a lot can be controlled at will (like wanting a different bass in a certain direction).

 

Surely you could reason that this all can't be audible (this is actually the common sense for the Archi-method). Well, tell that to the users of XXHE. But at least you can't say it isn't measurable.

[PeterSt]

55 minutes ago, Archimago said:

Seen nothing after all these years.

 

Well, there you go.

Hint: Jplay as well as Fidelizer spring from XXHighEnd ideas.

AO did not, as far as I know.

[PeterSt]

2 hours ago, mansr said:

Also, the 12 μs difference is inaudible. Moving your head 4 mm makes a bigger difference.

 

Yes, in your theory. Might there be a next time you visit Mani, ask him to flip up Sw#5 on his NOS1 DAC. Now you have 0,02 degrees difference at 1000Hz between the channels. With that switch down it is 0,00 degrees.

Next ask for a track with bass only, meaning not too much higher frequency elements in it, so you won't be fooled too much with the channel separation and so-called non-directivity of the lower frequencies. Now listen to the difference with these both switch settings.

[PeterSt]

23 minutes ago, STC said:

The data reaching the DAC chip would be carrying left and right. Is the a delay between this signal due to the fact that SPDIF carries the data in series. 
 

I ask this because theoretical value and actual value in my system differs by about 11us.

 

11us is half of a sample (44.1 KHz). That looks as an out of phase (180 degrees) to me. The electrical difference can't be that large, never mind if the processing is serially.

 

It depends on the whole system whether the samples will be clocked out in parallel at the exact same moment. For one stereo chip, I'd say that this will be the case, because the chip will take care of it BUT it will depend on the sampling rate. Thus, when the sampling rate becomes higher, there may not be time enough to wait for the last bit coming in (the DAC chip's buffer) while also the lot must be clocked out at some moment. You talk about SPDIF, but for i2s the same is in order.

Etc.

Anyway, it is not said at all that there will be zero difference for any random DAC. But 11us ... ???

 

[PeterSt]

30 minutes ago, pkane2001 said:

50 out of 65536 is -62dB. I’d be very surprised if Archimago’s software/hardware couldn’t resolve this —  any decent 16bit ADC is more than adequate to do this with lots of room to spare.

 

But Paul, this difference exists for one sample duration ... Nothing is going to measure that in dB. Try it yourself ! Thus :

 

+25, -25, +25, -25 and that a sufficient amount of time. This is what you see in my graphs. If you ask me, that results in 0dB net difference. And might you agree, then try one time +25 on to a minute. You won't see that in dB, nor would you hear it. But it could be graphed, like I do ...

 

But let me know whether you might agree.

 

[PeterSt]

16 minutes ago, pkane2001 said:

Say I start and stop Prime95 or another torture test a few times during this recording on the computer generating the -90dB signal.

 

Would you say this should produce some alternate bands of noise and no noise in the recording? This is a much more intensive test than a cursor blinking in your example, so should have an obvious effect, no? Anything that you see wrong with this test setup?

 

This will fail IMO because there will be too much noise to begin with. This is about the elimination of noise making it actually worse at first, because the less is left the more discrete it becomes. In the end all the noise we see may comprise of individual frequencies, most square and thus already comprising of "infinite" more smaller.

 

Do notice that in an already optimized system I can show you the number of processor/core task switches being 14 million or so. When I start my playback this diminishes to 640,000 task switches.

You are most probably stuck in the former situation and beyond (to the wrong side). So you have, relatively, so much noise, this won't bring any difference.

Mind you please, "noise" in this realm is what I showed. This is not the normal noise we measure, because this comprises of more "stretched" frequencies. What I show are actually little dirac pulses. This may measure as normal noise all right, but way more down.

 

To get the idea, look here:

 

 

If you look carefully you can still see some patterns. But would the cursor be visible here ? ... it would clearly be under the level of the remaining noise, plus this noise is constant while the cursor starts with a burst and then dies out (after 0,2 sec IIRC).

[PeterSt]

7 minutes ago, pkane2001 said:

I’m not sure why not. One sample at 16/44.1k can be easily measured if the ADC is running at say 24/192k, no? 

 

You could find it, yes. In the wave form (oscilloscope memory). That is what I do. But measure it somehow ? on what bin size ?

But you can try it with your software ?

[PeterSt]

4 minutes ago, pkane2001 said:

My software let’s you zoom in on the waveform as far as you want, in time and amplitude (I’m not talking about FFTs). So you can certainly see individual samples. But so does Audacity and I’m sure many other software packages. 

 

Yes. But the stance was that Archimago should be able to measure it (according to you). And from there I say: try it yourself with your own software.

You might already have a problem with the not-clean environment. So for example, if I measure the inherent system noise (DAC output) at something like -146dB (anyway, 30uV p-p), which I can measure because I have an analyser for that (have you ??), and in your situation that would be -120dB which is still very very good ... then what ? Then you may not be bothered at all by tiny noise differences (but meanwhile all smears because of the larger pile of noise). And please don't say that this will be inaudible ... (because we talk measurement now).

 

Incorporate my previous posts as well. Because it is still not 60dB what we measure for this noise. So the first thing you could do is set up an emulation with 0 noise, put up that value of digital 25 (which is over -66dB) (24 bit representative is fine BUT you will have visualization issues) and not 50 (because the 50 would be the variation between plus and minus, but not so important), run your program over a length of one minute, and show the dB value found.

I say : 0.00000... whatever.

And no, it is not allowed to "optimize" your program and let it to run for say 45us because it then it may show a found diff value of 33dB. So mind you, then you are looking again. This is not measuring.

Funny, actually.

 

But ...

Might you be able to measure anything (and with sufficient digits you will) you can do the math, incorporate the time element, make a realistic dB number of it, but that would *still* be about that one sample situation which is fake. A little bit more practice would be two of those opposite deviating samples, and try to come up with a measured number again. 25 + - 25 is still zero, depending on how close they are.

 

Give it a thought. I'm off for now.

[PeterSt]

Maybe to understand somewhat better:

 

 

This was the difference in accuracy I found between the two channels of my personal DAC back at the time. This is the utmost complex "measurement" because it takes the digital file as the reference, and holds the analogue output against that. The big waves are the deviation, and they already emerge from sluggishness (I forgot the slew rate of that DAC, but today's version is infinitely better at 2000v/us for its most crucial element regarding this). Anyway ...

 

See the top channel ? clearly more vague than the other channel. It is less accurate somehow.

This is NOT measurable by means of THD. Why ? because a single sine is too easy on a DAC.

 

With this in mind, try to see how other means of noise also imply this being less accurate, with of course always the idea that we shouldn't be able to hear these minute changes.

But we do. And I am really not my only customer. 😜

Of course we do not hear such matters when the noise already blasts out of the speakers at full gain. This, sadly, is so for most people. So set the volume wide open and if you hear noise from the tweeter (or worse) with your ear 1 inch from it, then the noise is at -70dB at least and you can forget about being able to hear any of this. So don't fool yourselves, have that listen, and draw some conclusions.

 

 

[PeterSt]

Paul, let's say that I am sloppy with my texts (probably because I deem it not important).

 

First off, the output voltage is 2.25VRMS. Secondly, the ~ -146dB is not SNR but just the idle noise level (I talked in that context, having the full gain and ear to speaker in mind).

From the top of my head, at a signal of -3dBFS the noise line is at -120dB (DAC output) - this of course readily urges the question: how can noise of such low levels can be audible, but make it the consistency of the signal (when you'd be able to zoom in sufficiently, you'd see the noise riding ON the signal (also the 2V etc.), not under it.

 

Then, nobody said that the lowest usage of the CPU implies the lowest noise, no matter how intuitive it would seem that this is so. The least noise means: the least varying current draw.

 

37 minutes ago, pkane2001 said:

First, I'd like to see if there is noise produced by CPU load that isn't there when CPU is idle.

 

The task ahead of you is virtually impossible without the necessary experience. Example: the cpu is never idle and the 14 million task switches *are* with the CPU being idle (in your terms). Say "nothing" running in the Windows OS (CPU usage shows -%) and then you'd have that. It's the worst opposite of being idle already.

 

42 minutes ago, pkane2001 said:

Fair?

 

Thus No. But for the unexpected reason (just told about).

 

I'll let it be from here on and I hope you don't mind. My graphs are there anyway, and for myself that is sufficient. Plus, maybe you recall me telling about the many months it took me to set up tests like this (although that included the programming for it).

[PeterSt]

19 hours ago, pkane2001 said:

I have some experience here... having written a full multi-tasking O/S for 80386 processor in the mid-80s. Task switching, scheduler, memory manager, DMA, interrupts, device drivers, storage management, protection rings, all that is old hat.

 

Paul, I hope you understand I wasn't trying to offend you. My experience is/was quite similar, back from the 70's, though main frames. But

 

19 hours ago, pkane2001 said:

Well, yes. But if 99% cpu utilization with many active threads and context switches doesn't generate a difference compared to a 1% load, I don't see how a blinking cursor could do this so easily 

 

that requires different experiences and in the end knowledge all together. When I started with this, I wasn't measuring computers as such, electrically. Why would I have. Why would anyone do such a thing. Why would anyone do such a thing on behalf of audio ? He surely should be crazy doing such things (mind you, this still counts today, only not for me). So as I said earlier on, there is no science in it that I can see, but working on these matters for over 10 years brings some empirically found knowledge (yes) which is still hard to describe because it is all unknown, not written about and even rejected by those who are educated in the field.

 

The 1 % load would probably be the worser one because of more distinct (noticeable) peaks. Trust me.

 

Get yourself a power meter. 20-30 USD. Put it in the mains outlet, and put your PC in it from there. Btw, notice that for me this would not be a situation to listen to/through because it will sound bad. Yep.

 

A PC, hence CPU, and obviously the one I am using (which is a 115WTDP or so Xeon)  is capable of about "instantly" drawing 20-30W more from the mains. I never measured the "instantly" but I regard it to be a few milliseconds (others may know or may be able to find the data on ATX PSU (latest version)). And I say 20-30W because that is what I see myself in an idle environment, not really power controlled or optimized. Thus this is NOT derived from some kind of instant testing, and putting the CPU from idle state to engaging all of its cores to 100% instantly (but theoretically it would imply something like a 100W more, as "instantly").

Now how to think that this will not influence everything and all, hooked to the mains, or what will be going on over interlinks (USB) otherwise. Of course, when all it made for it, the influences vanish. Part of it is a linear PSU which is slower (yes, think about that too). But when too slow, things won't be able to cope and again SQ worsens (this is why a very small TDP processor never sounds good, but actually this is another story - though notice that it is related because you can't solve the 20-30W issue by means of a lower wattage CPU). The headroom of the Porsche vs the Trabant (sorry).

 

The movement of that cursor is that 20-30W increase. Try it. And once you see it happening, you start to dig what the heck is going on in that stupid OS, why it happens, and that indeed it is all so.

Not when *I* start playback, this is all moved out of the way. Now the usage is varying 1.5W only (which I still deem to much but this is USB related and out of my real control), with playback (say 32/705.6) going on on top of it.

Btw the whole OS tweaking (also done by XXHighEnd) causes a normally idle running system like this - that consuming 90-120W - to lower that consumption to 45W.

Now also think of a 20-30W varying on to 90W is less impacting than 20-30W on to 45W. So these elements also play its role.

 

 

I'll stop here, because this isn't supposed to be a lecture or something of that kind. But it hopefully tells that my systems programming experiences from back in the days, don't do really much to the knowledge required for this stuff. One thing though: your interest will go in this direction easily, because of that base knowledge and experiences.

Btw, I recall it took me more than a year to tame the Garbage Collection of the Windows OSes (OSes because in each version they change things to it). So this alone validates some reading into Mark Russinovich System Internals books.

And when all that has been done, we're up to influencing the lot because we can now first see it. Next up is whether it would be able to change sound. Say that this is today, anno November 2019.

 

Obviously for me the path went the other way around; I first made the influencing from some theoretical ideas (which computer playback for the better also was such an idea), that worked and then some kind of first next was writing this analysis software.

And all I really learned from there is that the least deviation of those graphs compared to the reference line, would be the most accurate representation of what's in the data (the file). Already that part is killing, because when it is 16/44.1 Redbook, that won't be what we play. It has to be filtered first ... Anyway, this is why I showed the graph of the lesser accurate channel. These things *can* be measured. And it is easy to see how a discrete number could be dedicated to the deviations. 

 

 

As a matter of fact, I started out with such discrete numbers, but it didn't tell what was going on ...

Still it could be an accuracy number.

 

[PeterSt]

1 hour ago, pkane2001 said:

So can you please describe how the top graph was captured? Was it captured as digital data, or analog output using an ADC, scope or analyzer? And at what point in the DAC was this captured?

 

7 hours ago, PeterSt said:

 

 

In that one, you mean ? Ehh, this is left (top) and right channel. It is another take of what I showed earlier on, of the inaccurate (left) channel. Btw, this is just stereo, but the deviation is always in the left channel, thus it is not the music.

 

The reference is here the digital file data. The (black) deviation is ADC captured analogue data (RME FireFace800), just at the DAC output, at the end of the interlinks; Just a normal connection.

 

... But this is almost all irrelevant, because it was only about the (possible) accuracy number that can be created, once an absolute reference exists; a digital file is that anyway.

A playback program without running cursor (etc. etc.) is a good reference just the same. But the anomalies in the reference (when captures themselves) have to be taken into account too. So it takes several comparisons to draw the correct conclusions about which does what. Example of this, with my emphasis to the text (not the graphs) :

 

Compare11 is generally showing that some consistent thing is going on in my DAC; Where the mousepointer shows, right below you see the same but expanded (this is Q1=-4 doing that !), while the third trace shows exactly the same though in opposite phase, but dead sure again Q1=-4 doing it. If you look closely at the (1), (2), (3) above, you see there is no common denominator (none of the three elements, -4, +4, Foobar is in each of them), so my DAC must be doing this by itself. However, it is emphasized or it is not (like in trace 1 it is not).

 

I hope it is not too confusing. But if I'd take each of the bottom two captures for further reference, then those lumps would be visible in what I compare it to; not good.

This is all obvious of course, as long as it's understood what is compared and how a "reference" is chosen. For example, if my ADC would add something on its own, it would be visible in everything. And since it just is, it has to be visually eliminated. Btw, quite tough for an "accuracy number".

 

 

[PeterSt]

but the scientists didn't turn up.

[PeterSt]

Does the possibility exist that this kindergarten changes into a biergarten again ?

 

[PeterSt]

The colour was wrong.

[PeterSt]

20 hours ago, pkane2001 said:

If there is an audio design that really takes days to get to optimal operating conditions, you can be sure that is a broken design.

 

Paul, why ?

[PeterSt]

23 hours ago, pkane2001 said:

So why is it that audiophiles are the only group in the world that suffers from cable and component break-in? 

 

Because what we *1) can hear can not by measured by anyone *2) ?

 

1) Make that me. Not you.

2) No comment.

 

😊

 

 

[PeterSt]

5 minutes ago, sandyk said:

You keep forgetting that this is an Audiophile forum

 

You keep thinking this is an Audiophile forum.

[PeterSt]

14 minutes ago, sandyk said:

Without their support this forum would more than likely cease to exist.

 

This forum will continue as an explicit non-audiophile forum. Or maybe not at all.

[PeterSt]

3 hours ago, STC said:

So that will be a non issue.  Sometimes when they use adapter it gets reversed.

 

Of course it matters. But it is out of your control unless you "measure". Doing it "all" wrong implies the largest current flow over interlinks. "All" right, implies the least current flow.

It is a matter of trialing because you won't know how the devices hook up internally. Two the same amps will be the same (hopefully), but the (matching) preamp already maybe not. And all of the other stuff ...

[PeterSt]

PS: Over here (the Schücko) we are lucky to be able to reverse the plugs at will.

[PeterSt]

Just now, semente said:

I use one of these to check the polarity.

 

But that is not the device to use. You should measure the "connection" hence current flow. The other day I posted the Van Medevoort "meter" ...

wait

[PeterSt]