Router for Audio Streaming

@jerryg123 , thank you. That's a pretty good article.  What I'm missing is an explanation exactly how the power supply and switching affects the audio stream sound quality in the digital stage (switch and streamer).  What is the mechanism.  The signal is still bits, so what happens to them, and what control or error checking, if any, is occurring in this stage.  Anyway thanks again.

Epilogue:

Hi guys,

Well, I broke down under the overwhelming peer pressure and succumbed to the ethernet gospel.  Did exactly as @nagel suggested -- got a high rated 30' CAT 6 cable off Amazon and ran it along the floor, from the router to the streamer.

My wife and I decided to evaluate it completely blind.

Our listening space is our living room, and the component rack is behind a wall in the study.
My wife has a very refined musical ear and sharper hearing than mine, and like me has been into music and good audio for decades, so she was the evaluator.
I proceeded to unplug and plug (or not...) the ethernet cable from/into the streamer and replay each track at least 3 times in quick succession with blind changes in between (and at times no changes for verification).  We did not touch the volume or any other controls throughout the evaluation. I had my router admin page open on my computer in the study to confirm each time after plugging in that the connection indeed switched from wifi back to wired.
My wife could not see what I was doing and I never told her.  She remained seated in the optimal listening spot in the living room.
I marked the track, setting (wired or wifi) and her feedback on a sheet in the study.
We repeated this for four hi-res Qobuz tracks which we know very well and which cover the important audio aspects - human voice, orchestra, harmonics, percussion, bass, sound stage, dynamic range, etc.

The outcome:  Nothing.  She could not tell any difference after any change with any track.  I 100% agreed with her assessment but we did not communicate during the evaluation and I recused myself since my experience was not blind.

Disclaimer:  We have very few devices sharing 2.4 GHz bandwidth with the streamer, we do not live in a high density area, and our internet download speed is consistently around 350 mbps or better, so our wifi traffic is not challenged. Hence, "your results may vary"... although I have serious doubts.

In closing, no one so far has been able to provide me with a clear logical explanation for a potential mechanism which alters bits in wifi in a manner which results in stuff like less rich tonality, narrower sound stage, reduced frequency response, increased noise floor and all the rest of it compared to Ethernet.  (I am not arguing about drops and buffering if your wifi is too crowded, but these are discrete events, not a continuous effect on sound quality.)

Many thanks to y'all for making this a very lively and informative thread!

Cheers.

Hey, FuzzTone!  Thanks for the quick and helpful reply!

How beneficial is the mesh feature if the house is not very large? (currently not using mesh).

Thank you, @audphile1 audphile1 and @hk_fan !

And thank you, @yage !  And thank you also for the links!  No, I have not looked into unbricking etc...  Fascinating stuff but not sure I'm up to diving into it. On the other hand, if the router is a brick the worst is buying a new one, which obviously I'm mentally getting prepared for...

My understanding of digital signal transmission and processing is very limited but I read/heard about bit error issues and clock accuracy issues.  I guess how the data is sent is one thing (and do we know exactly what equipment they use?) and how it is being received and processed is another, isn't it?

