Innuos Zenith Mk3 or OpticalRendu + separate server?

[Nenon]

I was just about to agree with everything you said and then I read this:

 

36 minutes ago, barrows said:

What is certain, is that an optical connection does not have any compromises

 

Are you really saying that an optical connection does not have ANY compromises?!? Okay, even if "an optical connection" (whatever you mean by that) does not, its implementation definitely does. 

I have added media convertors to my network and they killed the dynamics and made my system sound lean. 

I have also added different media converters and powered them with LPS1.2 (charged by a very good LPS) and they brought a lot of joy in my system. I then replaced all caps on those media convertors with high quality ones, and that brought the SQ up another notch. 

Then I added a JCAT Femto Net card and a SOTM switch connected via copper. At that point my system sounded better than the optical connection without the JCAT and SOTM. I can keep going with examples but that's not the point.

So again, it depends on the implementation. If I was a betting man, I would bet that the WiFi solution Blackmorec implemented with SJ power supplies sounds better than my first optical solution. 

[barrows]

13 minutes ago, Nenon said:

Are you really saying that an optical connection does not have ANY compromises?

YES, I am, or to be, perhaps, more precise, an optical connection is the LEAST compromised solution.  But, as your experience suggests, how one implements an optical solution can make a difference.  For example, your problems could have been due to the FMCs you used, or what power supply you used on the downstream FMC, etc.  When one uses an optical connection, the downstream device which converts from optical to electrical needs to be as well designed as your JCAT NIC (hopefully) is.  An OTS FMC is going to compromise things.

Some folks have suggested that the clocks all need to be high quality, your JCAT NIC has high quality clocks if I remember correctly...  At the very least you want the downstream FMC (or DAC/Renderer with optical input) to have high quality clock(s).  It may also still be an advantage to have high quality upstream clock(s)  

 

[Nenon]

Let’s address the elephant in the room first. The obvious compromise in optical solutions is the optical to electrical conversion. That is not something you need to do if you don’t use optical. It’s another stage your data needs to go through, so it’s obviously a compromise. Yes, you do it to address other issues (i.e. to isolate the upstream electrical noise), but what that means Is that you are willing to compromise by adding another stage for your data, so that you can solve a problem assuming the overall end result would be better. And it probably would be better (if implemented properly), and I am not arguing about that. Every designer knows that compromises exist in every design. There are “cost no object” products, but even the designers of such products have to do compromises.  

 

Having said that, I would agree with the “LEAST compromised solution”. If implemented right, it would probably be better than copper or Wifi+copper.

 

My first optical solution was fed by LPS2.1 and sBooster, and it did not sound good. And yes - clocks, power supplies, vibration control, cables, etc. it all matters in a good resolving system. Waiting to see the $1000+ audiophile optical cables on the market soon :).

 

Sorry if we went offtopic. 

[barrows]

4 minutes ago, Nenon said:

so it’s obviously a compromise

I would suggest that no one, ever, has provided ANY evidence of this.  Provide some evidence, or stop suggesting things are "obvious".

 

Again: Optical transmission is the gold standard for high speed data.

 

Do some research on Optical Ethernet transmission from non-audiophile sources and perhaps learn something before suggesting things are "obvious".  Before I considered actually using optical Ethernet I did a few hours of research from non-audiophile sources on the advantages of optical data transmission, there is plenty of technical information out there.

[Nenon]

OMG, someone is convinced he found a design with no compromises! With such attitude toward designs, I am starting to get an idea why I could never get my ultraRendu to sound good in my system, regardless of the power supplies (LPS1.2, sBooster, SJ DC3, etc) and reference level power and USB cables I used. 

 

For the record, I manage the datacenters of a global company. Ultra low latency local networks with 100 Gbps backbone dark fibers and thousands of servers with multiple 40 Gbps NICs is what I do for living. That’s my daily job, so I don’t need to do “research on Optical Ethernet transmission from non-audiophile sources”. And guess what… when you live at the edge of the technology, and every nanosecond of latency matters, you don’t use fiber transceivers!

 

