Jump to content
IGNORED

CPU Load and Sound Quality


STC

Recommended Posts

45 minutes ago, sandyk said:

Sorry STC, but this IS true and not just Audiophile folklore .


I cannot comment on this because I do not know how the system actually works. Technically, digital data streams serially so a SPDIF output would have a sample delay between the left and right. That would be so small to be easily visible looking at the waveforms. However, this can make a difference in the soundstage. Depending how the DAC was designed whether the delay was compensated or not is not known. 
 

Is it possible that when you stream directly the small delay between the channels either increased or reduced? If it so then it points to a flaw in the modification. 

Link to comment
9 minutes ago, STC said:


Alex, you can ask John about my contribution. Including about one of the version you praised so highly. 

Yea -- I didn't connect the discussion -- you are in the PM list.  Can everyone see who is particiapting in it?

I am agnostic on the audiblity of digital noise leaking into the audio -- it either happens to an audible extent or not...  I truly do not know from my own experience because my hearing goes 'hissss' all of the time, even without hiss in the signal or electronics...

 

(I probably shouldn't participate much in this discussion -- my ability to hear low level noise and other such effects is long gone -- mostly tuned to hear various kinds of distortion, that is it.)

 

John

Link to comment
21 minutes ago, STC said:


Alex, you can ask John about my contribution. Including about one of the version you praised so highly. 

 Your last reply was 9 days ago when you said the attached. Perhaps you have given John additional feedback elsewhere such as email ?  In fact, John took a break recently in his posting due to the lack of participation, which suggested that participants were losing interest in the project due to perhaps too many samples being provided ?

Quote

…….I am sorry that I have not been giving any feedback lately. It is not that I have no interest in what you are doing but I do not think if we are constantly exposed to various versions can be objective our judgment. 

Anyway, we are now well and truly OFF Topic ,and I doubt that any consensus will ever be reached on the subject of this thread.

In the meantime, quite a few members in another area of the forum are even reporting hearing differences between different types of RAM

 

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
Just now, sandyk said:

 Your last reply was 9 days ago when you said the attached. Perhaps you have given John additional feedback elsewhere such as email ?  In fact, John took a break recently in his posting due to the lack of participation, which suggested that participants were losing interest in the project due to perhaps too many samples being provided ?

 

I believe that the listening for feedback should be done only as a 'fun' activity -- maybe a slight sense of responsibility, and that is it.  However, anything I post is certainly okay to casually listen -- enjoy, and let me know if you happen to hear some kind of problem.

 

I am trying to make some listening a little 'fun' for people, while maybe getting some crumbs of help from time to time.  Alex does a lot of participation and help, and I thank him a LOT.

 

Nothing at all wrong with being busy on other things!!!  I sometimes I wish I didn't have this terrible obscession -- honestly biding time until some important doctors appts, after which I might be able to work a little on the C4.... 

Kindness!!!  That is the key!!!

 

John

 

Link to comment
45 minutes ago, STC said:

I cannot comment on this because I do not know how the system actually works. Technically, digital data streams serially so a SPDIF output would have a sample delay between the left and right.

That is incorrect. Although the left and right channel samples are interleaved, the receiver buffers the data and does the A/D conversion simultaneously.

 

The early Sony CD players did have a half-sample delay between the channels, but that's ancient history. Also, the 12 μs difference is inaudible. Moving your head 4 mm makes a bigger difference.

Link to comment
17 minutes ago, mansr said:

That is incorrect. Although the left and right channel samples are interleaved, the receiver buffers the data and does the A/D conversion simultaneously.

 

The early Sony CD players did have a half-sample delay between the channels, but that's ancient history. Also, the 12 μs difference is inaudible. Moving your head 4 mm makes a bigger difference.


Thanks for confirming. 12μs can be audible. IME, there is some inconsistencies when playing with delays for crosstalk. The real time cancellation and playing a preprocessed file directly still causes some difference in the soundstage which we are unable to pinpoint where it originates from. I am now thinking this is happening in the DAW which supposed to compensates all delays. 
 

BTW, how did you get half a sample delay?  

Link to comment
14 minutes ago, STC said:

12μs can be audible.

Maybe, under some carefully controlled conditions. If one channel has a constant 12 μs delay, it is equivalent to the listener being 4 mm closer to one speaker. That's not a problem unless you are this guy:

head-vise.gif.18c79d6db4b46b2e75ab2538ee92baf1.gif

 

18 minutes ago, STC said:

BTW, how did you get half a sample delay?  

Those early CD players had a single DAC serving both channels.

Link to comment
39 minutes ago, mansr said:

Maybe, under some carefully controlled conditions. If one channel has a constant 12 μs delay, it is equivalent to the listener being 4 mm closer to one speaker. That's not a problem unless you are this guy:

head-vise.gif.18c79d6db4b46b2e75ab2538ee92baf1.gif

 

Those early CD players had a single DAC serving both channels.


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?

Link to comment
33 minutes ago, Archimago said:

IMO, software like Fidelizer and JPlay are just silly:

http://archimago.blogspot.com/2015/08/measurements-audiophile-sound-and.html

 

 You are entitled to your own opinion, however many do not agree with you about them being just plain silly.(No, I don't use either)

 I would be surprised if you are even able to hear the differences between Audio files played from a PC's different storage medium, let alone the benefits of playing from System Memory, where JRiver reluctantly provided the option after numerous customer requests.

 

 

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

 

image.thumb.png.0551196544c37bbe57ecd340cb7d3c18.png

 

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.

 

image.thumb.png.e147e36b9459004a5e1ca0fb879eaf2d.png

 

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.

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
36 minutes 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?

 

There are plenty of DAC chips that have at least 2 channels - two complete, separate converter circuits in a single physical device.

 

2 hours ago, sandyk said:

 

In the meantime, quite a few members in another area of the forum are even reporting hearing differences between different types of RAM

 

 

Alex, if one goes about it carefully, it's quite easy to hear variations in SQ depending on CPU activity, hardware arrangement, and the settings - this cheapo Toshiba laptop I'm now using is fairly recent, but still the tonality varies depending upon what I do - shifting some of the circuitry outside of the plastic, like the DAC, makes some things worse, and some things better; it's all part of a flux, I'm afraid 😉.

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

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
6 minutes ago, fas42 said:

 

Alex, if one goes about it carefully, it's quite easy to hear variations in SQ depending on CPU activity, hardware arrangement, and the settings - this cheapo Toshiba laptop I'm now using is fairly recent, but still the tonality varies depending upon what I do - shifting some of the bits outside of the plastic, like the DAC, makes some things worse, and some things better; it's all part of a flux, I'm afraid 😉.

 

Yes, but you don't need to measure everything first before you listen to it or view it before deciding how it must look or sound , and for that matter neither does the OP of this thread normally, even though he is unable to hear differences with the CPU idling and under stress.

 

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 minutes ago, PeterSt said:

 

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

 

 

The "science" is that the DAC and following analogue circuitry should operate in as benign an electrical environment as one can organise - many a slip twixt the theory, and practice of achieving such.

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

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
2 minutes ago, PeterSt said:

Now listen to the difference with these both switch settings.

 Peter

  Expectation Bias is highly unlikely to let him hear these things, just like with Archimago and several others.¬¬

 He would need to go into another room behind a closed door, and have Mani repeat the exercise numerous times under NON sighted conditions while he performed the switching .

 

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
9 minutes ago, fas42 said:

 

Say, Dragonfly Red uses

 

 


Even PCM2704 as in the picture is a stereo DAC. Maybe I didn’t phrase the question correctly. 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. 

Link to comment
33 minutes ago, PeterSt said:

 

Wrong is a big word. Insufficiently detailed is another.

 

image.thumb.png.0551196544c37bbe57ecd340cb7d3c18.png

 

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.

 

image.thumb.png.e147e36b9459004a5e1ca0fb879eaf2d.png

 

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.

 

Peter,

 

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.

 

So let’s try to repeat your measurement results. If I have a DAC playing a tone at say -90dB and record the analog output using a quality 24 bit ADC (accurate to about -110dB). I’ll use a separate laptop to record the output of the ADC. 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?

 

 

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

 

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
32 minutes ago, STC said:


Even PCM2704 as in the picture is a stereo DAC. Maybe I didn’t phrase the question correctly. 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. 

 

The control circuitry which is part of the chip - which accepts, say, SPDIF as input - does all the necessary buffering, delaying and synchronising of the data, if it's serial - it ensures that the two channels of digital data are fed to the actual converters, to analogue, completely synchronously.

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