Jump to content
IGNORED

Bit perfect software changing sound. How?


Recommended Posts

Just now, manueljenkin said:

Yes it is phenomenal that the data storage access noise seems to pass through all these layers but if you consider the path, none of them have anything to compensate for the fluctuations, and as long as it is within thresholds of digital circuit operation it'll be passed through (but analog and mixed signal systems are picky). It indeed is profound that this distinct improvement is not buried within noise generated from the rest of the link.

You have not demonstrated this to be the case.

Link to comment
9 minutes ago, idiot_savant said:

You also have to consider how much *stuff* a CPU is doing when you're just looking at a static screen, and any extraneous noise added by reading a few megabytes of data will be swamped in this. I honestly don't doubt that you perceive a difference, but I equally honesly believe that if things were as "fairytale" as you are stating, we wouldn't be having this discussion because the internet wouldn't work

 

your friendly neighbourhood idiot

 

A PC motherboard ground plane is an absolute mess of noise currents that do not stop becuase you have fiddled with and reduced a few processes.

Link to comment
2 minutes ago, manueljenkin said:

I'll wait for more people to listen first, I have enough people who has heard difference, and one of them has a device with galvanic isolation.

Just listening is of no relevance in this objective thread.

 

Subjective evaluation is absolutely fine, but not what most audiophiles do, ie without any proper controls.

Link to comment
2 minutes ago, March Audio said:

A PC motherboard ground plane is an absolute mess of noise currents that do not stop becuase you have fiddled with and reduced a few processes.

Well that is nothing more than just your opinion. There are enough people who find an optimized pc to sound better than an Ethernet streamer or a galvanically isolated ddc.

Link to comment

But my point is even if we assume this noise is distinct enough from everything else to matter - it's *extremely* difficult to see how optimising a file could reduce this noise. Consider, for example, if you play the same file twice - it's not read from the file system twice, it will be read from the filesystem cache, *even* if the application doesn't explicitly buffer it. I'm also a bit confused about your "lower level language" assertion, could you elaborate?

 

 

 

your friendly neighbourhood idiot

 

 

Link to comment
10 minutes ago, idiot_savant said:

But my point is even if we assume this noise is distinct enough from everything else to matter - it's *extremely* difficult to see how optimising a file could reduce this noise. Consider, for example, if you play the same file twice - it's not read from the file system twice, it will be read from the filesystem cache, *even* if the application doesn't explicitly buffer it. I'm also a bit confused about your "lower level language" assertion, could you elaborate?

 

 

 

your friendly neighbourhood idiot

 

 

I'm not sure what's stopping you from playing the same file twice. To store it to RAM there will need to be an access at some point. 

 

There are softwares that have been written in assembler code, like this : https://www.igorware.com/small-player/download (this one is a little too old though, but there are similar approaches even today). There's more, that have been written in different approaches but the overall thing is the code that executes during playback is slimmer and necessitates less activity. Some use specific instruction sets in pc to reduce total number of accesses. Generic players are based on multiple layers of abstraction to make it work with all systems at the expense of proper optimization for specific capable systems.

Link to comment

And I think we've drifted onto two subjects, which are different:

 

(1)Can optimising a PC ( e.g. task scheduler, playback software etc ) affect e.g. RF, EMC that might conceivably affect a DAC

 

(2)Can we modify a file on the to enhance (1)?

 

Just to be clear, I can think of no way for (2) to happen if the *data* is identical on a modern OS - consider if our OS was running a deduplicating file system, where identical files are identified and only one copy is physically kept on the disk? Or a file on a NAS, where we absolutely have no control over it?

 

your friendly neighbourhood idiot

 

Link to comment
5 minutes ago, idiot_savant said:

And I think we've drifted onto two subjects, which are different:

 

(1)Can optimising a PC ( e.g. task scheduler, playback software etc ) affect e.g. RF, EMC that might conceivably affect a DAC

 

(2)Can we modify a file on the to enhance (1)?

 

Just to be clear, I can think of no way for (2) to happen if the *data* is identical on a modern OS - consider if our OS was running a deduplicating file system, where identical files are identified and only one copy is physically kept on the disk? Or a file on a NAS, where we absolutely have no control over it?

 

your friendly neighbourhood idiot

 

I don't think windows 10 does any data deduplication by default. Haven't seen any evidence of that on my system.

Link to comment

