EtherREGEN on the way!

[Puma Cat]

Originally Posted by Cohibaman

Again, not trying to dispute anything here; I’m trying to understand.

Yep, no worries, Mike.

My ER's been here over a week now, and I am very impressed with the audible benefits it brings to the presentation: a notably quieter noise floor, more open, extended highs, and improved "spaciousness" or "spatiality", image and voice placement, and improved inner detail, microdynamics. The subtle timbres and instrumental shadings coming off of instruments is more apparent and more natural-sounding. There's a more apparent interplay of subtle instrumental and vocal cues, e.g. hearing the secondary reflection of Kenny Burrell's guitar off the opposite wall in the recording studio, as mentioned above.

ER lets me play the system both louder AND quieter and have a more engaging experience.

[doggiehowser]

The way I see it, the difference between file transfer on a PC and sending a music file is timing.

With a PC, there is no "time critical" component. The bits arrive and at the receiving end, the parity bits are checked and given time to reconstitute the errors so you get back the original file. You can also get the handshaking to resend the file.

With music transmission, the errors can still be corrected in real time, but there is processor load involved in error correction.

Two separate companies have come to the same conclusion over the years.

One was Pure Music. In one of their earliest incarnations, the developer spent a tonne of time working through the algorihm to reduce processor load spikes. Less processor load, better sound quality. Subsequently, it all became bug fixes to work with the latest version of Mac OS so that optimization seemed to be lost. So for years, reviewers swore by a particular build/version of Pure Music and stuck to the old MacOS.

The second was the designer of ESS Labs. He said when he measured steady state results, he had the best measurements but when he got hifi designers to use his earlier designs they hated it. He said in collaboration with a few key designers, he went to discover that in his DAC design, which were state machines, it mattered less how fast they reached the steady state, but how little power fluctuated between the different states.

Those small power fluctuations seemed to affect the overall quality of the DAC.

I've found similar results in the past with an iPOD playing back AIFF/WAV vs ALAC on a Wadia iTransport.

[Puma Cat]

Originally Posted by doggiehowser

The way I see it, the difference between file transfer on a PC and sending a music file is timing.

This is exactly right.

For computing applications, e.g., sending a file to a printer, timing has no impact on the quality of the (discrete) output.

In audio applications where the file is continuously being streamed AND femtosecond differences in timing are audible, noise factors e.g. phase noise are critical in how they impact the quality of the reproduction.

[Cohibaman]

Originally Posted by Puma Cat

This is exactly right.



For computing applications, e.g., sending a file to a printer, timing has no impact on the quality of the (discrete) output.



In audio applications where the file is continuously being streamed AND femtosecond differences in timing are audible, noise factors e.g. phase noise are critical in how they impact the quality of the reproduction.

And this I fully understand and agree with, i.e., my PC feeding my DAC, where timing IS everything and what’s more, there’s no error correction. A clear case, for me anyway, where a cable does matter. Hence purchasing the AQ Diamond USB from you.

It’s the transfer of a “file” from the NAS to my PC that I struggle with the need for any specialized “audio” hardware or cables.

If what they are claiming is true (aside from streaming), all of my “files” on the local SSD of my PC are flawed, since the transfer was made over non-audio grade hardware. That doesn’t compute (pun intended).

Another case in point, all of the Hi-Rez files coming from HDTracks would suffer from degradation because nowhere in the whole chain, from their source of the files, the download to my other PC via the Internet, the transfer to the NAS, then finally to my media PC, is an “audio” grade device.

What am I not understanding?

[doggiehowser]

the copying of the file to an SSD doesn't require real time - errors can be corrected on the receiving end by reconstructing based on parity/error correcting bits. so you get perfect copies.

sending of the music in real time - if there are errors and need to be corrected in real time, the computing load is different than if the signal was intact and in time (which is what cables and products like reclockers try to do)

[IM3CPO]

You guys are confusing apples and oranges here. The biggest thing you need to keep in mind is that the network connections in the case being discussed is **ETHERNET** which uses "Frames" as its payload. The protocol you are using (TCP-IP in this case) is encapsulated inside these Ethernet frames. TCP-IP has several things going on, but the "TCP" of TCP-IP stands for Transmission Control Protocol. TCP is what handles the error checking at the APPLICATION layer between the hosts talking on the network. The TCP header will not only contain the checksum used to ensure what was sent it what was received, but it also has contains a SEQUENCE NUMBER. Why is that? Because you can (and most certainly do) have MORE THAN ONE TCP-IP packet inside one Ethernet Frame... and TCP-IP packets **ARE NOT SENT IN ORDER**.... There are send and receive buffers that are used to deconstruct and reconstruct the data before and after its transmitted. Ethernet based TCP-IP Network connections ARE NOT SERIAL CONNECTIONS! There *is* such a thing as synchronous Ethernet but computer networks DO NOT USE IT...