Thanks again!  My current plan is to order a new router from Amazon Prime (as to which one I'm soliciting opinions here).  Once it arrived, try a hard-reset of the Netgear.  If successful, send the new one back.  if not, set up the new one and take the Netgear to the electronics recycling pile.

Thank you, @kota1 and @lollipopguild !  All good inputs!

Thank you, @yage !  I ran the 'netstat -s' command and I see a bunch of lines in the TCP section but no '... discarded for bad checksum'.  What segment of time does this command cover?

For whatever it's worth, in the UTP section I get:

    396308 datagrams received
        0 with incomplete header
        0 with bad data length field
        0 with bad checksum
        1 with no checksum
        330384 checksummed in software
            246184 datagrams (53642392 bytes) over IPv4
            84200 datagrams (18592713 bytes) over IPv6
        351 dropped due to no socket
        80576 broadcast/multicast datagrams undelivered
        0 time multicast source filter matched
        36642 dropped due to full socket buffers
        0 not for hashed pcb
        278739 delivered
    130000 datagrams output
        138955 checksummed in software
            107355 datagrams (38385652 bytes) over IPv4
            31600 datagrams (6833860 bytes) over IPv6

Have no clue what all this means....

Cheers!

To @soix :

Magna Mano Ultra LMS streamer
RME ADI-2-DAC FS dac
Sony SCD-XA5400ES CD/SACD player
Thorens TD 166 MkII turntable w/ Shure V15VxMR and JICO stylus

Parallel stereo systems playing together in same room from common source:

System A:
Bryston BP-25 preamp
Bryston 4B SST amp
JBL L150A speakers

System B:
NAD C165BEE preamp (and overall source selector)
NAD C272 amp
Magneplanar MG1.6/QR speakers

Pretty kooky, huh?

@yage , thanks!  Here is the tcp dump:

tcp:
    0 packet sent
        0 data packet (0 byte)
        0 data packet (0 byte) retransmitted
        0 resend initiated by MTU discovery
        0 ack-only packet (0 delayed)
        0 URG only packet
        0 window probe packet
        0 window update packet
        0 control packet
        0 data packet sent after flow control
        0 challenge ACK sent due to unexpected SYN
        0 challenge ACK sent due to unexpected RST
        0 checksummed in software
            0 segment (0 byte) over IPv4
            0 segment (0 byte) over IPv6
    0 packet received
        0 ack (for 0 byte)
        0 duplicate ack
        0 ack for unsent data
        0 packet (0 byte) received in-sequence
        0 completely duplicate packet (0 byte)
        0 old duplicate packet
        0 received packet dropped due to low memory
        0 packet with some dup. data (0 byte duped)
        0 out-of-order packet (0 byte)
        0 packet (0 byte) of data after window
        0 window probe
        0 window update packet
        0 packet recovered after loss
        0 packet received after close
        0 bad reset
        0 discarded for bad checksum
        0 checksummed in software
            0 segment (0 byte) over IPv4
            0 segment (0 byte) over IPv6
        0 discarded for bad header offset field
        0 discarded because packet too short
    0 connection request
    0 connection accept
    0 bad connection attempt
    0 listen queue overflow
    0 connection established (including accepts)
    0 connection closed (including 0 drop)
        0 connection updated cached RTT on close
        0 connection updated cached RTT variance on close
        0 connection updated cached ssthresh on close
        0 connection initialized RTT from route cache
        0 connection initialized RTT variance from route cache
        0 connection initialized ssthresh from route cache
    0 embryonic connection dropped
    0 segment updated rtt (of 0 attempt)
    0 retransmit timeout
        0 connection dropped by rexmit timeout
        0 connection dropped after retransmitting FIN
        0 unnecessary packet retransmissions
    0 persist timeout
        0 connection dropped by persist timeout
    0 keepalive timeout
        0 keepalive probe sent
        0 connection dropped by keepalive
        0 connection dropped by keepalive offload
    0 correct ACK header prediction
    0 correct data packet header prediction
    0 SACK recovery episode
    0 segment rexmit in SACK recovery episodes
    0 byte rexmit in SACK recovery episodes
    0 SACK option (SACK blocks) received
    0 SACK option (SACK blocks) sent
    0 SACK scoreboard overflow
    0 limited transmit done
    0 early retransmit done
    0 time cumulative ack advanced along with SACK
    0 probe timeout
        0 time retransmit timeout triggered after probe
        0 time probe packets were sent for an interface
        0 time couldn't send probe packets for an interface
        0 time fast recovery after tail loss
        0 time recovered last packet
        0 SACK based rescue retransmit
    0 client connection attempted to negotiate ECN
        0 client connection successfully negotiated ECN
        0 time graceful fallback to Non-ECN connection
        0 time lost ECN negotiating SYN, followed by retransmission
        0 server connection attempted to negotiate ECN
        0 server connection successfully negotiated ECN
        0 time lost ECN negotiating SYN-ACK, followed by retransmission
        0 time received congestion experienced (CE) notification
        0 time CWR was sent in response to ECE
        0 time sent ECE notification
        0 connection received CE atleast once
        0 connection received ECE atleast once
        0 connection using ECN have seen packet loss but no CE
        0 connection using ECN have seen packet loss and CE
        0 connection using ECN received CE but no packet loss
        0 connection fell back to non-ECN due to SYN-loss
        0 connection fell back to non-ECN due to reordering
        0 connection fell back to non-ECN due to excessive CE-markings
        0 connection fell back caused by connection drop due to RST
        0 connection fell back due to drop after multiple retransmits
        0 connection fell back due to RST after SYN
    0 time packet reordering was detected on a connection
        0 time transmitted packets were reordered
        0 time fast recovery was delayed to handle reordering
        0 time retransmission was avoided by delaying recovery
        0 retransmission not needed
    0 retransmission due to tail loss
    0 time DSACK option was sent
        0 time DSACK option was received
        0 time DSACK was disabled on a connection
        0 time recovered from bad retransmission using DSACK
        0 time ignored DSACK due to ack loss
        0 time ignored old DSACK options
    0 time PMTU Blackhole detection, size reverted
    0 connection were dropped after long sleep
    0 connection had stretch ack algorithm disabled
    0 time a TFO-cookie has been announced
    0 SYN with data and a valid TFO-cookie have been received
    0 SYN with TFO-cookie-request received
    0 time an invalid TFO-cookie has been received
    0 time we requested a TFO-cookie
        0 time the peer announced a TFO-cookie
    0 time we combined SYN with data and a TFO-cookie
        0 time our SYN with data has been acknowledged
    0 time a connection-attempt with TFO fell back to regular TCP
    0 time a TFO-connection blackhole'd
    0 time a TFO-cookie we sent was wrong
    0 time did not received a TFO-cookie we asked for
    0 time TFO got disabled due to heuristicsn
    0 time TFO got blackholed in the sending direction
    0 time maximum segment size was changed to default
    0 time maximum segment size was changed to medium
    0 time maximum segment size was changed to low
    0 timer drift less or equal to 1 ms
    0 timer drift less or equal to 10 ms
    0 timer drift less or equal to 20 ms
    0 timer drift less or equal to 50 ms
    0 timer drift less or equal to 100 ms
    0 timer drift less or equal to 200 ms
    0 timer drift less or equal to 500 ms
    0 timer drift less or equal to 1000 ms
    0 timer drift greater than to 1000 ms

All zeroes.  Is that good or bad?? 😳

@elliottbnewcombjr , thanks!  That's exactly what I've done, as I mentioned in one of my previous posts.

Folks, thanks a bunch for all the great input:

@yage :  Ooops, thanks.  Not sure how to go about it but will try.

@soix and @riccitone :  Interesting!  But how/why does an extender help? It itself is getting the signal on wifi. I've had good signal strength and never any buffering with the Netgear until the firmware issue.  I intend to either fix it or replace it with a better one, so would there be any gain from an extender?

@audioman58 :  How/why a combined modem+router would be better than separate devices in terms of sound quality, or is it just to save money (not bad in itself)?

@dougthebiker & @daledeee1 vs. @yage :  Interesting!  So... looks like two of you are stating that sound quality (e.g., staging and clarify) can be influenced in the digital stage (other than outright failures), while I believe @yage has stated that it cannot other than outright failures .  Can y'all please explain?

Thanks again!

@soix , thanks.  I guess in that case using a mesh network like a TP-Link Decco, as several folks are recommending, and connecting the streamer via cable to one of the nodes would be even better, no?

Folks, so much good input!! Thank you all!  I will look into most of these suggestions.

One point to keep in mind:  Bypassing wifi altogether in my situation is not a practical solution.  I am pretty much stuck with wifi considering the amount of time, money and effort I am willing to invest in this.  I also heard of some issues and mixed results with powerline signal transmission, so, again, I am staying wireless.  I have had wireless streaming for years with no signal problems that I am aware of.  Of course I don't know what signal quality I'm missing, but my wife and I are quite musically discerning, we also listen to our Thorens/Shure turntable and our Sony ES SACD on the same system, and find our wifi streaming sound with the current streamer and DAC quite good, certainly on par with the CD player. 

The quest is for a good wifi router solution with obvious streaming and sound quality benefits in case the current Netgear ends up a brick.

Thank you, @daledeee1 !  Indeed, OCD and never satisfied can be potentially joy robbing so I am trying to avoid it.  For the time being it will be wifi - that's a hard constraint for now.  I may be trying 2 different wifi solutions, a "conventional" powerful router and a mesh system if my Netgear ends up a brick and see what works, or rather what doesn't.  Had my lowly Netgear R6400v2 not "locked up" I wouldn't have started this thread...

Most recently I have spent my energy and some funds on acoustic improvements to the listening space with HUGE bang for the buck, but that's for another thread...

P.S., to all the good folks here, please narrow/tweak your recommendations if possible to wireless solutions only. I have no easy way or desire to run a cable from my router to my streamer or use powerline - I understand this may be presenting a tradeoff but it is a hard limitation. I may have not stated this explicitly enough in my original post, and for that I apologize.

In system engineering this is called "optimization under constraints". :-)

