PSA - how to directly connect NAA to HQP without bridging in Windows

[tboooe]

Like many, I believe a direct connection between HQP and NAA to sound better than having to use a switch.  To me the sound is more dynamic, energetic, and clear.  To achieve this, I had to establish a Bridge between my two NICs in my HQP pc.  I used this configuration for a while before upgrading to Server 2016 from Server 2012 R2.  Unfortunately, with Server 2016 there is no minimal server mode so I had to pick between installing the full GUI or use core mode.  In core mode, bridging of NICs is not possible so I had to reintroduce my Cisco SG300 SFP switch back into my system.  I kept trying to find a solution that would allow a direct connection and thanks to @Miska and @AudioPhil I've been able to do it.  Another benefit of this direct connection solution is that you dont have to go through the hassle of bridging your NICs.  The drawback of course is that you cannot remote desktop into the NAA to troubleshoot since its no longer on the local network.  No big deal, when I need to remote desktop into the NAA I just plug it back into my switch.

 

Anyway, here is the solution....

On both the HQP and NAA pc, enable IPv6*

IPv4 can be enabled as well

Use Task Manager to ensure the NICs on both pcs are receiving IPv6 addresses

Connect the NAA to the second HQP NIC

Restart both computers**

Go into HQP settings and select IPv6 as the backend.  Your NAA should show up in the drop down.

High five yourself, thank Miska and bask in the glorious sounds made possible by this direct connection!

 

*since I run in core mode, there is no GUI so I go into the registry to enable IPv6.  For some reason the Powershell and netsh commands to enable IPv6 wouldnt work for me.  The registry key is DisabledComponents found at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\.  Set it to 0 to enable IPv6 and 255 to disable it. (please be very careful when editing the registry, perform a backup first, I am not responsible, blah blah blah)

**I would check to make sure IPv6 is still enabled after a restart

 

Let me know if you have any questions.

[Hammer]

Hi, I'm trying to do the same thing on Server 2016 as my HQPlayer machine.  I have a NIC setup for ipv6 only and I am wondering how this NIC gets an ipv6 address if it is just directly connected to my NAA pc.  If I need to manually set an address, what should it be and do I need a Default Gateway?  Thanks, Hammer

[tboooe]

1 hour ago, Hammer said:

Hi, I'm trying to do the same thing on Server 2016 as my HQPlayer machine.  I have a NIC setup for ipv6 only and I am wondering how this NIC gets an ipv6 address if it is just directly connected to my NAA pc.  If I need to manually set an address, what should it be and do I need a Default Gateway?  Thanks, Hammer

i am also running Server 2016.  Once you enable IPv6 and connect that nic to another device like a router, switch or NAA, an IP address is automatically assigned.  Thats one of the benefits of IPv6, no need for DHCP.  Connect your NAA to HQP PC, go into Task Manager and check the Networking page to verify that there is an IPv6 address.  

 

I dont know if you are using AO or not, but you may want to check the registry entry I listed in my original post to ensure IPv6 is enabled.  I couldnt enable using Powershell or netsh commands.

[Hammer]

I see an ipv6 address for the NIC, but there doesn't seem to be any activity and HQplayer is not seeing the NAA under ipv6 dropdown box.  Any ideas?  Thanks!

[Hammer]

To clarify, I see the address on the server 2016 side.  I can’t tell on the NAA side since I am running Miska’s x64 NAA image....I believe that has ipv6 activated, right?  Thank you again!

[tboooe]

1 hour ago, Hammer said:

To clarify, I see the address on the server 2016 side.  I can’t tell on the NAA side since I am running Miska’s x64 NAA image....I believe that has ipv6 activated, right?  Thank you again!

You need to check on the NAA side if IPv6 is enabled.  I am no Linux expert but I think you can type ifconfig on the NAA to see if an IPv6 address shows up.

 

Assuming it is enabled on the NAA, try restarting the HQP pc then check HQP settings.