Components like hard drives, SSD's, printers, USB, etc., do not use Ethernet nor do they use TCP-IP. These devices are in no meaningful way (in this specific topic) comparable to streaming or sending files over Ethernet networks.

Also wanted to quickly add that my intent of using caps is just to add emphasis; not to imply I am yelling.

If these EtherREGEN switches do make a positive impact in audio quality, there literally is no way for it to do so at the TCP-IP packet level (the error correction actually proves this to be impossible; the checksums would never match if it made any change at all). If there is an error at the Ethernet frame level, you simply wont have any connection at all.

In closing, it is theoretically possible the EtherREGEN cleans up stray electrical on the line that could interfere with the internal operation of the receiving device. The odds of you being able to measure this impact to the output signal you are listening to though is going to be near impossible.

[Cohibaman]

Thanks gentlemen. This has definitely been educational.

Stephen, I’m sorry if this evolved and wound up derailing your initial thread just to get it through my thick head.

[Puma Cat]

Originally Posted by IM3CPO

If these EtherREGEN switches do make a positive impact in audio quality, there literally is no way for it to do so at the TCP-IP packet level (the error correction actually proves this to be impossible; the checksums would never match if it made any change at all). If there is an error at the Ethernet frame level, you simply wont have any connection at all.

In closing, it is theoretically possible the EtherREGEN cleans up stray electrical on the line that could interfere with the internal operation of the receiving device. The odds of you being able to measure this impact to the output signal you are listening to though is going to be near impossible.

As mentioned before, the "noise" factors that impact audio quality for music file streaming are not at the TCP-IP packet level.

And, as I've mentioned above (numerous times), I'm going to defer to John Swenson's white paper, in which he is planning to include measurement data.

Lastly, no one's arm is being twisted here to buy an EtherREGEN. If some folks don't think, or can't hear, the improvements that Ethernet cables and/or switches have an audible impact on the sound quality and presentation in a digital streaming front-end, that's great, because that means those folks can put those discretionary funds towards something that they feel would provide more benefit to their systems.

I'm just sharing my honest experiences and listening impressions here; folks that know me know I don't suffer from confirmation or ascertainment bias, if a component or device brings no audible improvement to an audio system, I'll say so. For example, my local brick and mortar store sold me a bill of goods when they sold me an Audioquest Carbon Firewire cable for connecting my music-containing hard drive to my music server computer. Couldn't tell ANY difference in using that cable at all; it was a waste of >$100. Nor did I hear any difference using the Furutech Flux-50 power cable thingy that sells for ~$1200. Zip, nada, niente.

I have to admit I wish I couldn't hear the improvements using devices e.g. FMCs, Ethernet cables, Ethernet switches, as well as the incredible amount of crap arising from switch-mode power supplies, because its just more stuff I have to buy that I quite honestly wish I didn't have to buy. I could put those discretionary spending funds into music, other components, another Shunyata NR power cord (which I need and pays BIG dividends), or going to a concert.

But, the facts are...I CAN.

I can't tell folks that they'll hear an improvement using an EtherREGEN or not. Digital streaming configurations that utilize "hard" Ethernet connections are so complex and multi-varied its impossible to predict, especially in the context of the multitude of systems folks use after the network bridge/streamer in the amplification chain.

If folks are interested, or think that they'd like to try it out, they can buy an ER for all of $640 + ~$9 for shipping and try one out in their own system. This is plenty of time for the ER to fully burn in and come up to optimal performance. If they don't like or it or feel it provides no benefit, they can return within 30 days for a full refund, no questions asked. You're out maybe twenty bucks in shipping costs to find out. That's way less than a rental from a cable company lending library.

[IM3CPO]

@ Puma Cat

Just wanted to let you know that I am not at odds with you. I was merely reading several people confusing numerous different subjects and I was trying to add some clarity by providing information. As I too have said at least three times, I have no problem with people who claim these work in their systems. I provided the information on the Ethernet frames and protocol because there were posts from people thinking differences were being made at this level.

I can hear differences in some system tweaks that dont entirely make any sense either (Stillponts and HRS products for example). Not all variables are known, so its possible an unknown variable is affected in a positive way from using an EtherREGEN. But there is also no way to measure something you dont know..

To me, there is nothing wrong with being skeptical. But dont take that skepticism as me disagreeing with your conclusions.

[W9TR]

I really like the fact that people are weighing in with a lot of very useful information on the subject of improving Ethernet audio performance. I am pretty familiar with Switched Ethernet and know that there are a lot of mechanisms at work at the PHY level that can and do impact audio performance completely apart from the Datalink and Transport layers. I am still working on the AC power for my system. Once I get that sorted Ethernet will be next and these discussions are helpful.
Tom