Expensive Ethernet?

Audio Science
21

They surely can make a difference. I certainly believe in silver vs. copper cables. I have personal experience with terrible USB and RCA cables. I returned an ultra-thick power cable for being too stiff and for sounding dead (it’s the last 3 feet after 1,000 feet from the relay station and XXX miles from the power generation plant). One of my CD players worked fine with only one cable, and had channel imbalance with every other cable I tried. I also noted bad experiences with Ethernet products too (above).

I don’t know that there’s anything here to disagree about – anything can have a potential impact. If one seeks to persuade the greatest number of people (especially critics) one must use valid tests. These must be perceptually valid tests rather than electrical measurement “objectivity” that’s also presumptive in its own way.

Measurable physical properties + highly predictable human characteristics + immediate human functioning by a given person affect the perceived impact.

3 Likes
22

I have always, and will always, insist that if you hear a difference then it makes a difference. Don’t let anyone ever tell you otherwise. Sound is literally objectively half in our heads. “Wiggly air” without a brain to interpret it as “sound” is just wind.

I do not dispute that there may be a difference between ethernet vs wired as the hardware and the transmission method are both different. Any difference makes a difference.

I do not, however, believe that a fancy “audiophile router” makes any audible difference in an audio chain. Bits are bits, they don’t sound like anything until they reach a DAC at minimum, and unless there is something very wrong with your network the DAC gets the same bits from a $15 radio shack router as it does from a $5000 “audiophile” router.

Unless you think otherwise. In which case I am super happy for you! Seriously. :wink:

4 Likes
23

If bits are bits then why would a streamer make a difference? Or a DDC? Both are before the DAC.

2 Likes
24

I don’t believe they do. Nor do I believe CD is audibly “better” than streaming. THAT SAID, I have not personally done this testing with my own ears, so I retain a shred of admitted uncertainty.

*edit: if your DAC does not have galvanically isolated USB input then it makes perfect sense why a streamer would provide a cleaner signal than PC USB. If your DAC has a galvanically isolated USB input, then again I do not believe it makes any difference.

3 Likes
25

Do we KNOW that they send the same bits to the DAC?

1 Like
26

The vast majority run open source software, so we can assume they don’t change the bits.
Some of the very expensive ones run their own software stack, and some do resample, but it’s unusual.
Streamers you have to be careful to specify how the signal is transmitted to the DAC, if it’s AES or SPDIF, it’s providing the clock and it’s easy to understand how that can impact the sound.

But for example I think the Optical Rendu is obviously better sounding than the Ultra Rendu, both use USB to connect to the DAC, so they aren’t providing the clock.

Of course that’s all based on personal observation.

1 Like
27

Just keep using a PC if you can’t hear the difference. Doesn’t matter to me.

Some can’t tell the difference between tubes, cables, etc., so do what makes you feel better.

1 Like
28

Chord’s DACs are “galvanically isolated”, and my DDC made a massive (audiophile massive) difference, but, like, anyone would notice on a reasonably transparent system. Again, it’s not just bits. Bits are transferred via an analogue signal that represents bits, and I don’t dispute that the bit representations almost always arrive perfectly, but it’s about the other junk that rides along with the analogue signal carrying the bits.

Not all galvanic isolation is perfect (even Rob Watts has said as much to me), and digital cables and sources absolutely matter. It may matter more or less for a given system, but the changes can be quite obvious in some setups. I have heard that the Holo DACs have an exceptionally good USB implementation, so it may matter less for you.

Anyway, I don’t think most people are making a bits perfection argument for the audiophile routers. Some are, but I agree that’s demonstrably disprovable.

It took me a minute to dig up, but Hans Beekhuyzen has an excellent, well-researched video on the topic. I generally agree with his philosophy, as he is listening first, measurements second, but is very knowledgeable about the technical aspects of the audio chain. He actually worked with a fellow enthusiast, and they seemed to be able to show an objectively measurable difference in jitter and phase noise with and without a network filter. I will reiterate that I have also heard a difference with a much less advanced network filter.

I don’t have a CD transport, but I was extremely annoyed to find that local files sound noticeably better than the exact same streamed file. It’s not huge, but it’s enough that I now buy and download my favorite albums to store directly on my NUC.

So, to sum up, I’m on team “bits arrive fully in tact, and most are re-clocked at the DAC”, but I think that is not the full story, and is missing a massively important factor - signal contamination that moves through the chain and causes (minor) distortions in downstream equipment that are audible.

4 Likes
29

It is very good ime, but I did try the spring with an auralic streamer back then and it was a meaningful improvement over the PC (using same cable). Also worth noting I did not use a generic USB cable.

4 Likes
30

These cable related audiophilia is not the devil, but in most cases not the right answer too.

The ethernet/USB data transfer has at least two critical parts from the audio perspective: asynchronous transfer and electrical noise.

  1. If the endpoint does not have proper reclocking
  2. or/and at the analog side of the DAC not isolated well from the parasitic electrical noises (from the network or the power connections)

Both things are weak design. The only good thing is these type of connections has less neuralgic points than the older ones.

Yes there is a chance, if you use other gadgets to hide these weaknesses in your system, you get better audible output. And maybe it is a cheaper solution than buy a new server/dac/stramer with proper design.

1 Like
31

As a software developer I want to see this as just transferring data from one place to another and the receiving device does whatever it needs to do.

I’ve never been able to find an explanation of why dacs can’t buffer the incomming data thus solving all transport issues.

But here we are decades after digital audio came into mass use (CD’s) and still it’s somehow a mysterious/unsolvable problem to get data into a dac.

3 Likes
32

USB based inputs do, modern USB audio is asynchronous, the OG standard wasn’t.