Thanks!

@ghdprentice , thanks. I am very happy with my streamer (Magna Mano Ultra MkII) and my DAC (RME ADI-2).  The only required action currently is either fix or replace the router since it cannot be controlled.  That's why the post.  Cheers.

@yage :  For whatever it's worth, just ran the netstat command in root - 0 discarded due to badchecksum - this is with my "locked up" Netgear.  Below is the relevant subsection (not the whole dump again...).

77680 window update packets

10349 packets recovered after loss

8558 packets received after close

2 bad resets

0 discarded for bad checksum

127869 checksummed in software

127837 segments (9756384 bytes) over IPv4

32 segments (1408 bytes) over IPv6

0 discarded for bad header offset field

0 discarded because packet too short

Thanks!

Thank you, @nmolnar !! It is awesome to synthesize inputs from our expert panel!  This is the beauty of this forum.

I will look into the M9.

@dougthebiker , thanks.

Digital representation of sound is not by square waves. There are no square waves in digital audio. There are square waves (before filtering) in inverters generating AC from DC but that’s a totally different story.

The sound level at a sampled point in time is represented by a numerical value in binary form. No sound is 0 and maximum sound level is the highest value possible with the number of bits used. The more bits (0’s or 1’s) are used to represent the numerical value (e.g. 24 vs 16) the better resolution is possible (discrimination between the closest sound levels). When we have 16 bits, we can have 2^16 distinct values, or sound levels, from 0 to 65535.