Done with this pointless discussion. 

[Blackmorec]

4 hours ago, Summit said:

 

Don’t take this the wrong way, but if wi-fi brought you massive improvement over wired LAN it likely mean that you have some weird thing going on upstream, I believe.

How very perceptive of you! I actually did have a weird thing going on upstream. It was called a Virgin Superhub router. Not the best router around by any stretch and certainly not when powered by its little Chinese power brick. My first evaluation compared direct ethernet cable between Superhub and AQVox vs a TPLink RE650 extender dedicated to the router’s 5GHz band on the receiver end and  to an ethernet output to the AQVox, with no wi-fi clients on the output side and the 2.4GHz band switched off.  Getting rid of the power brick brought enhancements, adding a new TPLink Archer AC5400 router and demoting the Superhub to a modem function brought improvements. Adding a better internet cable between modem and router brought improvements, as did placing the TPLink Router on an Atacama mini-rack. 

[Blackmorec]

4 hours ago, barrows said:

The reason to use an isolated approach to Networked audio is that it renders what is going on upstream, in terms of noisy commercial computer gear, a non-issue (whether copper Ethernet wire, optical based isolation, or WiFi)-this is a good thing, as upstream tweaks become unnecessary and make no difference (for the most part).

This is simply not correct. With wi-fi in place and functioning flawlessly, you could still clearly hear the improvements brought by better routers, placing the router on an anti-vibration platform, implementing superior ethernet cables and improving the power supply to modem and router.  My conclusion would be that electrical noise transmitted along ethernet cables is not the only issue/parameter affecting sound  quality. Believing this will bog you down with an inferior front end that will impact your final sound regardless of the isolation employed. 

[Superdad]

I think you gents are all arguing about how to dress up the rear end of the horse.  

We expect you’ll get to see its face—and the rear will mostly cease to matter—once EtherREGEN ships.  

True data, power, and clock isolation—that’s what the endpoint wants.  The impenetrable moat.  

[Nenon]

We truly hope so! Can't wait to try the EtherREGEN. Stop teasing us and get it out

[Nenon]

By the way, there were many claims before that the rear end did not matter. It was the USB DACs with galvanic isolation - with those, the USB output and USB cables were not supposed to matter. But it did. Then it was the last clock in the chain. But it turned out the clocks before also mattered. And so on...

I am yet to see/hear a device that is completely immune to upstream jitter/noise. Until then I am skeptical.

Regardless of that, I would be online at 9 am the day you release the etherregen to try to order one. Or two.

[barrows]

1 hour ago, Nenon said:

OMG, someone is convinced he found a design with no compromises!

I never said any such thing.  I did not find any design with no compromises...  what I said was that, quote:

 

"YES, I am, or to be, perhaps, more precise, an optical connection is the LEAST compromised solution."

 

This is about an optical connection for high speed data transmission, not about any specific product or design.

 

 

[barrows]

27 minutes ago, Superdad said:

I think you gents are all arguing about how to dress up the rear end of the horse.  

We expect you’ll get to see its face—and the rear will mostly cease to matter—once EtherREGEN ships.  

True data, power, and clock isolation—that’s what the endpoint wants.  The impenetrable moat.  

Alex:  Are you suggesting that a moat a few centimeters wide would provide more noise isolation than 20' of optical cable?  To be clear, I suspect the EtherRegen will be a fine product and in no way am I interested in making any kind of criticism of what it can do, but I am curious that you appear to be suggesting that an optical connection will still allow electrical noise (not referring to clock inaccuracies, phase noise here) to get to the endpoint? 

[barrows]

47 minutes ago, Blackmorec said:

My conclusion would be that electrical noise transmitted along ethernet cables is not the only issue/parameter affecting sound  quality

I have asked this question before, but statements like this require that it be asked again:

 