[simonklp]

On Wednesday, May 23, 2018 at 7:18 AM, tboooe said:

Use Task Manager to ensure the NICs on both pcs are receiving IPv6 addresses

Connect the NAA to the second HQP NIC

Restart both computers**

Go into HQP settings and select IPv6 as the backend.  Your NAA should show up in the drop down.

High five yourself, thank Miska and bask in the glorious sounds made possible by this direct connection!

 

*since I run in core mode, there is no GUI so I go into the registry to enable IPv6.  For some reason the Powershell and netsh commands to enable IPv6 wouldnt work for me.  The registry key is DisabledComponents found at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\.  Set it to 0 to enable IPv6 and 255 to disable it. (please be very careful when editing the registry, perform a backup first, I am not responsible, blah blah blah)

**I would check to make sure IPv6 is still enabled after a restart

 

Let me know if you have any questions.

Hi @tboooe, first of all, I must thank you so much for your kindness to share this solution of bridging HQPlayer and NAA without the switch under WS2016 Core. I had been successful to work in this way last night. However, I cannot work in this way again this morning. What I can remember is that after achieving this bridging, I had upgraded the AudiophileOptimizer from AO 2.20 beta 5 to the final release of AO 2.20.

 

When I found the bridging not working this morning, I had checked the registry key setting, and found that it changed from 0 back to 255. So, I had changed it back to 0 again. However, it still doesn't work.

 

In this case, could you please kindly advise what did you mean by "Use Task Manager to ensure the NICs on both pcs are receiving IPv6 addresses". How to check it out?

 

Thanks and regards, Simon

[tboooe]

9 minutes ago, simonklp said:

Hi @tboooe, first of all, I must thank you so much for your kindness to share this solution of bridging HQPlayer and NAA without the switch under WS2016 Core. I had been successful to work in this way last night. However, I cannot work in this way again this morning. What I can remember is that after achieving this bridging, I had upgraded the AudiophileOptimizer from AO 2.20 beta 5 to the final release of AO 2.20.

 

When I found the bridging not working this morning, I had checked the registry key setting, and found that it changed from 0 back to 255. So, I had changed it back to 0 again. However, it still doesn't work.

 

In this case, could you please kindly advise what did you mean by "Use Task Manager to ensure the NICs on both pcs are receiving IPv6 addresses". How to check it out?

 

Thanks and regards, Simon

I noticed the same thing too with AO.  I had to re-enable IPv6.  After you enable it, did you first restart the NAA then HQP PC?

 

In core, press CTRL + SHIFT + ESC to bring up the Task Manager.  Then select the Performance tab to see if your NIC is getting an IPv6 address.

 

BTW, do you think the music sounds better with this direct connection vs the switch?

[simonklp]

6 hours ago, tboooe said:

I noticed the same thing too with AO.  I had to re-enable IPv6.  After you enable it, did you first restart the NAA then HQP PC?

 

In core, press CTRL + SHIFT + ESC to bring up the Task Manager.  Then select the Performance tab to see if your NIC is getting an IPv6 address.

 

BTW, do you think the music sounds better with this direct connection vs the switch?

Hi @tboooe, I think I had started the NAA and then HQP PC. But it didn't work. Anyway, after I had removed the Ethernet cable from the network switch and then plugged into the LAN port of the HQP PC, then restart both NAA and HQP PC, the direct connection works again now.

 

The initial impression is that I felt the SQ of direct connection between NAA and  HQP PC is at least on par or slightly better than that by passing through the network switch. But since the difference was not day-and-night, I am not sure that the slightly better SQ was due to placebo effect.

 

Anyway, my appreciation for your kind sharing. Thanks and regards, Simon

[simonklp]

On Saturday, May 26, 2018 at 9:47 AM, tboooe said:

I noticed the same thing too with AO.  I had to re-enable IPv6.  After you enable it, did you first restart the NAA then HQP PC?

 