The sampling rate, or how frequently these numbers are sampled, defines the frequency response, or rather, what is the highest frequency that can be transmitted. For instance, CD sampling rate is 44,100 times (values) per second, and the highest frequency is around 20 kHz.

What you get in digital sound is a stream of numerical values in binary format which represent the sound level at each sampled point in time during the music. The frequency, or pitch of the sound, is determined by the fluctuation of consecutive numerical values. Converting these numerical values to analog voltages and "connecting" or "smoothing" them is done by the DAC. Digital transmission devices do not modify the numerical stream, only ensure it is received as it was sent or report errors.

For simplicity, if you use 4 bits, then 0001 = 1, and 1111 = 15. So 1000 (which = 8) is not greater by 1 vs 0000 (which = 0). The packet transfer protocols check for errors both in wifi and ethernet. If your wifi signal is strong and stable and you have sufficient bandwidth you get the same stream as via ethernet, otherwise you get drops or buffering.

For whatever it’s worth, there is a technical review of the UpTone Audio EtherRegen in audiosciencereview.com. You can look it up.

Update:  Two routers ordered on Amazon Prime:  Asus AX5400 (conventional) and TP-Link X60 3-pack. The Asus based on specs and highest rated reviews on Amazon.  The TP-Link based on specs and several endorsements here.

The Asus is here and the TP-Link is due here tomorrow.  Once it's here I will try first the factory reset and firmware update on the current Netgear.  If successful (kind of doubt it) both news ones go back.  If not successful I have yet to decide which new one to try first.  If the first new one works, the other new one goes back.  If the first new one does not work it goes back and we try the second one.  If that one does not work either (unlikely I think) it also goes back and we're back to the drawing board...

OK, I get what you were after, @dougthebiker ... The "square waves" defining the individual bits...

In fact they are not and do not need to be square at all. They "just" need to meet specified tolerance windows of high and low values inside a specified clock window.

Both wifi and ethernet signals need to meet this. Both wifi and wired routers and switches need to comply with these window specs. Good ones do, really bad ones may not.