What mechanism/parameter, do you suppose, is at work which improves your sound quality, within the context of a galvanically isolated Network connection (WiFi or optical), when you, for instance, place your router on a vibration control platform?  I am not trying to be smart here, i am honestly curious.  So far I have never heard a single, even highly speculative, theory on how things like this could possibly make a difference in sound quality.  @Nenon, as you appear to be an expert in Networking, I am interested in your take on this as well: "when every nanosecond matters" do you pay attention to vibration control of Network hardware?

 

As a secondary question: If vibration control of every switch or router in the chain makes a significant difference, what does this mean for music files distributed streamed from sources like Tidal and Qobuz? 

[Blackmorec]

35 minutes ago, barrows said:

I have asked this question before, but statements like this require that it be asked again:

 

What mechanism/parameter, do you suppose, is at work which improves your sound quality, within the context of a galvanically isolated Network connection (WiFi or optical), when you, for instance, place your router on a vibration control platform?  I am not trying to be smart here, i am honestly curious.  So far I have never heard a single, even highly speculative, theory on how things like this could possibly make a difference in sound quality.  @Nenon, as you appear to be an expert in Networking, I am interested in your take on this as well: "when every nanosecond matters" do you pay attention to vibration control of Network hardware?

 

As a secondary question: If vibration control of every switch or router in the chain makes a significant difference, what does this mean for music files distributed streamed from sources like Tidal and Qobuz? 

‘Fraid I can’t help you with the physics; in fact i hardly believed it myself. The only reason i installed a mini-rack is because the router looked strange sitting on the floor. I was as surprised as anyone when i heard clear improvements that i wasn’t expecting. Indeed i wasn’t expecting any changes. In addition, I don’t know why ethernet cables help improve SQ, but they do, even those installed before any isolation. 

[barrows]

16 minutes ago, Blackmorec said:

‘Fraid I can’t help you with the physics; in fact i hardly believed it myself.

Fair enough then... and thank you for answering my inquiry; I am interested in learning here.  Most of this stuff is understood by someone, as it is not quantum effects we are likely concerned with here.  

As there is some anecdotal evidence which suggests that clock phase noise is important here, there is the small possibility that vibration control is allowing the clock to perform closer to its best, as clocks are sensitive to vibration.  Was your router located somewhere it was subject to external sources of vibration before the rack (floor vibrations transmitted through the home perhaps)?  Although it is difficult to believe that this a possible mechanism for the improvement, it is the only one I can think of offhand.

[Nenon]

1 hour ago, barrows said:

do you pay attention to vibration control of Network hardware

 

Not the way audiophiles do it by putting fancy footers, isolation platforms, etc. However, I guess there is naturally some level of vibration control due to effective mass. A fully populated server cabinet for example could weight 2,000 lbs and it is typically bolted to the ground. I guess that does something to some types of vibrations. But no, other than the heavy mass that exists by the nature of those products, nothing else is done for isolation.

Keep in mind that every device has several fans, so there is a lot of vibration there. Also, a fully populated cabinet can draw 5-6 kVA of power. A lot of heat is generated and cooling is not an easy task. 

This is a lot different than what we do in audio. It's not practical to produce fanless servers or network devices and put them on Stillpoints. And I am still baffled how some of these things I have no explanation to matter in high end audio. 

BTW, optical cables have their own issues. Transceivers start generating errors from time to time, fiber cables get dirty and need cleaning or replacing. We replace fiber cables and transceivers more often than copper. Actually, I can't remember the last time we replaced a copper cable. And we only use the best transceivers available. An extended range 100G Cisco transceiver for example is $30K. And you need two per connection. 

One advice I can give to audio manufacturers that implement fiber optic is to monitor for FCS / CRC errors and suggest to the user to check the fiber cable if they start increasing. I guess trying to recover such errors would be pretty bad for audio streaming, and if the user has no visibility, a $50 fiber cable that got some dust can ruin the performance of an expensive system. Just a though... But everyone implementing optical connections probably knows that. 

 

[barrows]