In core, press CTRL + SHIFT + ESC to bring up the Task Manager.  Then select the Performance tab to see if your NIC is getting an IPv6 address.

 

BTW, do you think the music sounds better with this direct connection vs the switch?

Hi @tboooe, after longer listening time, I tend to agree that the music sounds better with this direct connection vs the switch.

 

Although my above conclusion is largely based on memory, because I have not done many A/B comparison by switching back and forth between the direct connection and via-switch setups, I have got a much stronger feeling that direct connection gives more crystal clear SQ.

[Sevenfeet]

I hate to be the flaming bag of poo on the doorstep of this thread but it's discussions like this that make my skin crawl.  I love the whole audiophile hobby and yes, we chase a lot of minute changes and upgrades for the best sound.  But when it comes to delivery of data from one place to another, I have to call BS on much of this.  For those of us who work in network technology, the idea that digital sound can be affected by the transport of packet switched data is completely ridiculous.  Data begins in a buffer at the source, is broken up into packets and delivered to the destination and unravelled in another buffer.  At that point the destination software OS and software can do with it as it pleases.

 

It doesn't matter what mechanisms it goes through as long as the data isn't corrupted (and there are plenty of ways along the path to check for that happening and automatic mechanisms to compensate).  Given the logic of this thread, you might as well start debating the merits of differing network cards and their corresponding chipsets.  We already have snake oil like "audiophile grade" USB cables and Ethernet cables out there to take our money.  Think about it, if it's good enough for your hard drive, LAN or WAN where data precision is everything, it's good enough for listening to music off your server or far away from Tidal's servers.

 

Again, I love our hobby but we need to focus on things that actually truly affect the sound.  And whether the data path has a switch or not isn't it.

[Audiophile Neuroscience]

1 hour ago, Sevenfeet said:

I hate to be the flaming bag of poo on the doorstep of this thread but it's discussions like this that make my skin crawl. 

 

Is that a No vote ??

[jamesg11]

5 hours ago, Sevenfeet said:

I hate to be the flaming bag of poo on the doorstep of this thread but it's discussions like this that make my skin crawl.  I love the whole audiophile hobby and yes, we chase a lot of minute changes and upgrades for the best sound.  But when it comes to delivery of data from one place to another, I have to call BS on much of this.  For those of us who work in network technology, the idea that digital sound can be affected by the transport of packet switched data is completely ridiculous.  Data begins in a buffer at the source, is broken up into packets and delivered to the destination and unravelled in another buffer.  At that point the destination software OS and software can do with it as it pleases.

 

It doesn't matter what mechanisms it goes through as long as the data isn't corrupted (and there are plenty of ways along the path to check for that happening and automatic mechanisms to compensate).  Given the logic of this thread, you might as well start debating the merits of differing network cards and their corresponding chipsets.  We already have snake oil like "audiophile grade" USB cables and Ethernet cables out there to take our money.  Think about it, if it's good enough for your hard drive, LAN or WAN where data precision is everything, it's good enough for listening to music off your server or far away from Tidal's servers.

 

Again, I love our hobby but we need to focus on things that actually truly affect the sound.  And whether the data path has a switch or not isn't it.

I take it that you haven’t confirmed the above theory-propositions with some a-b listening?

[One and a half]

7 hours ago, Sevenfeet said:

I hate to be the flaming bag of poo on the doorstep of this thread but it's discussions like this that make my skin crawl.  I love the whole audiophile hobby and yes, we chase a lot of minute changes and upgrades for the best sound.  But when it comes to delivery of data from one place to another, I have to call BS on much of this.  For those of us who work in network technology, the idea that digital sound can be affected by the transport of packet switched data is completely ridiculous.  Data begins in a buffer at the source, is broken up into packets and delivered to the destination and unravelled in another buffer.  At that point the destination software OS and software can do with it as it pleases.

 