What I was trying to explain is that an error in the level of one or more bits (1 instead of 0 or vice versa) does not create distortion, it creates a numerical error vs. the check bits which either can be corrected or results in a drop or buffering or really obvious noise, not harmonic distortion or amplitude or phase shift.

Of course wifi is susceptible to range and strength and bandwidth/speed issues. The point is that once you have a properly set up network with decent equipment and the signal is stable (sufficient speed and strength), the signal you will get via wifi will be identical to the one you get via ethernet.

Low quality or too long ethernet cables can also cause your bit signal to shift outside of the tolerance windows and cause transmission errors due to out of spec resistance, capacitance or inductance.

Think of streaming HD TV on your wifi Amazon Fire Stick vs. via digital cable. If you have enough bandwidth and signal strength, the picture on the same TV will be the same. The colors will be the same, the resolution will be the same, etc. The one on the Fire Stick will not be "distorted".

Same thing with audio. I took care to specify and locate my existing router and streamer such that there is no buffering or drops. I now need at minimum to replicate this. To my knowledge there are indeed subtle, incremental sound quality improvement opportunities in better routers due to clocking accuracy and electrical noise, and that’s the reason for my original post. But that applies to both ethernet and wifi.

I believe we beat this horse to death.

Cheers!

@cakyol , thanks.  I have been streaming audio over wifi for over 10 years, more than 3 with the current router.  My streamer requires 2.4GHz.  As I mentioned a few posts up I have around 10 devices on the same network and do not have issues.  Sound quality is on par with, maybe better than my Sony ES CD player (most likely thanks to the DAC). Speedtest is showing regularly 300-350 Mbps download at my Mac over wifi.

Hello @teknorob23 ,

Please refer to my original post. I am focusing on the router because it is broken. Everything else is fine. I am simply inquiring whether there is obvious opportunity for any sound quality improvement in case I need to replace it.

I have fine and stable sound with wifi streaming, no drops or buffering issues. I am just no longer able to control my router, that's what this is all about.

I intend to use the repaired or new router exactly the same way I use it now - through wifi and with all other current wifi devices. I have 10 or 11 wifi devices on the network including at most one smart TV concurrently with the streamer. No gaming or cameras. We have one desktop connected to the router via ethernet for my wife's business (zoom-type sessions). If I decide to use the Asus it will be connected to the desktop via the priority (gaming) port.

@brunomarcs , sorry for encroaching on your lofty audio forum.

I think I made it very clear what my parameters, constraints and reasoning are. And I received a wide range of very good advice here, both wifi and wired.

There is more than one way to skin a cat, even in audio. Even in audio, as in life, there are tradeoffs. I am looking for the best solution within constraints, not the absolute best solution in the universe at any cost or effort or side effects.

The audio world is full of many approaches and solutions in a wide range of cost and complexity. It is also full of myths and dogma.

Even with my doctor and lawyer I am always listening and evaluating very carefully but am not obligated to accept their advice. So let’s relax a bit.

Cheers.

Well... good news and bad news.

The bad news first: I won't be able to use yet any of the good advice collected here.
The good news:  Contrary to the Netgear horror stories I was able to hard-reset and update my current router and all is well.  So both new routers will be dropped off at Kohl's tomorrow...

I do appreciate all your inputs and will refer to them again when the time comes to replace the router.  And to all the wifi skeptics (and believers):  If any of you happen to pass through upstate SC and have an hour or two to spare, drop me a line here with some advance notice and we will welcome you to our home for a brief (or longer) audition.

Cheers,

Yoram

P.S., just to confirm my understanding: the tri-band mesh has a wireless backhaul which does not rob bandwidth from the devices and does not need ethernet backhaul, correct?

@nmolnar , thank you.  I'm inclined to follow your advice.  Will report outcome.

Thank you, @yage !  It was very helpful.  That dump was before fixing the router.  I can only assume that nothing changed for the worse.  Thanks again!

@teknorob23, no worries!

@nmolnar , thank you for this!  Duly noted!

My Netgear is from late 2018, and just got its firmware update.  It has been and is performing fine.  Our house is not very big and we do not experience drops while roaming around with mobile devices, but my focus is audio performance.