@Nenon, thanks for your input.  I am always interested to learn from those who are expert in their own field.  Perhaps you could indulge me in a question:  Considering Ethernet Jitter, I guess this would be packet jitter-when does this become a "problem" in your work?  Is it because it gives rise to actual packet errors and re-sends, slowing down the network, or is it only a problem when/if there is an uncorrected error (my understanding is that uncorrected errors are very rare or non existent)?

And perhaps then you could relate this concept of Ethernet jitter to a home audio system.  With networked audio, I cannot recall ever having a dropout, so I am quite sure that any errors occurring are corrected-but there is some speculation that, perhaps, maybe, the level of error correction (re-sends) occurring may produce more processor noise, potentially degrading audio performance if/when this noise gets to the DAC circuitry.  I have certainly experienced (subjectively) that having the Ethernet clock in a Renderer upgraded to a Femto level part (from something already quite good) improves sound quality, but the mechanism of such is unproven to my knowledge.

[Nenon]

@barrows 

Drops can occur at many different levels. But once you build out a reliable network, it just doesn't drop any packets. We process many millions updates per second. The network devices don't drop any packets. It's a piece of cake for most network devices to transport packets from point A to point B. They can do it reliably all day long at different speed and utilization without a need for error correction. 

If something goes wrong, such as a bad transceiver or dirty cable, for example, you see CRC errors. Those appear at the Data-link layer. The network device does not try to correct them. It's up to your application or the protocol your application uses to correct those errors and recover the missed packets. If you use TCP for example,  the dropped packets would be recovered via retransmissions. It's part of the TCP specification. If you use multicast, however, the dropped packets would not be recovered. In that case you can build something in your application to take care of the recovery. Any type of retransmission/recovery obviously causes latency. But as I mentioned above, typically in a well designed network you don’t see drops. So that’s not really an issue. 

 

Although we call our networks low-latency and sometimes even ultra low-latency, we measure the latency at nanosecond granularity. Our brain is amazing. I think we are capable of hearing picoseconds latency (that’s a speculation on my part) when we listen to our highly resolving systems. If that’s the case, then everything I know about “low-latency” network goes out the roof. And we probably need to look at what is happening at a micro level (I.e. the actual physical layer where the electrical signal is converted to digital).

 

How the ethernet PHY chips deal with jitter at a hardware level is unfortunately not my area of expertise. I will do some reading on the topic, because I think this is most important part for high-end audio.

 

[This entire paragraph is pure speculation]

I am guessing that our brain is sensitive to the jitter that happens at this layer (picoseconds?). If the electrical signal arriving to the PHY is degraded, the PHY would need to use some methods to correct it. Occasionally (depending on how compromised the signal is?), it may take a little longer to correct the compromised signal. That delay might be what impacts the sound quality… the way I imagine it is data (our music) coming at a steady rate, and all of a sudden you get a delay (some type of recovery) and then going back to its steady rate. Although this is at a micro-level / picoseconds, our brain can catch that delay during the recovery. And this is where better clocks, better cables, and cleaner power can help. So maybe that's why you hear an improvement when you upgrade the ethernet clock. Maybe a better clock reduces the number of those "signal breakouts". That would also explain why ethernet cables work (deliver cleaner signal - less "signal breakouts") or even vibration treatment works (helps the clock remain more stable, resulting in less "signal breakouts"). That would also explain why changes upstream of the optical isolation work - the optical isolation isolates the electrical noise and probably smoothens the "signal breakouts" but does not completely eliminate them. Actually the more switches you have in the chain, the more you will smoothen the upstream "signal breakouts"... the problem, though, would be that every switch in the chain has the potential to generate more new "signal breakouts"... There are quite a few reports that adding two SOTM switches is better than having just one - here you go, they have good clocks, good power, potentially do well on not creating too many additional "signal breakouts", but because you have two of them, they smoothen the upstream "signal breakouts". This theory does not even conflict with "bits are bits" - yes bits are bits, they are exactly the same, but when you have uneven time gaps between them ("signal breakouts"), your brain can catch it.

 