@manueljenkin - for playing the same file twice, is it equally optimised on the second playback is my point, as it will not have been read.

 

 

As for "fewer accesses" - to what? RAM? Disk? OS calls? Like I say, you have to realise how much stuff is happening *all* the time just to let you see a static screen. Are we really saying some *instructions" sound better than others?

 

 

your friendly neighbourhood idiot

 

Link to comment
23 minutes ago, manueljenkin said:

Well that is nothing more than just your opinion. There are enough people who find an optimized pc to sound better than an Ethernet streamer or a galvanically isolated ddc.

No, it's quite demonstrable.  Do you think a pc processes just stop while you are playing music?

 

What's not demonstrable is that the uncontrolled subjective views of random individuals is of any merit.

Link to comment
Just now, idiot_savant said:

@manueljenkin - for playing the same file twice, is it equally optimised on the second playback is my point, as it will not have been read.

 

 

As for "fewer accesses" - to what? RAM? Disk? OS calls? Like I say, you have to realise how much stuff is happening *all* the time just to let you see a static screen. Are we really saying some *instructions" sound better than others?

 

 

your friendly neighbourhood idiot

 

Yes. One less source of noise can help. And yes some instructions "can" sound better than others if we go by this. They definitely have different intrinsic noise and determinism patterns.

Link to comment

Also @idiot_savant you gotta understand something. I have tried it, and to me it brought in improvements so I'm searching to see how it truly works at a deeper level (I have a fair idea on the generic principles, but I like to explore further). The other guy seems to not hear any changes (I don't know if he has tried It properly but that's his own) so he's interested in "debunking" it with any abstraction he could. And I'm debunking his "abstractions".

 

However you're making speculations even without trying when it wouldn't cost you anything to try it. Not sure if refusing to try an easy task relevant to the discussion is part of the "objective" process.

Link to comment

@manueljenkin - right, this is the objective forum. If you're going to make these factual claims:

 

They definitely have different intrinsic noise and determinism patterns.

 

then I'm sure you can back them up? You do realise that in a modern CPU each x86 instruction doesn't really map into what a CPU does any more?

 

Does the optimisation work on an NTFS compressed drive, as supported natively by windows 10?

 

As for noise, consider the following:

a 4k framebuffer is 3840*2160*32 bits = 33MBytes. This has to be read from a framebuffer ( DDR local to a graphics card typically ) at 60 times a second. That's the equivalent of reading 3 CDs a second from DDR and shoving it out of an HDMI port.

And this generates less noise than choosing instructions apparently.

 

I'm the one giving numbers and facts, these aren't speculations. If you really want me to install a VM so I can install some potentially virus-ridden code, and use a debugger to try and find out what this thing does, then I'm afraid you might not like the results. After all, if it's really written in a low-level language, that should be pretty simple to prove

 

 

your friendly neighbourhood idiot

 

 

Link to comment
11 minutes ago, idiot_savant said:

@manueljenkin - right, this is the objective forum. If you're going to make these factual claims:

 

They definitely have different intrinsic noise and determinism patterns.

 

then I'm sure you can back them up? You do realise that in a modern CPU each x86 instruction doesn't really map into what a CPU does any more?

 

Does the optimisation work on an NTFS compressed drive, as supported natively by windows 10?

 

As for noise, consider the following:

a 4k framebuffer is 3840*2160*32 bits = 33MBytes. This has to be read from a framebuffer ( DDR local to a graphics card typically ) at 60 times a second. That's the equivalent of reading 3 CDs a second from DDR and shoving it out of an HDMI port.

And this generates less noise than choosing instructions apparently.

 

I'm the one giving numbers and facts, these aren't speculations. If you really want me to install a VM so I can install some potentially virus-ridden code, and use a debugger to try and find out what this thing does, then I'm afraid you might not like the results. After all, if it's really written in a low-level language, that should be pretty simple to prove

 

 

your friendly neighbourhood idiot

 

 

 

Talking generally there appears to be a massive mythology built up around all of this.  Noise caused by this, noise caused by that, noise caused by the other.

 

The described mechanisms are always nebulous without the slightest bit of evidence that demonstrates cause and effect, let alone showing the problems actually end up in the dac output.

 

 

Link to comment
38 minutes ago, idiot_savant said:

@manueljenkin 

You do realise that in a modern CPU each x86 instruction doesn't really map into what a CPU does any more?