I still have on my hands the sealed TP-Link X60 3-pack mesh system which I'm about to return in the interest of cashflow...  Do you think I should bite the bullet and install it now, postpone for a year or two, and/or in any case steer clear from TP-Link?

Thanks!

@yage , thanks! I am really trying to avoid running ethernet wires -- no easy way to do it in this house cleanly and cheaply. Maybe a mesh system is an overkill in our situation? There is one line I ran from the router (ground floor) to my wife’s office upstairs. All other devices are fine accessing the router via wifi.

Per @nmolnar ’s advice I might be inclined to update to a newer tech router but do not want to create new issues where there are none at present...

P.S., the TP-Link X60 I have here ready to be returned is Wifi 6, but not tri-band.

@yage , thanks again.  I have no Wifi 6 compatible devices at this point.  I will definitely keep your points in mind.  As you recall the original conversation started with the query about sound quality (referring to continuous distortion level, not reliability).  I have yet to be persuaded that a reliable wifi network distorts audio more than ethernet.  I see no way for that to take place.  If there are specific routers with superior clock accuracy or electric noise control which impacts the bit stream I remain curious (but that would not be specific to wireless vs. ethernet).

Cheers!

@oldrooney , wanted to get back to you. Very cool streamer, the Aries!

We listen to Pandora, Spotify and Qobuz, and I spent quite a bit of time looking for a wifi streamer that would support all three and replace my two existing streamers - Squeezebox Duet and Bluesound Node 2 - at the highest audio definitions available. Unfortunately very few devices fully support Pandora.

One of the good folks on this forum cued me onto the Magna Mano Ultra Mk2, which I’ve been using happily for over 1.5 years now together with an RME ADI-2 FS dac. The Mano can run ethernet but my home makes it quite difficult. It runs wifi 2.4G very reliably. My router and Mano are both located quite high and about 18’ and 2 internal walls apart. I did move all my other devices that are capable to 5G, especially the smart TVs, to minimize 2.4G traffic.

BTW, the root cause for this entire thread was that I needed to update the Logitech Media Server software on the Mano but could not access it because of a failed router firmware update... All is well now.

@pcrhkr , I'm with you. UPS is a good idea. Have been considering one for a while. Which one do you have/recommend?

Had quite several good years of use from my Bluesound Node 2.  It developed the known red LED issue but kept running fine.  Ended up replacing it and my squeezebox duet not long ago with a single streamer to increase flexibility and improve the DAC.

Staying with the Netgear for the time being.

Please forgive me but for the life of me I cannot see the purpose of this device other than to enrich its manufacturers.

Gents, no offense intended or taken.  I simply have not enough time or money to try every audio gizmo without some basic understanding of why, how and to what extent it works, and whether it is intended to address a specific "opportunity" with my current setup. Same is the case for dietary supplements, fitness programs, investment plans, etc...

In this case I read through some of the available literature online and cannot convince myself that this stuff works at all or that its effect is perceptible by the human ear.  I am an engineer with some grasp of vibration theory and signal processing, including Fourier series etc.

As to subjective evaluation, in my audio experience, when you have a very good system to start with, and you are introducing a subtle tweak -- not a very different speaker or an amp of a different performance category or bass traps etc. -- the only reliable way to evaluate its effect with no placebo effect requires:  a) blind A-B-A auditioning, and b) immediate and brief back to back auditioning - e.g., a 5 sec. segment repeated within 1-2 seconds.  These are impossible to accomplish on our own.

Of course I could be wrong.  And of course it could be that I am currently complacent and content with our sound quality and happy to just enjoy the music and not chase the ever receding horizon of promised improvements...

Cheers.

Sorry guys, not buying (figuratively and literally).  But thanks for the tip!

In my understanding, a digital signal (defined by a stream of binary bits) can be distorted in one of two ways ("failure modes"):  a) a "high bit" or "1" is read as a "low bit" or 0 or vice versa, and b) the timing of the bits is unsteady or fluctuating.

In order to prevent failure mode a) the bit stream includes checksum bits which are verified and in case of error the packet is either corrected or rejected which causes buffering or a drop, not a distortion (amplitude, phase, harmonic) of the sound.

The way to minimize failure mode b), which is also called jitter, is to use good clocks and power supplies.