[Blackmorec]

Barrows, I’ve been around hi-fi for more than 40 years chasing the dream of reproducing music that my brain is able to process without identifying any hi-fi related anomalies like frequency shifts, coloration,  room nodes, smearing, loss of detail, hardness, harshness etc.  I want to get completely involved in the music, without my brain identifying shortcomings. Its taken me the best part of 40 years to reach this goal. 

 

Over that time I’ve learned a couple of major lessons

1. Space and time are critical elements in music reproduction. If music isn’t differentiated spatially, as it would be in nature, it often sounds muddy and confused as frequencies overlap and either mask or colour and distort one another. As soon as similar frequencies are differentiated spatially and in time,  it becomes far easier to hear individual strands and the music sounds a lot more pure, realistic and undistorted. 

2. The better and more refined my system has become over time, the better resolved the detail but the more coherent the music has become,  2 seemingly polar opposites that are in reality highly complementary. Essentially the big picture becomes more meaningful when it contains more well resolved detail.

 

OK, so where I’m trying to get with my hi-fi and music should be clear. I’m looking for a highly resolved signal that does a perfect job in presenting and conveying the big musical picture, with huge listener involvement and no sonic contradictions.  Instruments and voices with accurate tonality and natural timbre, accurately portrayed in space, with super precise timing that underpins the rhythmic interplay between musicians. When it all works well, the music grabs my soul and doesn’t let go.  Changes to my system are easy to hear in this context because the music is either more involving and enjoyable or less. I can analyse the detail of what has changed but that’s of purely academic interest, far more important is how I’m reacting to the music my system is producing. 

Obviously no 2 recordings are the same. Some offer listening-room-expanding accurate portrayals of the recording venue or what the recording engineer has created as a recording acoustic, with acoustically active,  related space in between that places all musicians in the same acoustic venue. Old recordings often portray very beautifully recorded instruments in a left, centre, right configuration, with ‘dead’ space in between...ie no.  acoustic ‘whole’ that places all the musicians in the same venue. Beautiful but old, less sophisticated recordings.  Yet others from the bygone era used simple miking techniques to get the whole thing more or less right, recording the artists and the venue acoustics ‘as one’ 

 

So, how does this all relate to the topic of vibration control etc. Simply this. When you isolate network components from structural borne vibration and/or provide a way to ‘drain’ internally component generated vibration,  the music reproduced by the system moves in the desired direction; sometime a little and sometimes more. Adding vibration control of network components was never stunning in terms of improved SQ, but it did deliver useful increments of sonic improvement. The Sean Jacobs power supplies would better fit the stunning description, especially when used together with SR cables throughout the network. 

 

I’ve no doubt that my system still includes compromises, especially in the network, which uses cheap, consumer grade electronics. Good, I’m glad that’s the case. It means that despite the stellar results I’m getting by optimising power, signal transmission and vibration control, there are still further Improvements to come. Brilliant.  In the meantime, for anyone who uses remote streaming, they need to know that refining the front end of their network is just as important in terms of sound quality as refining their DAC, server or loudspeakers.  They also need to know that a well set up and optimised Wi-fi that provides excellent isolation can deliver stellar results. When I started out with digital streaming, I believed that wi-fi was a massive compromise and avoided it like the plague, but refinement after refinement,  Wi-fi has proven to be a great tool  in the search for sonic excellence. 

Can optical be better?  I hope so. But optical in its current state will require just as much optimisation as wi-fi and I’m not seeing speciality stores crammed with optical networking for me to try. So until someone bring out a fully optimised optical networking, I’ll stick with what’s freely available and capable of delivering stellar sonics. 

When you finally release whatever it is you’re working on,  I’d be more than happy to try it and if it beats what I currently have, more power to you. Anything that advances the SOTA is most welcome 

In the meantime though, its worth remembering that optimised Wi-fi is a pretty damned good solution and is not chopped liver, as some would make out.  