Yes but it still doesn't mean two different codes get compiled to the same instruction sets.

 

38 minutes ago, idiot_savant said:

@manueljenkin 

As for noise, consider the following:

a 4k framebuffer is 3840*2160*32 bits = 33MBytes. This has to be read from a framebuffer ( DDR local to a graphics card typically ) at 60 times a second. That's the equivalent of reading 3 CDs a second from DDR and shoving it out of an HDMI port.

And this generates less noise than choosing instructions apparently.

I never said GPU displaying wallpaper produces "less noise" than music playback. And of course most of these tools do have modes to remove image displaying load on the cpuhttp://wtfplay-project.org this is a commandline os so not much to render there and when playing you don't even see cursor blinking so the image is static. Xxhighend comes with an unattended mode where only a static image is displayed and when the next song is played it will actually take time to update (likely generates images at that instant and loads to GPU memory). It would be naive to think cpu generates all pixels at every instant of time and loads into GPU memory for displaying 😅, then there is no purpose for a GPU (so your assertion of the noise you have mentioned is based on a speculation, not a fact). GPU has a parallel pipeline to generate these, has its own architecture that might have its own noise patterns (need not be as high as cpu for the same task) and send via hdmi port.

 

So we have less to no correlation here. Yes if you're using a normal desktop environment then yes there will be noise from GPU but even here the access noise is a separate thing with its own patterns. Do they influence each other? Very likely. Can one completely mask the differences of the other? May or may not be! So far my experience has shown the "may not be" case. But this is irrelevant for me since I use my players in unattended mode and above paragraph shows why your argument doesn't hold well.

Link to comment
29 minutes ago, idiot_savant said:

@manueljenkin 

I'm the one giving numbers and facts, these aren't speculations. If you really want me to install a VM so I can install some potentially virus-ridden code, and use a debugger to try and find out what this thing does, then I'm afraid you might not like the results. After all, if it's really written in a low-level language, that should be pretty simple to prove

 

Sorry, installing these on vm will also likely induce overhead and cause issues in analysis. The code hasn't caused any issues to my system but YMMV.

Link to comment
1 hour ago, idiot_savant said:

Consider, for example, if you play the same file twice - it's not read from the file system twice, it will be read from the filesystem cache, *even* if the application doesn't explicitly buffer it.

 

I.S., it could be a good idea to quote the text you respond to. For example, this could be addressed to me, but I am uncertain.

 

Consider, for example, that the disk file subsystem is eliminated as far as possible, by means of reading the file twice. Or triple. I could show you parts of the 250K+ lines of code snippets about this.

I can also assure you that if the physical file system does not exist as such because all is loaded from RAM (OS inclusive) then these things still matters because this is just how the OS works (your implying of layering).

And people in here wonder about how an SSD can still have influence ? I am just laughing.

 

Software like XXHE sounds better for countless reasons. And this most certainly will not imply that the author is held to explain the why's of it. Just leave it be. Don't buy it. Don't use it, whatever. But DO NOT start out with questioning in the negative ways March Audio does here. It is his freakin' 4th attempt because the threads are closed down he participates in, or he is banned from the other because of his sour shouting.

 