It doesn't matter what mechanisms it goes through as long as the data isn't corrupted (and there are plenty of ways along the path to check for that happening and automatic mechanisms to compensate).  Given the logic of this thread, you might as well start debating the merits of differing network cards and their corresponding chipsets.  We already have snake oil like "audiophile grade" USB cables and Ethernet cables out there to take our money.  Think about it, if it's good enough for your hard drive, LAN or WAN where data precision is everything, it's good enough for listening to music off your server or far away from Tidal's servers.

 

Again, I love our hobby but we need to focus on things that actually truly affect the sound.  And whether the data path has a switch or not isn't it.

 

The problem of noise on the taking a ride on data is the real problem. Buffers are immaterial, when the conducting medium, a cable, transmits noise and data from point A to B. The noise is not removed, it couples to audio circuits, creates a mess and travels back to the source. Less devices in the path, the less noise is coupled. If a switch is removed, all the better, a switch is a noise source due to the power supply used.

 

 

References

 

Screened and Shielded Cabling - Noise Immunity, Grounding, and the Antenna Myth Fundamentals of Noise Interference

 

4 ways in which noise can enter a signal cable and its control

 

Ground noise is a misunderstood problem of data networks

 

 

[Sevenfeet]

5 hours ago, One and a half said:

 

The problem of noise on the taking a ride on data is the real problem. Buffers are immaterial, when the conducting medium, a cable, transmits noise and data from point A to B. The noise is not removed, it couples to audio circuits, creates a mess and travels back to the source. Less devices in the path, the less noise is coupled.

5 hours ago, One and a half said:

 

The problem of noise on the taking a ride on data is the real problem. Buffers are immaterial, when the conducting medium, a cable, transmits noise and data from point A to B. The noise is not removed, it couples to audio circuits, creates a mess and travels back to the source. Less devices in the path, the less noise is coupled. If a switch is removed, all the better, a switch is a noise source due to the power supply used.

 

 

References

 

Screened and Shielded Cabling - Noise Immunity, Grounding, and the Antenna Myth Fundamentals of Noise Interference

 

4 ways in which noise can enter a signal cable and its control

 

Ground noise is a misunderstood problem of data networks

 

 

If a switch is removed, all the better, a switch is a noise source due to the power supply used.

 

 

References

 

Screened and Shielded Cabling - Noise Immunity, Grounding, and the Antenna Myth Fundamentals of Noise Interference

 

4 ways in which noise can enter a signal cable and its control

 

Ground noise is a misunderstood problem of data networks

 

 

 

Oh Puleeze!  Stop conflating things that happen in the analog world with the digital world.  Yes, they intersect and rely on each other for our communications.  But let me give you a quote from the ground noise article you reference:

 

"For an ideal interconnected system, the grounding wires from all of the interconnected equipment come from the same source, ensuring that, initially, they have the same voltage. No current flows in any of the ground wires, nor are they subject to any magnetic fields. This ensures that there can be no voltage drop along the ground wires. The result is that all points along all of the ground wires are at the same voltage, and no intersystem ground noise exists between devices attached at various points along the grounding system.

Unfortunately, significant electrical effects can prevent this ideal scenario from happening. In some cases, the deviation from the ideal can result in hardware damage and in corruption of data." [emphasis mine]

It's the corruption of data that is important here and NOTHING ELSE MATTERS.  For 45 years ever since Bob Metcalfe invented Ethernet, the way that we transmit digital data from place to place, be it across the room or around the globe has been remarkable consistent.  And it doesn't matter if the way the transmission happens is old style "thick" coaxial cable, thin coaxial cable, twisted pair cable (of varying speeds over the years) or wireless communications of all types.  Ethernet's principal is this: let's say you have a megabyte of data you need send from one computer to another.  You begin with a communications program that prepares the data for transport by placing it in a buffer first.  Then the program takes the first subsection of that data from the buffer and forms a packet with it.  A packet is just the original data plus additional metadata that describes it in a few key ways: the origin computer (a MAC address and TCP/IP address) and the destination address (again, a MAC address and TCP/IP address).  Finally, the packet gets a data checksum which is the key point here.  The data is checked with a mathematical formula that derives a number based on all of the data in the packet.  Then that checksum is written into the packet header itself.