[Blackmorec]

57 minutes ago, Nenon said:

@barrows 

Drops can occur at many different levels. But once you build out a reliable network, it just doesn't drop any packets. We process many millions updates per second. The network devices don't drop any packets. It's a piece of cake for most network devices to transport packets from point A to point B. They can do it reliably all day long at different speed and utilization without a need for error correction. 

If something goes wrong, such as a bad transceiver or dirty cable, for example, you see CRC errors. Those appear at the Data-link layer. The network device does not try to correct them. It's up to your application or the protocol your application uses to correct those errors and recover the missed packets. If you use TCP for example,  the dropped packets would be recovered via retransmissions. It's part of the TCP specification. If you use multicast, however, the dropped packets would not be recovered. In that case you can build something in your application to take care of the recovery. Any type of retransmission/recovery obviously causes latency. But as I mentioned above, typically in a well designed network you don’t see drops. So that’s not really an issue. 

 

Although we call our networks low-latency and sometimes even ultra low-latency, we measure the latency at nanosecond granularity. Our brain is amazing. I think we are capable of hearing picoseconds latency (that’s a speculation on my part) when we listen to our highly resolving systems. If that’s the case, then everything I know about “low-latency” network goes out the roof. And we probably need to look at what is happening at a micro level (I.e. the actual physical layer where the electrical signal is converted to digital).

 

How the ethernet PHY chips deal with jitter at a hardware level is unfortunately not my area of expertise. I will do some reading on the topic, because I think this is most important part for high-end audio.

 

[This entire paragraph is pure speculation]

I am guessing that our brain is sensitive to the jitter that happens at this layer (picoseconds?). If the electrical signal arriving to the PHY is degraded, the PHY would need to use some methods to correct it. Occasionally (depending on how compromised the signal is?), it may take a little longer to correct the compromised signal. That delay might be what impacts the sound quality… the way I imagine it is data (our music) coming at a steady rate, and all of a sudden you get a delay (some type of recovery) and then going back to its steady rate. Although this is at a micro-level / picoseconds, our brain can catch that delay during the recovery. And this is where better clocks, better cables, and cleaner power can help. So maybe that's why you hear an improvement when you upgrade the ethernet clock. Maybe a better clock reduces the number of those "signal breakouts". That would also explain why ethernet cables work (deliver cleaner signal - less "signal breakouts") or even vibration treatment works (helps the clock remain more stable, resulting in less "signal breakouts"). That would also explain why changes upstream of the optical isolation work - the optical isolation isolates the electrical noise and probably smoothens the "signal breakouts" but does not completely eliminate them. Actually the more switches you have in the chain, the more you will smoothen the upstream "signal breakouts"... the problem, though, would be that every switch in the chain has the potential to generate more new "signal breakouts"... There are quite a few reports that adding two SOTM switches is better than having just one - here you go, they have good clocks, good power, potentially do well on not creating too many additional "signal breakouts", but because you have two of them, they smoothen the upstream "signal breakouts". This theory does not even conflict with "bits are bits" - yes bits are bits, they are exactly the same, but when you have uneven time gaps between them ("signal breakouts"), your brain can catch it.

 

That’s exactly the kind of information I hope to find, that makes trawling through some of these threads worthwhile. I appreciate that a lot of what you say is speculation, but its logic seems really solid, so while it may not yet be proven by measurements and experimentation,  it sure sounds reasonable and does a great job of scratching the itch caused when subjective results don’t vibe with commonly held and stated views. Nice post!

[Blackmorec]

5 hours ago, Blackmorec said:

deleted

  

 

[barrows]

@Nenon.  Thanks for the details.  OK, so, it appears we can be pretty certain that we are not losing packets in terms of Ethernet distributed home audio, unless there is something very wrong with our Network configuration.  Secondly, your speculation about small timing differences effecting audio sound quality makes no sense, so here is why i have an issue with some of these things.  Timing differences of Ethernet distribution never make it to the audio which we hear (actual audio jitter).  this is an area where I do have some expertise (so we have an understanding of this, audiophile for over 40 years, introduced to the hobby by my Father and Uncle, working in high end audio for the last 20 years).

