Bit perfect software changing sound. How?

[vortecjr]

From the batteries Archimago used and FYI John didn't use a DAC in his measurements;)  Disprove the two measurements and present your data or no one will accept your replay.

[manueljenkin]

35 minutes ago, idiot_savant said:

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

33Mbytes is once again your speculation. If you want to display just commandline texts in black and white I doubt you need more than 4 bits (or even 2) per pixel. Neither do they need to have the content at 4k resolution. So the total access size might be much smaller and GPU can upscale them both in color bit depth and resolution (otherwise I am not seeing much point of these devices begin SIMD to begin with). Also GPU should be accessing the RAM through its own dedicated DMA. All of this is assuming GPU doesn't have a cache or the cache is not used, otherwise, the scenario gets even easier

[PeterSt]

1 hour ago, idiot_savant said:

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

 

Should you work with NTFS compressed drives in audio ??

You take way too much for granted.

 

Your questions are fine, but they assume less knowledge than yours. This is dangerous.

 

So ... Should you work with NTFS compressed drives in audio ??

and if so why. If not, why not ?

No clue ?

prerequisites perhaps ?

OS depended (indeed) ?

Use a server version of the same ?

 

This thread goes nowhere because it is too much without sufficient real-life experience. So:

 

@vortecjr, Jesus, nice to see you !

[idiot_savant]

Erm,

 

I'm not talking about *updating* the screen.

*sigh*

So... Application->many,many layers of graphics stuff->framebuffer->HDMI

If you crash a PC, does the screen turn off? Or - maybe, just maybe the last thing the OS does is draw a blue screen in the framebuffer, that still needs to be sent by the GPU

 

your friendly neighbourhood idiot

 

[PeterSt]

1 hour ago, idiot_savant said:

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?

 

I see. You too are ready for XXHighEnd.

Want to bet ?

You have no single-idea how much all can be done, ONCE one thinks of it. You can and do too, right (because tempted or not). Well, go ahead. I won't bet you on not being able to do it (because you sure can and will with some stakes). Not with you. Not with a few others in this thread as well.

Whether you'd really do it, first requires some belief. Or a very graduate expansion of such features. And 1000s of ears because you can't do this alone.

 

See ?

[PeterSt]

3 minutes ago, idiot_savant said:

I'm not talking about *updating* the screen.

*sigh*

So... Application->many,many layers of graphics stuff->framebuffer->HDMI

If you crash a PC, does the screen turn off? Or - maybe, just maybe the last thing the OS does is draw a blue screen in the framebuffer, that still needs to be sent by the GPU

 

I am sorry, but it is again not clear who you address here (could be Manuel, could me me).

It is also not clear what you are "stating".

 

Nobody needs to refresh/update a screen because Mr Windows is doing this all the time for you.

No ?

[idiot_savant]

@PeterSt - I'm talking about the graphics card providing HDMI to the screen. Where is that image *stored*, and constantly *read from*

 

 

your friendly neighbourhood idiot

[March Audio]

58 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?

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.

Regarding smps yes they are a source of leakage currents through the Y caps.

 

The problem is that domestic hifi is still fixated on single ended rca interconnections.  Smps leakage currents end up in the ground and flowing through the rca signal low(shield).  Non issue in balanced.  The shield is a 3rd wire separate from the signal conductors and that's where the leakage currents harmlessly (mostly) end up flowing.

 

All Js is doing in that experiment is shunting the currents to ground through a different path to reduce that flowing in the audio circuit.  The effectiveness is dependant on the impedance of the various paths the currents can take.

 

This is not the solution.  The solution is to get the audio signal off the ground, ie not use single ended rca.

[PeterSt]

57 minutes ago, manueljenkin said:

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

 

No-way this will be possible. And you'd have instant poor sound of it.

(tried it all)

[PeterSt]

1 minute ago, idiot_savant said:

@PeterSt - I'm talking about the graphics card providing HDMI to the screen. Where is that image *stored*, and constantly *read from*

 

From the Video Card with mapping to normal memory.

But fyi: nobody is using physically attached monitors for audio playback. Unless, of course, you want poor sound.

 

How many context-changes to you want ?

oh uhh oops. Hahaha.

 

Let's start that subject. Task switching.

 

Come on, this is endless. Really. We only make ourselves steamed up. Or me y'all.

[PeterSt]

deleted

 

[idiot_savant]

Can people not do maths or read on this forum?

I'll do it again for @manueljenkin

Let's take a really low res screen, say 720p. HDMI *requires* 8 bit-per-channel sRGB as a *minimum*. So *each frame* is 1280 (width) * 720 ( height ) * 3 ( 24 bits/pixel ).

This gives us 2.7Mbytes/frame, of which there are 60 a second, giving us 165Mbytes/second, or over 900 times the bandwidth of CD-quality audio.