Why is the checksum important?  Well at that point the packet is transmitted to the destination or an intermediary which then transmits it to a destination.  And that transport turns the data into electromagnetic signals either on a physical wire, wireless or maybe both on its way.  Yes, that is the ANALOG realm which you've pointed out can affect the signal.  So how do we know the data isn't corrupted?  The answer is that checksum.  Once the receiver on the other end gets the packet, its examined to check which origin it came from (MAC and TCP/IP address) and then it does the same mathematical algorithm on the packet data as what happened in the beginning.  If the checksum number matches what came in the packet, then the data is good and the data is then transferred to the buffer where it is then distributed to whatever program on the destination wanted it.

The checksum system has worked for 45 years and safeguards the data, making sure that nothing along the way corrupted it.  The checksum system also is counting on there being at least some occasional corruption along the way.  If the checksum doesn't match, then the destination can ask the origin for the packet to be resent....not the entire buffer of data, just the packet(s) that didn't make it intact.  This happens every day, silently to all kinds of data you use every day.  In the early days of what used to be called Arpanet, the transmission lines and modems responsible for the digital->analog->digital conversion weren't as good so errors happened.    Also, Ethernet was originally a "party line" system where a group of computers on a local network might end up interfering with each other's communication if they decided to transport simultaneously. The checksum system guarded against mistakes and had re-transmission built into the system.  These days the wired transmission world is far better with the advent of routers and switches meaning that there are only two parties on any given wire.  But the wireless world is just like Ethernet of old with different transmitters possibly communicating over one another on a given frequency, corrupting the transmission.  Ethernet's system of checksums and re-transmission keeps the entire system reliable.

So we come back to our little audiophile hobby where for decades we debated endlessly about the merits of how a particular capacitor, transistor, tube or other analog device reproduced the original analog signal.  It's easy to think that the digital world might work in the same way.  But ask yourself this:  if the world operated where data could get transformed in the most minute (bit level) form on its way to the destination, could you trust anything you rely on?  Your critical data on your hard drive (movies, photos, documents, music)?  The medical data when you visit the doctor or hospital?  What about the clinical trial data on that cancer drug your loved one depends on?  The data we use to run our cities, test our water and keep planes from crashing into each other or the ground?  How about the data our military and intelligence agencies rely on to keep us safe?  All of it relies on the same system Bob Metcalfe invented 45 years ago.  It works because it relies on an inviolable construct:  MATH.  And the only other thing a switch does is add to the delivery time of a packet, which is usually measured in milliseconds.  That's never a consistent variable in how your audio is presented unless the switch is broken (which in that case, you have bigger problems).

Don't waste your time and money on things that aren't true in any context that we depend on from local LANs to satellite communication.  We can debate the analog only layer, yes.  We can debate how @MIska's HQPlayer transforms digital data before transport or what DACs do to the digital data upon receipt as its transformed back to analog.  But debating the transport system that we rely on literally everything in our world as somehow magically transforming audio digital data is a fool's errand.

</flameoff>

[tboooe]

@Sevenfeet thank you so much for your input.  As an (ex) engineer myself I truly appreciate science, the data to explain things, and learning new things.  However, I've been in this hobby long enough to know that its really subjective and involves phenomena I dont even remotely comprehend.  Its these aspects about our whacky hobby that makes its so fun, interesting, and frustrating at the same time.  I personally enjoy reading different opinions and points of view but I let my ears make the ultimate decision.  I am fully aware that perhaps some of my perception of what I  think I am hearing is at least in some part influenced by confirmation bias, ignorance, etc.  At the end of the day, people will believe they hear whatever it is they think they do.  As long as they are enjoying the experimentation and ultimately how their music sounds thats all that matters.  

