a) the phenomena you describe above (including Skin Effect) have been well understood regarding data transmission many years ago
b) despite many trials and material combinations, nobody was ever able to come up with a material which would overcome the physical phenomena you describe
c) as a result, the Ethernet PROTOCOL was designed (and has been refined many times since to overcome these physical limitations
d) it is the Protocol that ensures that correct data is transmitted and received.....data that is "very similar" is eliminated, with 'blanks' left.....so that the receiver easily knows that the data is corrupt and missing data
Lastly, I think that we agree that the use of the following can help with the reduction / elimination of RFI / EMI entering the Endpoint.......as RFI / EMI is known to have detrimental impact on the PCM processing within an 861 or MS600
a) a dedicated Switch for our Sooloos kit;
b) Shielded and Screened SSTP cable for all Sooloos transfers (even a good idea throughout the home network)
c) moving any Wifi Access points as far as possible away from our Endpoints to reduce ambient RFI
d) minimizing the use of Powerline Networking devices throughout our home networks and especially not using Powerline connections to Sooloos Endpoints [as they are known to introduce high RFI levels]
d) the use of Galvanic Isolation (GISO) may also assist when the above "prevention" methods are difficult
So, RFI mitigation and the methods to achieve that is likely something we can agree on
However, we may have to agree to disagree on the impact of Skin Effect, higher SNR or the other phenomena you mention on the Robustness and Integrity of Ethernet Data Transmission
Good discussion. The premise is that some people think they hear a difference. If that is true it is intriguing to know what might cause it.
A friend of mine who has no intention of buying an expensive network cable did tell me he heard very clear changes in SQ when the cables were swapped at a demo. He is level headed and quite techy. He has no idea why it would be different with audio over IP. I trust that he did hear differences.
Hi Nick Could he have heard differences between the cables??.........Most certainly
Could the differences heard be due to "suggestion" or placebo......Certainly, and applies to us all
Could I construct a test at a Show Demo that would ensure that people heard differences and would buy my Cables??.......Yes, quite easily in fact
Just ensure that you have a High RFI source within 2 feet......e.g. a Wifi 'Router' on or under the table......or have a mobile phone on the table, even better if it's sending / receiving data or in the middle of a call
Point is, these Demo's are constructed to show a difference and the Phenomena is understood by enough people to create an environment where 1 cable sounds superior to another ........making it easier to promote the Cable I'm trying to sell
I�ve previously explained how I was able to establish performance differences between an ID40 and ID41 in an 861v6 with v8 Firmware.
Use my network to generate high RFI levels (video streaming and file copying)... and take none of the �prevention� steps outlined above (separate switch, SSTP cable etc., etc.)... and then it was quite easy to hear a difference between the ID40 and ID41 (likely due to the Ferrite and other filtering built into the ID41, reducing RFI entering the 861v6).
However, reinsert the dedicated Switch and SSTP cabling reduced those observed differences to very little.
Bringing the Network activity and data transfers back down to a �normal' level, further reduced any differences to borderline negligible.
Summary RFI can be used in a test to make it appear like the Cable is the �saviour�.
But your friend can be reassured that the Streamed Music via Ethernet was being received 100% Intact and 100% Integral by the Endpoint... if it wasn�t then he would have heard obvious dropouts... not just perceived �differences".
This is is a case of even though it quacks like a duck and walks like a duck, it's still NOT a Duck
Meridian brand 2 different SPEAKERLINK Cables which just so happens to have a Construction identical to Shielded Ethernet cables with RJ45 connections.
These SpeakerLink cables are NOT promoted by Meridian as Ethernet cable... Russ Andrews says different of course... but then again, that is a whole different discussion regarding his methods and motives IMHO
SpeakerLink cables are used for the Balanced AES / EBU Digital Transmission of Data from e.g. a Source to Speakerlink DSP speakers.
Even though this is a potentially better transfer mechanism than SPDIF over Coax or Optical, as this is still a "One-Way" transmission... with NONE of the Error Correction or Packet Re-Transmission benefits which are described above.
Understand the confusion, but it's not promoted by Meridian for Ethernet use.
See how Meridian describe their SpeakerLink cable here.
In the interest of accuracy it does have the Meridian branding on it.
... great thread and great discussion, very very interesting.
With all due respect, it was bought out for speakerlink, not general purpose networking. Meridian showed their hands and stated they could hear differences in different speakerlink cables. That is quite different from networking which we are talking about. Just because you can use the cable for both applications it moot, you wont see it being marketed by Meridian as improving network data.
[edit]Ronnie beat me to it[/edit]
Last edited by Ian; 2014-09-1513:07.
Meridian owner since 1992 Prime & PSU, Focal Elear headphones, Roon (ROCK 8Gi5 NUC), Explorer 1 & 2, F80. 200/203, various Sonos (via Roon).
The SOLE purpose of the ID41 is make sure the received Data is IDENTICAL to what was sent���and to act as a �buffer tank� to allow that all necessary data to be re-transmitted from the Core and then re-assembled [in the correct timing order] so that it matches IDENTICALLY with what the Core sent
The ID41, despite its �1,000 cost, performs no other function within an 861��..it doesn�t Upsample or Apodize��.add any dither�..or perform any other processing, other than ensuring that Identical data is passed from the Core to the 861
If, even after multiple re-tranmissions, a time-out is exceeded, then the ID41 will simply ignore those �packets� and send the remaining data onto the 861
This means that if a Data packet was not identical, then there would simply be a �blank� in the sound replay���.which would be easily audible as a �dropout�
And it is because we don�t hear these �dropouts� that we know that the data received at the ID41 and passed to the 861 is identical to the data transmitted from the Core
I didn't realise that! Would a regular network card be able to carry out that function (potentially i.e. with the correct drivers)? Is there anything from technical perspective that warrants the extra expense?
Lastly, I think that we agree that the use of the following can help with the reduction / elimination of RFI / EMI entering the Endpoint.......as RFI / EMI is known to have detrimental impact on the PCM processing within an 861 or MS600
a) a dedicated Switch for our Sooloos kit;
d) the use of Galvanic Isolation (GISO) may also assist when the above "prevention" methods are difficult
I agree that this is a very helpful and informative discussion, particularly for someone like me who has no background in these matters and who is currently evaluating the GISO. As part of that evaluation it makes sense for me to try and address other issues that may be adding what the GISO appears to be filtering out. My current setup consists of a BT router connected to an older version of the Apple Airport Extreme. My Sooloos equipment is connected to the latter via shielded cables and the Airport also provides wi-fi for the iPad Meridian app and for the rest of the household gadgets (desktop and personal computers, ipads). Given a) above, would it be advisable in my setup to have a separate Switch just for the Sooloos equipment? How would this be connected up? If advisable, can someone please recommend a reasonably priced, quality Switch that does not itself add any nasties to Sooloos?
I assume you use the BT HH as effectively a modem and the AEBS as your router?
To connect a switch to an Airport Extreme you just connect your LAN cable to one of the 3 ports on the back and then connect the other end to your switch, there is nothing complicated about it, no configuration required.
Then connect all your Sooloos components to the remaining ports on the switch, as for choice of switch there are so many I can not advise you on what to select, personally I have an 8 port Cisco unmanaged switch that cost around �30.00 and has given me no problems.
as you are taking the (imho the correct way of proceeding) route of investigating fixing the underlying issues rather than putting a sticky plaster over them, once you put a switch in place, would you mind disconnecting the LAN link to the rest of your network and reporting on if you hear any differences?
This is only temporary as you will loose the ability to control Sooloos via iPad etc and of course, metadata services, but it will provide some feedback on how much noise is being introduced from outside (ie internet and wifi) the confines of a standalone dedicated Sooloos network.
You may find that you want to cue up some long playlists to give an extended listening test. Depending on what your other kit is, MSR transport controls may still work to allow you to go back and forward through the queue.
As for switches, most will be fit for the purpose, but I personally like Netgear Switches and use a mix of the cheaper plastic bodied switches and slightly more expensive metal bodies prosafe switches with option of grounding the chassis - just watch out for network speeds as Netgear do a mix of similar looking 10/100 and Gigabit versions. You should be able to find a nice little 5 port prosafe gigabit switch for about �20-30 but cannot recommend an exact model as Netgear have revamped their range since I last purchased.
Meridian owner since 1992 Prime & PSU, Focal Elear headphones, Roon (ROCK 8Gi5 NUC), Explorer 1 & 2, F80. 200/203, various Sonos (via Roon).