My 33Mbytes/frame was assuming 12-bits/channel, which is fairly common.

It doesn't matter what you *show* - be it a command line, a blank screen etc. there is a framebuffer that is *written to* by the CPU/GPU and *read by* a constantly running frambuffer->HDMI bit of hardware. I'll repeat. How can adding or removing a few instructions come close to a 900x bandwidth increase ( at a minimum )

 

This is *not* speculation, this is actual sums done on actual specs.

 

@PeterSt - so now I'm not allowed to use a screen?

 

your friendly neighbourhood idiot

 

 

 

[PeterSt]

8 minutes ago, idiot_savant said:

I'm talking about the graphics card providing HDMI to the screen. Where is that image *stored*, and constantly *read from*

 

Highlight the text and click Quote Selection. Now I quoted you ...

 

[idiot_savant]

7 minutes ago, PeterSt said:

How many context-changes to you want ?

oh uhh oops. Hahaha.

 

Let's start that subject. Task switching.

There are no context changes or task switching involved in a GPU ( or CPU ) reading a framebuffer to generate HDMI

 

happy?

 

your friendly neighbourhood idiot

[March Audio]

8 minutes ago, PeterSt said:

 

From the Video Card with mapping to normal memory.

But fyi: nobody is using physically attached monitors for audio playback. Unless, of course, you want poor sound.

 

How many context-changes to you want ?

oh uhh oops. Hahaha.

 

Let's start that subject. Task switching.

 

Come on, this is endless. Really. We only make ourselves steamed up. Or me y'all.

What utter nonsense.  Is this like the "no one uses SSDs because they sound awful" comment you made the other day?

[PeterSt]

2 minutes ago, idiot_savant said:

 

@PeterSt - so now I'm not allowed to use a screen?

 

 

For the better SQ ?
no.

As a matter of fact, the more modern playback systems always use two PC's. One of them headless.

That better playback system does not have anything in the audio paying PC. Only a CPU and memory and an Ethernet connection to the Music somewhere plus for RDC. And RAM. Nothing else.

OS from RAM.

[idiot_savant]

2 minutes ago, PeterSt said:

OS from RAM

 

But I thought accessing RAM was noisy?

 

 

your friendly neighbourhood idiot

[PeterSt]

2 minutes ago, idiot_savant said:

There are no context changes or task switching involved in a GPU ( or CPU ) reading a framebuffer to generate HDMI

 

happy?

 

I put yet another context to "prerequisites". Not your fault that you didn't get that one.

But next I hopped to the subject of Task Switching.

 

Already did some counts on your modern OS ? I say : 16 million per second on a 20 core. Doing not-thing.

Now try XXHighEnd in MinOS mode while playing. 160,000.

Something has to be doing this. Oh, this is not important. But what is important is that this is totally full with the sh*t we try to work out here. Impossible.

Still true.

 

Try it for your own system and see whether I may have the numbers right. Btw, it is allowed to use a screen. Haha (back at the time I did too).

[PeterSt]

1 minute ago, idiot_savant said:

But I thought accessing RAM was noisy?

 

Not my words.

Accessing the wrong RAM is noisy (ECC).

 

But if you know a means to avoid RAM, tell me by PM please. It would be a huge secret I would like to keep among us.

😁

[PeterSt]

5 minutes ago, March Audio said:

What utter nonsense.  Is this like the "no one uses SSDs because they sound awful" comment you made the other day?

 

Oh, him again.

I had hoped you were gone.

 

Btw, Yes indeed mr know-it-all.

[manueljenkin]

2 minutes ago, PeterSt said:

 

Not my words.

Accessing the wrong RAM is noisy (ECC).

 

But if you know a means to avoid RAM, tell me by PM please. It would be a huge secret I would like to keep among us.

😁

Don't leak the secret I told you 😜.

[idiot_savant]

Well, I'm not the one saying RAM is noisy.

 

I'm just the one confused about how some kinds of access are noisier than others

 

 

 

your friendly neighbourhood idiot

 

 

 

[March Audio]

37 minutes ago, vortecjr said:

From the batteries Archimago used and FYI John didn't use a DAC in his measurements;)  Disprove the two measurements and present your data or no one will accept your replay.

Sorry I don't understand what you mean regarding the batteries.

 

I have provided a clear explanation regarding 60Hz pickup there.

 

 Please refer to my comments above regarding Johns post.  His measurement technique is irrelevant to that issue.

[March Audio]

7 minutes ago, PeterSt said:

 

Oh, him again.

I had hoped you were gone.

 

Btw, Yes indeed mr know-it-all.

Got any evidence to back up either claim?

[manueljenkin]

1 minute ago, March Audio said:

Got any evidence to back up either claim?

Claim?