The digital audio data which is presented to our DACs is timed by the clock in the DAC, each word or bit, is timed out of a buffer, by the DAC clock (at least in any competently designed DAC).  Indeed, I agree that the human ear/brain mechanism is very sensitive to this timing and the artifacts produced by the DAC when this timing is off.  But, this timing is not effected by the timing of Ethernet packets, there is absolutely no correlation there-the only clock which matters for this is the DAC clock, period (I am keeping this discussion on USB audio here for simplicity, SPDIF would be a bit more complex, but still all timing would bear no correlation with Ethernet timing).  The speculation that Ethernet timing somehow effects the timing of the audio we hear is false, so if Ethernet timing issues actually cause some kind of audio degradation, the mechanism for this effect must be something else.

 

@Blackmorec, I like your 1 & 2 above.  In a previous position at an high end audio company I was trained in doing listening tests, and participated in testing for jitter, where we correlated measured jitter levels with subjective listening experiences.  This resulted in some interesting take aways-one was that it was clear that sometimes, especially in less than perfect systems, it was clear that a listener could prefer the sound with the higher jitter level.  But, your 1 & 2 above indicate to my experience a real improvement in jitter (most likely).  I find the way to really nail this down subjectively, is that lower jitter will usually reveal more detail (and at the levels we are likely referring to I do not mean more detail in the sense of hearing a subtle percussion instrument you did not hear before, I mean more like hearing more detail of the sound of that percussion instrument, perhaps like hearing now for certain that the percussion instrument, perhaps at -60 dB even, way in the background is most certainly a wood block, hearing the woodiness of it, for example) while at the same time experiencing more ease in the presentation of the music, a more natural sound, which allows the listener to relax more and engage more fully with the music-sometimes this even takes the form of a feeling that the music is slowing down a bit.  Having read some on how the brain experiences music (read Daniel Levitin's work on this, highly recommended) I suspect what is going on is that the brain is doing less work to sort out what it is hearing, and this allows the listener to relax more and engage with the actual music, rather than with the work of sorting out what is being presented to the ear.  The problem with this of course, is that it is so subjective the listener has to be very careful about controlling the space they are in, as this sense of ease is so subjective that the state of mind of the listener is almost certainly the biggest factor in experiencing it.  So if one is interested in critical listening for evaluation, one must develop techniques in controlling for the personal variable.  For me, I learned that there was never a point in trying to do listening tests anytime I was stressed, or had other things on my mind, even subconsciously.  I am not suggesting that your observations are not valid, I can have no idea of that, only you can know, and one can only know after much work on understanding their own minds and consciousness.  I am just mentioning this for anyone who might have the patience to read this!  I recommend things like meditation, or other practices of mindfulness, in order to really get handle on controlling for the subjective human factor in all this.

 

Back to nuts and bolts:  So, re Ethernet timing and how it might effect audio playback.  We have no answer here, as I have mentioned, Ethernet timing has no bearing on the actual timing in the DAC, at least not directly.  Only the DAC clock is responsible for timing the bits into the conversion stage.  So, if the Ethernet clock is having an effect on the audio playback, the mechanism by which this happens is something else-what could that be?  What else is there?  We have the data, which as we have discussed is perfect (no packet losses, and individual packets, data points, are not being changed), we have the timing, which in Ethernet does not effect the timing in the DAC, and we have electrical noise levels coming into the DAC from the Network.  What else is there?  It appears to me that the only thing there is from the Network which can effect the audio playback is the Network noise getting into the DAC ...

[incus]

40 minutes ago, barrows said:

The speculation that Ethernet timing somehow effects the timing of the audio we hear is false

What more precisely makes you so sure of this? Doesn't each ethernet clock have a certain tolerance that does allow for a certain level of timing error to pass through, albeit below the threshold of the precision of that clock? Could these in turn be perceptible along the lines of what @Nenon is saying? It has been the case in my experimentation that bettering the clocks upstream of the DAC results in and of itself in an audible improvement... Separate from power supply, cabling, electrical isolation and vibration-control upgrades... just a thought...

[Nenon]

1 hour ago, barrows said:

@Nenon.  Thanks for the details.  OK, so, it appears we can be pretty certain that we are not losing packets in terms of Ethernet distributed home audio, unless there is something very wrong with our Network configuration.  Secondly, your speculation about small timing differences effecting audio sound quality makes no sense, so here is why i have an issue with some of these things.  Timing differences of Ethernet distribution never make it to the audio which we hear (actual audio jitter).  this is an area where I do have some expertise (so we have an understanding of this, audiophile for over 40 years, introduced to the hobby by my Father and Uncle, working in high end audio for the last 20 years).

The digital audio data which is presented to our DACs is timed by the clock in the DAC, each word or bit, is timed out of a buffer, by the DAC clock (at least in any competently designed DAC).  Indeed, I agree that the human ear/brain mechanism is very sensitive to this timing and the artifacts produced by the DAC when this timing is off.  But, this timing is not effected by the timing of Ethernet packets, there is absolutely no correlation there-the only clock which matters for this is the DAC clock, period (I am keeping this discussion on USB audio here for simplicity, SPDIF would be a bit more complex, but still all timing would bear no correlation with Ethernet timing).  The speculation that Ethernet timing somehow effects the timing of the audio we hear is false, so if Ethernet timing issues actually cause some kind of audio degradation, the mechanism for this effect must be something else.

 

I think we are talking about two different things and two different reconstruction mechanisms. I was referring to the PHY converting the electrical signal to Ethernet frames. You are referring to the DAC converting the electrical signal that carries the digital signal containing music. Two completely different signals - one is Ethernet (upstream of the music application), the other is the digital format of the music (downstream of the music application).

What I was trying to say (speculate) was that if the process of converting the electrical signal from your ethernet cable to ethernet frames has to do a lot of recovery, it adds some latency to your network delivery. Very little latency, but perhaps enough for our brain to pick it up. There are no dropped packets. Every single bit gets delivered perfectly fine to the data link layer then all the way to your music application. Your application converts it to whatever format you use and goes out through your digital output interface (let's say USB).
The DAC receives the USB output and does its reclocking to address any issues with the electrical signal to digital signal conversion of the bits containing music (nothing to the with the Ethernet frames bits). And that's what you are referring to. But the DAC cannot do much about the irregularities of your network traffic upstream of the application receiving it. That latency added by the Ethernet PHYs is what I believe impacts the quality of the music. Improving the Ethernet PHY with better clocks and cables (and also helping the clock function better by taking care of vibrations and providing clean power) means less recovery, less latency, and more timely signal delivered to your application. But that's not the timing in the digital audio you are thinking about. The DAC does not reclock the Ethernet signal upstream of your application. I am not sure if am explaining this properly... it's much easier on a whiteboard.
But that would also explain why applications that buffer 100% of the song before playing and larger squeezelite buffers sound better.

[barrows]

15 minutes ago, Nenon said:

That latency added by the Ethernet PHYs is what I believe impacts the quality of the music.

 

There is no explanation here as to how this would be possible.  What are you proposing is the actual mechanism for any latencies in Ethernet effecting the output of the DAC?  As long as the USB interface gets the complete data, it is then clocked out in time as per the local clock, and no latency on the Ethernet side has any effect on this.

 

Additionally, if this latency is effecting music playback sound quality, via some as yet unknown mechanism, then what would be the implications for sound quality for files streamed from the Internet (Tidal/Qobuz)?  I would guess (please correct me if I am wrong about this) that latencies from an Internet streamed file would be orders of magnitude greater than that for locally stored files considering how many Ethernet switches and the like must be involved from the path of the server to one's home.