I suppose this will be my last post in here (huge threat's over my head).

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

Also @idiot_savant you gotta understand something. I have tried it, and to me it brought in improvements so I'm searching to see how it truly works at a deeper level (I have a fair idea on the generic principles, but I like to explore further). The other guy seems to not hear any changes (I don't know if he has tried It properly but that's his own) so he's interested in "debunking" it with any abstraction he could. And I'm debunking his "abstractions".

 

However you're making speculations even without trying when it wouldn't cost you anything to try it. Not sure if refusing to try an easy task relevant to the discussion is part of the "objective" process.

I have tried properly it and no you haven't debunked anything.

 

I have asked if you know the mechanism by which it could work and you have just replied with nebulous general speculations about "noise".  None of those speculations seem to provide any convincing explanation as to how these files are optimised.

 

PeterST claimed he used the same techniques in his software and therefore understood what was going on.  Yet when asked to explain he just became personally abusive.

 

So all we have are your subjective opinions.  Opinions which do not concur with mine.  Zero evidence to support anything beyond that. 

Link to comment

@manueljenkin - look, I understand - you've heard something, and have become interested in how that might have happened, read some stuff on the internet and so on. That's great! But you can't mistake that for actually knowing how stuff works.

HDMI is constantly running - so I'm not talking about generating frames, I'm saying even for a static image ( black even ), *something* has to store that image *somewhere* to transmit it over the HDMI wire. Now this amount of data (33MBytes)  has to be *continually* sent

 

Now, in a good PC with a separate GPU, that has it's own DDR that is being read, but in a more generic PC, that will have something like an APU that uses *the same DDR*. Now, internally, the frame buffer might be cached, but even you must see that having a 2Gbyte/s RAM access inside the same box as something having a 176kByte/s RAM access are orders of magnitude different?

 

You might claim there is no correlation, but how is reading a framebuffer to keep a static image less intensive than reading a buffer to provide audio to a DAC? This has *nothing* to do with how you create that image.

 

And you do know that your CPU is *constantly" accessing memory anyway, right, even if that is access is just to say "nothing to see here"? 

 

your friendly neighbourhood idiot

Link to comment
47 minutes ago, idiot_savant said:

then I'm sure you can back them up? You do realise that in a modern CPU each x86 instruction doesn't really map into what a CPU does any more?

 

What if ... what if our questioners in here would take it for granted that some of the others know a few things.

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
3 minutes ago, March Audio said:

PeterST claimed he used the same techniques in his software and therefore understood what was going on.  Yet when asked to explain he just became personally abusive.

 

When TF are you finally going to read ?

QUOTE ME.

And stop these nonsensical responses, mr TROLL.

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, vortecjr said:

Not according to measurements from Archimago posted here: Archimago's Musings: MEASUREMENTS: On the value for ethernet "galvanic isolation"...

 

According to the article, "Over the years, I have already demonstrated that ethernet works well as a means of digital audio data transmission. I have never found any differences in cables used, and sound quality is fine whether used locally or transmitted globally. But what about this issue of the possibility of electrical interference and the potential for improvement with galvanic isolation? Well, I think I can show what in practice successful galvanic isolation would look like at my home...

 

Remember this noise plot I showed a few weeks back when measuring the Raspberry Pi 3 + HiFiBerry DAC+ Pro run off a lithium battery?

Noise%2B-%2B60Hz%2Bcircled.png


Interesting don't you think that there's a 60Hz hum (red circle) even in the situation with the lithium ion battery (green) compared to when plugged into an AC adaptor (white)? Hmmmm, where does that come from given that the whole playback and measurement chain is run off batteries - the lithium battery in my laptop feeding the ADC, and the Duracell battery powering the Pi 3 and HiFiBerry DAC+ Pro board?

 

The answer was obvious. It was a very low amount of noise seeping in from the ethernet connection."

 

BTW the above is not a one off as John S. in this forum showed similar AC noise leakage over copper ethernet. He went a little further and showed when / why it happens and offered a remedy. You can read more about his measurements and solution to the issue here:

https://audiophilestyle.com/forums/topic/37034-smps-and-grounding/?tab=comments#comment-721414

 

Of course none of this is a concern with fiber optic ethernet that provide true 100% galvanic isolation.

That pick up can come in from many sources.  I'm afraid it doesn't indicate ineffective galvanic isolation.

 

The dac used in that measurement has a single ended output so CMR will be messed up even if you fed it into a balanced measurement adc.

 

Single ended connections are bad news in terms of signal integrity and noise rejection.

 

Also if cat 6 shielded cable is used and that shield is connected to the metal shell it will basically be a big antenna putting 60hz on the Pi ground plane. This will probably be connected to the RCA low.  Hence 60hz pick up.

Link to comment
35 minutes ago, manueljenkin said:

I never said GPU displaying wallpaper produces "less noise" than music playback.

 

The factor of CPU cycles used with the normal Windows GUI operative (DWM) is 

10,000

more than when using the most native canvas that I can find (and use in XXHighEnd).

 

40 minutes ago, manueljenkin said:

Xxhighend comes with an unattended mode where only a static image is displayed and when the next song is played it will actually take time to update (likely generates images at that instant and loads to GPU memory). It would be naive to think cpu generates all pixels at every instant of time and loads into GPU memory for displaying 😅, then there is no purpose for a GPU.

 

So still, I am afraid Yes. The CPU is involved largely.

Eliminating of such matters is always audible (for the better).

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
Guest
This topic is now closed to further replies.



×
×
  • Create New...