For SPDIF/AES the DAC designer has a choice, they can reconstruct the clock from the incoming stream, or they can “buffer” it and create a new clock, the issue is if that clock drifts relative to the incoming clock you have bigger issues. Reconstruction of the clock from the AES/SPDIF source can be done entirely in hardware.
Most devices just reconstruct the incoming clock and sometimes clean it up using a PLL.

Depending on what you paid for your DAC/Streamer the quality of the clock can vary quite a lot, a lot of manufacturers just use off the shelf hardware for USB, the JLSounds boards are considered the best of the XMos based solutions, but even among those the board isn’t always used the same way, and some manufacturers will use higher quality clocks.

It’s not really the issue, the issue is how clean the clock pulse is at the point the signal becomes analog. Clocks are just analog transmission lines with a threshold, any noise riding on the line moves that transmission forwards or backwards in time, that’s jitter.
It’s one of those things no one expected to be audible, and was actually discovered to have an audible effect after CD was released, I think Cambridge audio originally identified it, when it because apparent that physically better built transports resulted in better perceived quality, even though it was all digital.

The problem is nothing is entirely electrically isolated from anything, and if some part of that noise makes it into the device doing the conversion, and the device can’t remove it, you increase jitter, a lot of that noise will be caused by the device itself but some of it can creep in through various other electrical connections.
I saw a video of someone measuring jitter at the clock pin on an old R2R chip based DAC, and demonstrating that upstream gear changes directly impacted the jitter.

3 Likes
33

Thanks for the info.

I guess I’m just being dense about this.

Are you saying the “input” is not just data, but data and a clock?

So even if transferrring the data has been solved there is still the issue of the receiving device adding the clock? So some dacs are better at getting the clock right than others?

Do CD’s have clock information on them or just data? I’ve always thought they just have data since the sample rate is known.

1 Like
34

Right but in an old style physical transport, the data is streamed off the disk at the clocked rate, there is probably buffer in their somewhere at least latching it. The new Schiit transport doesn’t work like that it plays a CD like a computer would, reads the data into a buffer then plays it.
The advantage of simpler hardware in this case is it’s less likely to introduce noise.
Analog electronics (in which I include digital board layout) is just messy, you run two wires on a board close to each other, and one will pick up part of the signal in the other, if it’s a figital signalm that’s cleaned up in the interpretation, but if one of them caries a clock it introduces jitter. Having things like a CPU on the board mean you have very high frequency signals flying around that will also result in RF interference.

Something at some point provides a clock for the output, with AES/SPDIF/I2S, the data is sent at the playback clock rate, so the receiver has to be careful introducing it’s own clock, because if they drift relative to each other you’ll get dropouts. The way this is resolved is using a PLL which is in effect a filter in the time domain.
Modern USB doesn’t work quite like that.

3 Likes
35

Thanks again for the reply. I’ll be thinking and researching and maybe the bulb will finally turn on.

1 Like
36

My explanation for this is that the first generation of CD players (mid 1980s) used gravity to keep the discs in place. They tended to flutter and skip, and struggle to speed up or slow down as the discs skidded on the spindle. The first few tracks (inside edges) were much more likely to skip, while the outer edges tended to flutter. Vendors started selling disc stick-on ring weights and heavy pads, but these sometimes made it worse because of the added momentum.

I recall shock in the early 1990s when dirt cheap (e.g., Mitsumi) PC CD-ROM players (proto transports) often outperformed expensive dedicated audio players – they used a top weight to clamp the disc in place. It made them usable in a vertical orientation, and solved the worst of the physical playback problems too.

2 Likes
37

Just data. The clock comes from elsewhere and, in the case of S/PDIF, gets combined with the data via Differential Manchester encoding (aka “biphase mark code”). The datastream sent over the cable (copper or fiber) is thus self-synchronizing.

USB sends the data via a different protocol.

CD-ROM also stores data differently than CD. CD is the red book (IEC 60908) and CD-ROM is the yellow one (ISO/IEC 10149).

None of which has anything to do with the way ethernet or wifi may impact sound quality.

4 Likes
38

CD ROM players played audio CDs in the original format too.

1 Like
39

Some fun facts, picking from various posts.

CD Players:

  • A few, very early, CD-players extracted the sample clock from the servo encoding in the CD’s data track, rather than using an oscillator or crystal to generate it.

  • Most early CD players only had single-channel DACs, which were duplexed (convert sample 1 for the left channel, then sample 1 for the right channel), which resulted in an 11.2µS delay on the right channel.

  • Most early CD players only had 14-bit converters (which sometimes couldn’t achieve 14 real bits of dynamic range at their outputs).

Local vs. Streamed Content:

The most common reasons for local files/CD rips sounding different from streamed files:

  • The streamed file is a different version/mastering of the track.

    This is easy to test … you just need to do a bit-level capture of the streamed file and compare it to the sample data in the local/ripped file. Very common for what the metadata might suggest is the same mastering NOT to be. Lost count of how many variations of “Graceland” (Paul Simon) masterings I’ve seen.

  • CD had pre-emphasis enabled, and the ripper didn’t handle it (very common with early rippers).

  • The streamed file is watermarked (much less common anymore).

DACs & Clocks:

  • Excepting on S/PDIF, ADAT and AES3 inputs, 99.9% of DACs drive the sample clock from an onboard clock (or clocks) located as close to the DAC chips as possible.

  • 100% of USB 2.0/UAC 2 DACs buffer the USB input and clock it out of the buffer using their own clock (as above).

  • External clocks are often less accurate (phase noise, beat error) than on-board clocks. They are also routinely misapplied. External word-clocks are generally (and originally) used to discipline and synchronize multiple DACs so they stay in sync over a protracted period, rather than apply more precise local clocking for an individual DAC.

10 Likes
40

Ha! Gotta remember that one.

1 Like