[One and a half]

@Sevenfeet , feel happier now? Neither of us will be swayed by either opinion, parallel thoughts rarely converge, leaving it at that.

[Miska]

Uh oh...

 

People, regarding Ethernet cables... Just remember to use UTP cables (ones with plastic connector housing) when connecting to NAA. Do NOT use STP cables (ones that have metal on connector housing), because this will likely break the ground isolation we want from the Ethernet (being otherwise transformer isolated). We generally don't want Ethernet cables to make ground connections between the networked devices. This is one of the main points for using Ethernet and NAA.

 

Unfortunately all audiophile network cables I've seen are STP type, so unsuitable for NAA use. I use plain standard CAT6 UTP cables (costs about 10€ for 2m piece).

 

Correct type of cable:

 

Incorrect type of cable:

 

[Sevenfeet]

8 minutes ago, One and a half said:

@Sevenfeet , feel happier now? Neither of us will be swayed by either opinion, parallel thoughts rarely converge, leaving it at that.

 

That's me, the flaming bag of poo on the doorstep.

 

Seriously though, this hobby is one of the most subjective pastimes I've ever seen.  It makes some sports nuts seem quite tame by comparison (and I'm one of those two having played Div I basketball).  And yes, we debate endlessly for decades on the merits of audio presentation.  And I do not pretend I know the eccentricities of what this circuit does to that analog signal path.

 

But I've worked for two different well known technology companies over the last two decades.  I've worked intimately on data networks since college.  And I'm pretty comfortable in my earlier thesis.  My point was say, stop spending your valuable time, energy and especially hard earned money (since it's completely moot) and worry about something else.

[Sevenfeet]

4 minutes ago, Miska said:

Uh oh...

 

People, regarding Ethernet cables... Just remember to use UTP cables (ones with plastic connector housing) when connecting to NAA. Do NOT use STP cables (ones that have metal on connector housing), because this will likely break the ground isolation we want from the Ethernet (being otherwise transformer isolated). We generally don't want Ethernet cables to make ground connections between the networked devices. This is one of the main points for using Ethernet and NAA.

 

Unfortunately all audiophile network cables I've seen are STP type, so unsuitable for NAA use. I use plain standard CAT6 UTP cables (costs about 10€ for 2m piece).

 

Correct type of cable:

 

Incorrect type of cable:

 

 

This advice isn't specific for audiophile networks.  Virtually all home and office twisted pair cabling should be the unshielded variety since that's the specified standard for 10/100/1000 base-T networks..  Shielded will work in most cases (short distance) but you can run into trouble in some cases.  Shielded is mainly used for specific circumstances in data centers.

[Miska]

3 minutes ago, Sevenfeet said:

Seriously though, this hobby is one of the most subjective pastimes I've ever seen.  It makes some sports nuts seem quite tame by comparison (and I'm one of those two having played Div I basketball).  And yes, we debate endlessly for decades on the merits of audio presentation.  And I do not pretend I know the eccentricities of what this circuit does to that analog signal path.

 

But I've worked for two different well known technology companies over the last two decades.  I've worked intimately on data networks since college.  And I'm pretty comfortable in my earlier thesis.  My point was say, stop spending your valuable time, energy and especially hard earned money (since it's completely moot) and worry about something else.

 

One of the reasons for NAA to exist is to allow galvanic isolation over high speed asynchronous FIFO buffered transport. Since for example USB by specification doesn't provide galvanic isolation, Ethernet is used as physical media because of two reasons:

1) Copper Ethernet is transformer isolated by the specification

2) There is various optical Ethernet networking gear available that provides even more isolation

 

This is not related to transferring bits around as such, this has more to do with analog electronics engineering.

 