With careful setup of my wifi network I am not experiencing failure mode a).

The reason for my original post was the potential to minimize failure mode b), the current extent of which I am not able to discern without hard comparison. I am open to practical and cost effective (not pie in the sky) suggestions that target potential jitter with an approach that I can understand.  The battery concept proposed by @romanesq makes some sense in this regard.

Please note that once we move to the DAC and analog stages it's a different story.

Cheers!

@ghdprentice , thanks!

I actually got sucked now (really for no good reason!) into "hardwiring" the ethernet cable through the crawl space.  Quite a PITA fishing it through 3 different places, but I figured I already have the cable, have the time, and have the poor judgment (and twisted urge?) to proceed with the challenge....

We may be hearing very slight improvement with our turntable, but definitely none with our Sony ES SACD player over wifi.

Like you, I resisted this, for 10 years in our case ever since we moved here.  Again, we have never had an issue or the need to do this.  Needless to say, I am not proceeding to invest in an audiophile grade switch...  :-)

Cheers!

Factual correction for the record (not that it affected the outcome):  The CAT 6 cable we used in the evaluation and I subsequently hardwired is 50' long, not 30' (got it mixed up with my bass guitar cable).

@sns :

1. As reported, we cannot detect any difference in sound between our wifi and our 50’ ethernet cable. We invite you to stop by and subject yourself to the same blind tests we ran and see if you can hear any difference. I will bet that you won’t hear any.

2. Latency in copper is about 5 nano sec/m, so with our cable it would be about 75 nano sec. If you treat that latency as 1/2 period, you get a frequency of about 6.7 MHz. Good luck hearing 75 nano secs or 6.7 MHz.

3. How does latency affect sound? So what if the sound is delayed 75 nano secs? What about the latency between the Qobuz or Spotify server and your router? What about the latencies (phase shifts) in the DAC, preamp and amp?

4. How does jitter sound like? What aspect of the sound does it affect and how?

I don't expect to ever hear any of the things you mention as a function of digital bits being somehow altered in such subtle ways.

Hi Guys,

More power to y'all.  I'm not preaching, honestly... Please keep doing what you're doing!!

My subtle sound quality perception may not be as refined as some of you, although folks say that I do have a very musical ear (nothing I did to earn it)...

My approach to audio is quite simple:

1.  It needs to sound really good to me.  I know when it does and when it doesn't, and why.

2.  It needs to make sense in the context of our discretionary funds and other hobbies and pastimes.

3.  If an improvement is not patently and immediately obvious to my ears, or the upfront technical rationale not convincing to my mind (e.g., how exactly digital bits get changed and how exactly it affects the sound), I conduct a controlled, fully blind evaluation, such as in this case.  This requires a trusted and audio-interested helper -- a spouse, a friend etc.  You'd be surprised by some of the results of true blind evaluations. I certainly was in a few instances.

4.  If I feel that I need improvement in a certain aspect of sound, I apply the Pareto approach:  What is the single element which is likely to provide the most improvement at a reasonable cost.  If that does not bring about all the desired improvement, what is the next one, etc.

5.  I don't pay for what I don't hear, however sexy the story or the equipment.

6.  I appreciate that in theory there may be 20 very subtle improvements coming from 20 different areas, of which each one alone I cannot detect, but when combined together vs. the starting point I would hear improvement.  I guess that would be my loss, as I am not hardcore enough to chase them all on the premise that maybe at the end I will reap the rewards...

Cheers!

@mendef , if you follow the thread you will discover that the router question had been resolved. I have successfully factory-reset my trusty Netgear AC1750 R6400v2 and it works seamlessly in both wifi and ethernet hi-res audio (Qobuz 192kHz) streaming as before.

My experience with wifi vs. ethernet (in audio) is the same as yours.

P.S., as I had posted, I'm getting consistently > 350 mbps at my desktop via wifi, and have never had audio buffering, so no speed issues.

@sns , thanks!  Re #3, for sure longer term listening helps to confirm whether you are satisfied or not with the change, however I found that only very quick back-to-back-to back-to back blind comparison can point out subtle differences.  Our memory just isn't good enough to retain sound subtleties.

@cakyol , thanks.  If you followed the thread you'd know that has been exactly my approach.