Jump to content
IGNORED

CPU Load and Sound Quality


STC

Recommended Posts

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.

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
7 minutes ago, PeterSt said:

 

But Paul, thus 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.

 

 

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? 

Link to comment
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:

 

image.thumb.png.e1a77394a38817a78737ffc0ed76b772.png

 

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).

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
4 minutes ago, pkane2001 said:

 

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


When I set the project to 192, the difference becomes negligible even with original 44.1. Unfortunately, the bandwidth is limited to 8 channels. So for now I am stuck with 96. 
 

Thanks to all for the answers. Apologies to the OP for going OT. 

Link to comment
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 ?

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
Just now, PeterSt said:

 

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 ?

 

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. 

Link to comment
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.

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment

Maybe to understand somewhat better:

 

image.png.023fec06bf23e62733f1bdce6cba3ec6.png

 

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.

 

 

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
8 hours ago, STC said:

Humans use ITD from as little as 10μs to 600 or 700μs. If the delay is constant ( and it could be true) then it is possible that the center image to be slightly off centered. That probably explains why every audiophile would have noticed that getting center image is always inconsistent. So what carefully  controlled condition you are talking about?

Did you not see the illustration I included? A constant 12 μs delay in one channel is equivalent to sitting about 4 mm off centre. You'd need to clamp your head in a vice to maintain your position that accurately.

Link to comment
16 minutes ago, mansr said:

Did you not see the illustration I included? A constant 12 μs delay in one channel is equivalent to sitting about 4 mm off centre. You'd need to clamp your head in a vice to maintain your position that accurately.


So? There won’t be other delays?  All signal come with constant delay?  I do this on daily basis and it is audible if you are looking. 

Link to comment
8 hours ago, STC said:

You may have just unraveled a mystery that has been bugging me for three years. How about the the small USB DACs. They come with single DAC. Audioquest Dragonfly?

Every modern audio DAC chip has at least two independent channels. The incoming serial data is buffered and released to the conversion stages simultaneously.

 

The only audio devices I'm aware of with the channel offset are the first generation of Sony CD players. Their DAC chip had only a single D/A conversion stage that alternated between the channels. Philips used two TDA1540 chips in their early models, later switching to the TDA1541 which has two channels.

Link to comment
2 minutes ago, mansr said:

Every modern audio DAC chip has at least two independent channels. The incoming serial data is buffered and released to the conversion stages simultaneously.

 

The only audio devices I'm aware of with the channel offset are the first generation of Sony CD players. Their DAC chip had only a single D/A conversion stage that alternated between the channels. Philips used two TDA1540 chips in their early models, later switching to the TDA1541 which has two channels.


That is where I am still looking for an answer to find out why the delay doesn’t tally with the calculation. 

Link to comment
12 hours ago, PeterSt said:

 

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).

 

Peter, certainly I don't think a single number like THD, or THD+N or jitter or whatever represents everything about a DAC or a system. DeltaWave produces some RMS null values, jitter and phase offsets as part of the analysis, but these are also not enough to completely describe the distortions or noise all by themselves. That's why in DW there are plots of various data over time, frequency, etc. to allow you to view the differences in much more detail than could possibly be revealed by a single number. Easy to zoom in on any portion of the plot to see the magnitude of the differences.

 

-146dB from a 2v output represents about 100nV, not 30µV. I'd be curious what equipment lets you measure such a low level signal. Even the best AP analyzer I'm aware of doesn't go down much below -120dB or so. And no, I don't have an AP analyzer. Which one do you have?

 

I am suggesting a simple test trying to reproduce what you posted. First, I'd like to see if there is noise produced by CPU load that isn't there when CPU is idle. Capture a waveform at the output of a DAC with a quality ADC at high sampling rate, then compare it to the original waveform. No averages, no FFTs, just simple waveform comparison. Once we confirm that CPU activity causes unusual noise at the output of a DAC, we can then talk about analysis, measurements, audibility, etc. Fair?

Link to comment

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).

Lush^3-e      Lush^2      Blaxius^2.5      Ethernet^3     HDMI^2     XLR^2

XXHighEnd (developer)

Phasure NOS1 24/768 Async USB DAC (manufacturer)

Phasure Mach III Audio PC with Linear PSU (manufacturer)

Orelino & Orelo MKII Speakers (designer/supplier)

Link to comment
40 minutes ago, PeterSt said:

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.

 

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 :) 

 

46 minutes ago, PeterSt said:

The task ahead of you is virtually impossible without the necessary experience

 

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.

 

So I'll try to reproduce your 'blinking cursor' result. But from past experience, this will not be easy. Maybe I can find a DAC or two where the CPU load does affect the output. I'll give it a shot.

 

 

Link to comment
1 hour ago, Ralf11 said:

 

So, you're normal

 No, S.T. is a little different to most in this area, possibly you too . This partial quote is from another forum

Quote

I do not perceive things like depth and width as what most audiophiles describe......

 

 

How a Digital Audio file sounds, or a Digital Video file looks, is governed to a large extent by the Power Supply area. All that Identical Checksums gives is the possibility of REGENERATING the file to close to that of the original file.

PROFILE UPDATED 13-11-2020

Link to comment
4 hours ago, pkane2001 said:

 

Once we confirm that CPU activity causes unusual noise at the output of a DAC, we can then talk about analysis, measurements, audibility, etc. Fair?

 

You see, Alex, that's where we have a problem here ... the technicals want the cart before the horse - unless something is measurable, it can't possibly exist 😜... the poor ol' universe, out there, struggled with self confidence for millennia, because humans hadn't worked how to 'measure' it - only now, slowly, is it starting to be feel OK about being so unusual, because people are pumping out more and more numbers about it - its sense of reality will finally fall into place when mankind gets all the i's dotted and t's crossed ... 🙂

 

Trouble is, this tidiness has failed to make it into, say, the medical world - wouldn't it be great if you were not feeling OK, and then the best experts of the day proclaimed that they can't find anything wrong ... you would be instantly cured, because "It was all in your head", 😉.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...