In addition, building things on top of networking technologies provides various advantages, such as many-to-many connections, while USB is limited to point-to-point. So for example any HQPlayer computer in the house can access any NAA in the house. One can use even WiFi links if needed (missing cabling, etc).

 

P.S. I personally don't use point-to-point multi-homed Ethernet connections, I see no reason to do so and it is painful as things get complex and not designed to be used that way. I have now 6 switches around the house on the same network and NAA's and HQPlayer computers around the house too. And things work fine on the network.

 

[Miska]

1 minute ago, Sevenfeet said:

This advice isn't specific for audiophile networks.  Virtually all home and office twisted pair cabling should be the unshielded variety since that's the specified standard for 10/100/1000 base-T networks..  Shielded will work in most cases (short distance) but you can run into trouble in some cases.  Shielded is mainly used for specific circumstances in data centers.

 

Yes, that's what I've been repeating several times. When people ask me when they can use STP, my answer is generally that within a normal machine room 19" racks that are carefully grounded to a common ground using at least 4 mm2 copper wire and all equipment is powered through 3-pin IEC power from common power feed.

 

Certainly not for long distances, because it creates danger for large ground currents / voltage potentials (reason why there is the transformer isolation by design).

 

[Allan F]

On 6/4/2018 at 2:00 PM, Sevenfeet said:

But I've worked for two different well known technology companies over the last two decades.  I've worked intimately on data networks since college.  And I'm pretty comfortable in my earlier thesis.  My point was say, stop spending your valuable time, energy and especially hard earned money (since it's completely moot) and worry about something else.

 

And during your employment in network technology over the last two decades, how often would you listen to the data for its sound quality?

 

Nothing personal but, IMO, all you are doing is repeating the "bits are bits" argument that has been debated ad nauseum on this forum. Based on my own experience, I have to disagree rather strongly with those who insist that all USB cables sound the same, and that investing in better cables is spending money on snake oil.

[simonklp]

In fact, my network between HQPlayer and NAA was connected via fibre and fibre switch before direct connection via fibre is possible, i.e. eliminated the use of fibre switch via direct connection. Since I have been using the fibre network, I don’t think the improvement in SQ via direct connection relates to galvanic isolation or shielding of noise, because I believe I had already achieved it even with the fibre switch.

 

However, I still maintain my feeling that direct fibre connection gives a clearer or more definitive SQ than via the fibre switch. In this case, I would suspect or speculate whether it relates to the elimination of latency induced at the switch. But, again, I believe that it is another controversial topic!

[Sevenfeet]

On 6/9/2018 at 3:22 AM, Allan F said:

 

And during your employment in network technology over the last two decades, how often would you listen to the data for its sound quality?

 

Nothing personal but, IMO, all you are doing is repeating the "bits are bits" argument that has been debated ad nauseum on this forum. Based on my own experience, I have to disagree rather strongly with those who insist that all USB cables sound the same, and that investing in better cables is spending money on snake oil.

 

Hoy boy.  And this is why "audiophile grade" data cables exist.

 

Look, if there were truly data discrepancies in the transport layer of networking or USB that could affect sound like that, then all of the data on your hard drive, SSD and the very website you are reading for now would be completely corrupted.  This isn't magic.  The technology that you depend on to power your information world must be exact and correct for occasional errors precisely or else it doesn't work, period.  Videophiles don't make the same ridiculous arguments when trying to get the best picture out of their $5000 TV or $20,000 projector.  You can discuss ad infinitum about the things that actually transform the data.  In the video world, it's the compression ratio of the content and other factors.  In our world, it's what @Miska's HQ Player does during its transformation process before it gets to the USB cable (or the network to the NAA and then to the USB cable).  

 

But the transport layer must work, or it doesn't.  As long as your cabling is within spec, you are good.  Don't waste your precious time, energy and especially money on this when there are plenty of legitimate things in our hobby that you can worry about.