Jump to content
IGNORED

Ars prepares to put “audiophile” Ethernet cables to the test in Las Vegas


Recommended Posts

Red herring argument.

 

The idea that the cables could make a difference in the sound of the analog output of the system isn't based on the data being transferred incorrectly. Rather, that the data is transferred correctly but there are other factors (various types of noise) which do affect the analog output, and that these are affected by the use of different ethernet cables.

 

Noise. Is. Measureable. Period.

 

I agree with what you are saying 100%. First thing you have to show is that there is noise to be mitigated in the first place.

 

Any audiophile vendor should be able to produce measurements that show their cable vs another double shielded Ethernet cable where both pass spec.

Link to comment
Well, there's latency and then there is latency. In the sample you gave below, it could easily have been that the latency was caused by the processor on device 192.168.0.1 being slower, or much busier, than the processor on 192.168.0.102.

 

In general, I have sub millisecond pings to everything on my home network, save a Roku 3 box. That's true whether they are connected via ethernet, fibre, or wireless.

 

Can you rerun your test just changing out the Ethernet cable with one you want to test?

 

-Paul

 

There isn't latency and then there is latency. You either have more or less of the same thing.

 

I could test an AQ Ethernet cable but to what point (which I did awhile ago with a Vodka cable from Amazon)?

 

Are you stating that sub 1ms performance with zero loss is sub-par? I have a BJC CAT6 cable here (4 meter). I could hop on over to Best Buy and pick up an AQ cable but ping should be less than 1ms for both.

 

No argument from me that that a $500 NAS is going to outperform an $80 cable modem. But 2ms is 2/1000ths of a second.

 

And what if the AQ cable is also sub 1ms? It just means I have two well performing cables.

 

If you want let me know what testing you would like to see and will get either a Pearl/Cinnamon/Forest cable (whatever is available) and test out.

Link to comment
Red herring argument.

 

The idea that the cables could make a difference in the sound of the analog output of the system isn't based on the data being transferred incorrectly. Rather, that the data is transferred correctly but there are other factors (various types of noise) which do affect the analog output, and that these are affected by the use of different ethernet cables.

 

It's not a red herring as plissken was responding to this:

 

"That noise can affect the accuracy of the operation of the computer."

 

Given that, what he said is an entirely appropriate response. In the wider field of cable audibility reasons, maybe not, but you can't just pull a response out of the argument it was responding to.

Link to comment
There isn't latency and then there is latency. You either have more or less of the same thing.

 

I could test an AQ Ethernet cable but to what point (which I did awhile ago with a Vodka cable from Amazon)?

 

Are you stating that sub 1ms performance with zero loss is sub-par? I have a BJC CAT6 cable here (4 meter). I could hop on over to Best Buy and pick up an AQ cable but ping should be less than 1ms for both.

 

No argument from me that that a $500 NAS is going to outperform an $80 cable modem. But 2ms is 2/1000ths of a second.

 

And what if the AQ cable is also sub 1ms? It just means I have two well performing cables.

 

If you want let me know what testing you would like to see and will get either a Pearl/Cinnamon/Forest cable (whatever is available) and test out.

 

No, I think you may have made an invalid assumption here, assuming that the cable was the reason for the latency. I am not sure that the two tests say anything about the cables, just one machine is responding faster than the other.

 

Almost dead certain that the cable had nothing to do with the latency you showed. And certainly not at that magnitude! The difference is probably (almost certainly completely) because you went to different machines.

 

So yes, there are different kinds of latency; cable lengths can cause a change in latency, cable types, such as fibre vs copper, and much more commonly, routing delays or packet queuing delays, or just a busy processor in a host. The latency we saw here was either host, routing, or a combination of both. And more, the effects and magnitude of any amount of latency often depend upon their source. A latency of 5ms over the internet is great, but would be unacceptable in a LAN. :)

 

Also, you need to run a transfer speed test to get a better idea of how the link is performing. I admit, that is difficult to do to a router, since they generally don't have a lot of storage and you need to transfer 10gigs or so to get a good measure on a modern network.

 

What you can do to show any effect of latency by cable is to test two cables going to the same place from the same machine. Not to two different machines.

 

As it happens, I just happen to have a 3meter AudioQuest Cinnamon Ethernet cable here, and a "cable matters" 3 meter cable, and a 3 meter cable that came with some IBM gear.

 

Connected to two Mac Minis on my desktop, there is no electrical noise on the lines I can detect, and absolutely no difference in pings or in speed tests over the three different cables.

 

Which is what I would expect to see if you changed out a $12 ethernet cable for a $300 Audioquest Vodka. [Edit: I originally said $3 cable here, but even I won't buy $3 Ethernet UTP cables.)

 

Even though that is what I expect to see, I would very much like to see a difference of some kind. That would validate my friends who can hear differences via Ethernet Cable than I can neither hear nor detect.

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
OT - have you read Michael Lewis' "Flash Boys"?

 

Yes - and it does kindle intense outrage. We can't all be winners in a competitive business environment, but the devil's in the ethical and moral issues. How much unfair positioning for advantage should we tolerate as a society? How much (if any) loss by individual investors or consumers is acceptable when the deck is stacked so heavily against us by a sophisticated industry? Do they have the right to profit consistently by plying a strategy against which we have absolutely no defense? In my calmer moments, I do recognize that embracing capitalism and accepting a free market economy require the ability to accept losses with grace and dignity. But I don't think this includes a blanket tolerance for being ripped off.

 

This discussion is absolutely not OT in a thread about the high cost cable industry. Many people believe that securities traders and financial advisors are simply ripoff artists, so they manage their own investments. Many of my friends are in this camp, and far more of them have done badly than well because they perceived sound advice (wow - pun and double entendre!) from qualified professionals as profit-motivated hype. They try to understand complex derivatives and invest for the "big win", rather than following a rational plan based on realistic strategy guided by professionals whose track records show that they know what they're doing.

 

There are many intelligent and educated people who believe they are being ripped off by everyone with whom they deal. For example, many mistrust sommeliers and assume that wine lists are structured solely around profit. In truth, most places want you to come back again so they look for good wines at fair prices - and they mark them up according to their business policies, not "How much can I get away with?" The other end of the consumer spectrum is those who order by name or from the price column, trying to appear knowledgeable and worldly even though they haven't a clue what they're drinking. Buyers of high end audio cables fall within the same spectrum - some think any cable beyond OEM is a ripoff, and others buy because of what they think it says about them, even though they don't find any functional benefit. In the middle are the reasonable people who made intelligent choices in pursuit of truth, value, and big pleasure....and Audioquest wants them to be repeat customers, not one time buyers of an overpriced product in which they'll be disappointed.

 

Although I haven't personally discovered value in big dollar wires, I do believe that most who are designing and selling them are well intentioned and not trying to rip us off. Even if their relationship to sound quality runs from debatable to theoretical, the technical factors and observations that drive design and manufacture of these are most often real. I don't doubt that their creators strongly believe in what they've created. I simply don't believe that Cardas and Audioquest are knowingly making inflated claims for their products for the sole purpose of selling them to the insecure and unsuspecting audiophiles of the world. And the cost of the ones I've seen seems to be at least somewhat proportional to the cost of manufacture. They're not doing the cable-maker's equivalent of high speed trading to manipulate the market and make big bucks - most are crafting beautiful products in which they believe. There are no "victims".

 

When I have a chance to grab them at a great price, I do so, e.g. I have garden hose power cables on my electronics because one of the dealers had a huge sale last year. I don't hear any difference at all compared to the standard wires with which they came - but I made the effort and no one got hurt. Sadly, high speed trading brings me no benefit at all but has affected the value of some of my holdings over the years. There are victims.

Link to comment
No, I think you may have made an invalid assumption here, assuming that the cable was the reason for the latency. I am not sure that the two tests say anything about the cables, just one machine is responding faster than the other.

 

Almost dead certain that the cable had nothing to do with the latency you showed. And certainly not at that magnitude! The difference is probably (almost certainly completely) because you went to different machines.

 

So yes, there are different kinds of latency; cable lengths can cause a change in latency, cable types, such as fibre vs copper, and much more commonly, routing delays or packet queuing delays, or just a busy processor in a host. The latency we saw here was either host, routing, or a combination of both. And more, the effects and magnitude of any amount of latency often depend upon their source. A latency of 5ms over the internet is great, but would be unacceptable in a LAN. :)

 

Also, you need to run a transfer speed test to get a better idea of how the link is performing. I admit, that is difficult to do to a router, since they generally don't have a lot of storage and you need to transfer 10gigs or so to get a good measure on a modern network.

 

What you can do to show any effect of latency by cable is to test two cables going to the same place from the same machine. Not to two different machines.

 

As it happens, I just happen to have a 3meter AudioQuest Cinnamon Ethernet cable here, and a "cable matters" 3 meter cable, and a 3 meter cable that came with some IBM gear.

 

Connected to two Mac Minis on my desktop, there is no electrical noise on the lines I can detect, and absolutely no difference in pings or in speed tests over the three different cables.

 

Which is what I would expect to see if you changed out a $12 ethernet cable for a $300 Audioquest Vodka. [Edit: I originally said $3 cable here, but even I won't buy $3 Ethernet UTP cables.)

 

Even though that is what I expect to see, I would very much like to see a difference of some kind. That would validate my friends who can hear differences via Ethernet Cable than I can neither hear nor detect.

 

How about we change this discussion just a little. There are a number of us who have heard a difference after switching to optical ethernet. There are a few ways to do this, and these are well documented in the "network isolation" and "optical network configurations" threads. Since we are all picking the equipment up on Amazon/eBay, I don't think anyone here is making any money by promoting this, and perhaps that means less bias.

 

Would you be willing to compare optical and copper ethernet SQ? If you hear a difference then this would lend evidence that there is a difference to be heard.

Custom room treatments for headphone users.

Link to comment
No, I think you may have made an invalid assumption here, assuming that the cable was the reason for the latency. I am not sure that the two tests say anything about the cables, just one machine is responding faster than the other.

 

Almost dead certain that the cable had nothing to do with the latency you showed. And certainly not at that magnitude! The difference is probably (almost certainly completely) because you went to different machines.

 

I didn't make any assumptions. I did test however. The difference is in the computational power of the devices I pinged because everything else is same as far as the cable distance and switch. Load wise I think they both were at idle when I did this.

 

So yes, there are different kinds of latency; cable lengths can cause a change in latency, cable types, such as fibre vs copper, and much more commonly, routing delays or packet queuing delays, or just a busy processor in a host. The latency we saw here was either host, routing, or a combination of both. And more, the effects and magnitude of any amount of latency often depend upon their source. A latency of 5ms over the internet is great, but would be unacceptable in a LAN. :)

 

I totally get what you are saying. I was saying, all in, latency is latency. If you have too much then you need to find out if it's PHY, CPU Load, or cabling.

 

So we can agree the 5msec and under is fine for a small lan? So either of my ping results are golden. So this back to if there is no EMI / RFI what is a more expensive cable going to do vs a certified BJC, TrippLite, or other $10-15 CAT6(A) cable.

 

If this is audible while a DAC is playing nothing with the outputs un-muted then it's measurable. Either by scope or better yet microphone.

 

 

Also, you need to run a transfer speed test to get a better idea of how the link is performing. I admit, that is difficult to do to a router, since they generally don't have a lot of storage and you need to transfer 10gigs or so to get a good measure on a modern network.

 

That's a piece of cake to perform on a router. Just throw a computer on the WAN side and statically configure the addressing for the WAN port and the computer.

 

Make the WAN side 192.168.1.X the LAN side 192.168.0.X. Setup and FTP server or punch the firewall for SMB. \\192.168.0.X of the WAN machine to a mapped drive letter on the LAN and test away.

 

What you can do to show any effect of latency by cable is to test two cables going to the same place from the same machine. Not to two different machines.

Even though that is what I expect to see, I would very much like to see a difference of some kind. That would validate my friends who can hear differences via Ethernet Cable than I can neither hear nor detect.

 

I don't see how it would validate anything since I am seeing postulation that the audio is effected with the cable simply plugged in and sitting idle. That means if you played even a file off of local storage you will still have the detrimental effect applied.

Link to comment
How about we change this discussion just a little. There are a number of us who have heard a difference after switching to optical ethernet. There are a few ways to do this, and these are well documented in the "network isolation" and "optical network configurations" threads. Since we are all picking the equipment up on Amazon/eBay, I don't think anyone here is making any money by promoting this, and perhaps that means less bias.

 

Would you be willing to compare optical and copper ethernet SQ? If you hear a difference then this would lend evidence that there is a difference to be heard.

 

Go optical. It has provable and measurable benefits. I would like to compare optical to wireless however :-)

Link to comment
I'm not a disciple of high dollar cables, although I did hear a significant improvement when going from a 10' generic came-with-a-printer-a-thousand-years-ago USB cable to a 1/2M Audioquest Forest (which was probably because the old one was USB1 and suffered mechanical degradation from age and being used many times in many pieces of equipment). However.....

 

Ping rate is a measure of the round-trip transit time between the pinging computer and the target, so it includes transit through all devices, processing, conversions, cables etc and is proportional in some way to the physical distance between termini. IEEE spec RFC254 is the standard for measuring this, and 1 Gb TCP/IP ethernet should have a latency no greater than about 0.1 msec over the physical distance traveled by the signal. Video streaming requires at least a 10Gb net for optimum performance, which is a latency below 50 microseconds. For "low latency applications" like RDMA, the recommended spec is 3 to 5 microseconds. Traditional computer audio is not specifically mentioned in any description of "low latency applications" that I've seen, but AOE (sending digital audio over ethernet without TCP/IP) is treated as one.

 

So technically, 2 to 3 msec latency on a LAN is not low latency. And a range between 1 and 3 msec reflects high variance despite the miniscule durations involved. So I don't have any problem believing that cabling through which latency is cut from 1+ msec to 50 microseconds, with a commensurate reduction in variance, could affect sound quality. Whether it does or not is a different question - but functions like high frequency trading require true, real time latency at or below 5 microseconds. There's good evidence that true low latency improves the accuracy of high volume, high speed trading - so I don't see why it couldn't affect sound quality.

 

Obviously, one would have to stratify the total latency into segments for each component and process. But with top quality equipment, a long CAT run (even in a domestic setting) could significantly change network latency.

 

The resolution in the printouts was in terms of units of 1 msec. This is almost three decimal orders of magnitude greater than the contribution of cable delay. Most of the actual delay is in driver and operating system overhead, and there is a question of timer resolution as well. The printout contributes no relevant information to the discussion of sound quality.

 

Low latency is not required for most applications, just low variance on latency (a.k.a. packet jitter). This is even true for hard real time applications such as network clock synchronization, however in the network clock synchronization case the results will depend on the difference in delay between the two directions.

 

Low latency audio is only needed when interactive work is required. This includes telephony, video conferencing, studio over dubbing and (to a lesser extent) sound and video editing. High frequency trading requires low latency because one crook's application is interacting with another crook's application, trying to cheat by being faster. It is possible to build exchanges that are immune to low latency, but this doesn't happen because the markets are rigged and Wall Street owns the politicians. Low latency is also needed for sports broadcasts where betting is involved, again interaction between "players".

Link to comment
How about we change this discussion just a little. There are a number of us who have heard a difference after switching to optical ethernet. There are a few ways to do this, and these are well documented in the "network isolation" and "optical network configurations" threads. Since we are all picking the equipment up on Amazon/eBay, I don't think anyone here is making any money by promoting this, and perhaps that means less bias.

 

Would you be willing to compare optical and copper ethernet SQ? If you hear a difference then this would lend evidence that there is a difference to be heard.

 

(grin) That I can speak to, as I have optical fibre running around the house, supporting the SAN and such.

 

While I can detect no change at all in playback when streamed over copper or wireless, I can hear what is to me a significant difference over optical fibre ethernet. I think that has something to do with he driver software, but I have not had time (or energy) to pursue it much further than the 'Wow! that's cool..." stage.

 

What I have found startling is that with sufficient capable ethernet connections, music played from shared drives sounds better to me than music played even from SSDs or Flash. I say that with a caveat, that being I am not sure I am really hearing a difference here, though I believe I do. It might just be the coolness factor in this case, but I don't think so.

 

What is on my testing schedule next is iSCS w/10g over copper. This is actually getting cheap now. Fibre connected drives make the music sound fantastic to me - but of course, in that case I am booting off the SAN and all storage is on the SAN. I am hoping the same thing will be true with 10g over copper, because it is way easier to install and cheaper to setup.

 

You can count me on board for that. :)

 

Can you do a SAN of some kind over your optical connections? I suspect, based upon just my guy, that you will also find the sound a notable improvement, especially if you can configure to IPL off the SAN.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
I didn't make any assumptions. I did test however. The difference is in the computational power of the devices I pinged because everything else is same as far as the cable distance and switch. Load wise I think they both were at idle when I did this.

 

I misunderstood then- I was thinking you were saying the difference in ping times was caused by the cable. Certainly I agree the difference in ping times was in all probability, caused by the CPUs on the various devices.

 

I totally get what you are saying. I was saying, all in, latency is latency. If you have too much then you need to find out if it's PHY, CPU Load, or cabling.

 

So we can agree the 5msec and under is fine for a small lan? So either of my ping results are golden. So this back to if there is no EMI / RFI what is a more expensive cable going to do vs a certified BJC, TrippLite, or other $10-15 CAT6(A) cable.

 

Actually, for a small lan, I would be looking for what is going on at 2ms, but I am overcautious. Also, my wife has been known to throw things when the network at home slows down... ;)

 

I don't see how it would validate anything since I am seeing postulation that the audio is effected with the cable simply plugged in and sitting idle. That means if you played even a file off of local storage you will still have the detrimental effect applied.

 

Well, that's where we don't expect the same results. I do not expect a cable with no transmissions on it to have measurable noise on it, save for it being in a very harsh environment. At which point, some kind of shielding would be called for. Need to have two totally idle cards, connected to a network with no broadcasts on the network to test that, which isn't hard, just not normal. :)

 

Again, I misunderstood your original posting. Apologies.

 

-Paul

Anyone who considers protocol unimportant has never dealt with a cat DAC.

Robert A. Heinlein

Link to comment
(grin) That I can speak to, as I have optical fibre running around the house, supporting the SAN and such.

 

While I can detect no change at all in playback when streamed over copper or wireless, I can hear what is to me a significant difference over optical fibre ethernet. I think that has something to do with he driver software, but I have not had time (or energy) to pursue it much further than the 'Wow! that's cool..." stage.

 

What I have found startling is that with sufficient capable ethernet connections, music played from shared drives sounds better to me than music played even from SSDs or Flash. I say that with a caveat, that being I am not sure I am really hearing a difference here, though I believe I do. It might just be the coolness factor in this case, but I don't think so.

 

What is on my testing schedule next is iSCS w/10g over copper. This is actually getting cheap now. Fibre connected drives make the music sound fantastic to me - but of course, in that case I am booting off the SAN and all storage is on the SAN. I am hoping the same thing will be true with 10g over copper, because it is way easier to install and cheaper to setup.

 

You can count me on board for that. :)

 

Can you do a SAN of some kind over your optical connections? I suspect, based upon just my guy, that you will also find the sound a notable improvement, especially if you can configure to IPL off the SAN.

 

-Paul

 

Yes that is exactly the idea, iSCSI boot and eliminate the SSD entirely. I was looking at 10g copper but not only is it more expensive, also requires alot more power than optical at 10g. I have a Brocade VDX6720-24 off ebay for ~$1k. Mellanox connectx-2 10g sfp nic cards are running $24-40 (!!). Cables and SFP modules are a few bucks. These prices are just crazy.

Custom room treatments for headphone users.

Link to comment
I misunderstood then- I was thinking you were saying the difference in ping times was caused by the cable. Certainly I agree the difference in ping times was in all probability, caused by the CPUs on the various devices.

 

Yep, I suspected we were speaking about the same thing.

 

 

Actually, for a small lan, I would be looking for what is going on at 2ms, but I am overcautious. Also, my wife has been known to throw things when the network at home slows down... ;)

 

The 2ms was my router which has two things going against it versus my NAS:

 

Lesser CPU / NIC and most likely sees more random traffic due to WSUS server I have setup for pulling updates.

 

Plus in all fairness my NAS has both GB NICS in a LAG Team.

 

 

Well, that's where we don't expect the same results. I do not expect a cable with no transmissions on it to have measurable noise on it, save for it being in a very harsh environment. At which point, some kind of shielding would be called for. Need to have two totally idle cards, connected to a network with no broadcasts on the network to test that, which isn't hard, just not normal. :)

 

-Paul

 

Others postulated that the compromised sound is there if the Network cable is simply plugged in and the actual data is stored locally.

 

I'm still not sure why people that state this won't fully engage in explorative conversation about that.

 

My NAS is setup as an ISCSI target for my servers and SMB for my client computers.

Link to comment
This will be entertaining:

 

Ars prepares to put

 

And starting out with a clear and biased objective as opposed to objectivity, I have no doubt that they will provide "proof" that the skeptics are correct, "proof" that IMO will be of value to nobody but the skeptics.

"Relax, it's only hi-fi. There's never been a hi-fi emergency." - Roy Hall

"Not everything that can be counted counts, and not everything that counts can be counted." - William Bruce Cameron

 

Link to comment
And starting out with a clear and biased objective as opposed to objectivity, I have no doubt that they will provide "proof" that the skeptics are correct, "proof" that IMO will be of value to nobody but the skeptics.

 

vs.

 

That's standard for any test of a null hypothesis. If you can produce a statistically robust counterexample (one person who can pass the test multiple times, or large numbers of people that can past the test a single time), you have evidence that the null hypothesis is wrong.

 

If not, you cannot really conclude anything about the veracity of the null hypothesis (apart from the observation that you haven't yet refuted it). There is no inductive proof, only falsification via counter-example.

Link to comment

Low latency is not required for most applications, just low variance on latency (a.k.a. packet jitter). This is even true for hard real time applications such as network clock synchronization, however in the network clock synchronization case the results will depend on the difference in delay between the two directions.

 

Low latency audio is only needed when interactive work is required. This includes telephony, video conferencing, studio over dubbing and (to a lesser extent) sound and video editing. High frequency trading requires low latency because one crook's application is interacting with another crook's application, trying to cheat by being faster. It is possible to build exchanges that are immune to low latency, but this doesn't happen because the markets are rigged and Wall Street owns the politicians. Low latency is also needed for sports broadcasts where betting is involved, again interaction between "players".

 

Well stated. Most people don't understand what they end up quoting unfortunately.

Low latency is critical for real-time performance. Listening to audio files isn't low latency because the file itself isn't real time.

 

It's one thing to stream a band playing live. It's a WHOLE other world to record that same band and play back later.

Link to comment
Yes - and it does kindle intense outrage. We can't all be winners in a competitive business environment, but the devil's in the ethical and moral issues. How much unfair positioning for advantage should we tolerate as a society?

 

Rigged, I tell you: instinet, pre-market, after hours, prime access to insider info and so much more, whereas we get hit with PDT and SSR rules, misdirecting analysts upgrades while they dump their shares, and much more. (Very OT)

Dedicated Line DSD/DXD | Audirvana+ | iFi iDSD Nano | SET Tube Amp | Totem Mites

Surround: VLC | M-Audio FastTrack Pro | Mac Opt | Panasonic SA-HE100 | Logitech Z623

DIY: SET Tube Amp | Low-Noise Linear Regulated Power Supply | USB, Power, Speaker Cables | Speaker Stands | Acoustic Panels

Link to comment
So this back to if there is no EMI / RFI

 

That's a major assumption, more like MAJOR assumption. And not very realistic.

 

Just throw a computer on the WAN side and statically configure the addressing for the WAN port and the computer.

 

Make the WAN side 192.168.1.X the LAN side 192.168.0.X. Setup and FTP server or punch the firewall for SMB. \\192.168.0.X of the WAN machine to a mapped drive letter on the LAN and test away.

 

Listening to native DSD256 on an old XP machine accessing an external HDD connected to an iMac in that very type of configuration while writing this, with Ethernet linking the two computers through a Linksys router with a hacked DD-WRT firmware. Sounds great :P

Dedicated Line DSD/DXD | Audirvana+ | iFi iDSD Nano | SET Tube Amp | Totem Mites

Surround: VLC | M-Audio FastTrack Pro | Mac Opt | Panasonic SA-HE100 | Logitech Z623

DIY: SET Tube Amp | Low-Noise Linear Regulated Power Supply | USB, Power, Speaker Cables | Speaker Stands | Acoustic Panels

Link to comment
That's a major assumption, more like MAJOR assumption. And not very realistic.

 

Just for clarification. It's not an assumption I've made or am making. It's one I have seen made by others in relation to why there is a difference in audio performance.

 

And when I ask the obvious question if the performance is affected when playing out of buffer and you are plugging in and removing the cable whilst playing does the performance stay the same or change. I've yet to get a straight answer out of anyone. Almost like a bulb went on in their head and they are a bit embarrassed.

Link to comment
Just for clarification. It's not an assumption I've made or am making. It's one I have seen made by others in relation to why there is a difference in audio performance.

 

And when I ask the obvious question if the performance is affected when playing out of buffer and you are plugging in and removing the cable whilst playing does the performance stay the same or change. I've yet to get a straight answer out of anyone. Almost like a bulb went on in their head and they are a bit embarrassed.

 

Easy test to do. If you want it to be valid, you should pull the AC power from your computer/file server and all your Ethernet switches/hubs/routers at the same time. The hard part is interpreting any differences you may hear, since you will be comparing different portions of the recording. (This can be avoided by the creation of the appropriate test files which consist of the same musical selection duplicated twice, interspersed with a slight pause to all for disconnections.)

 

This assumes that your rendering device has a sufficiently large buffer for the network I/O to capture useful amounts of audio.

Link to comment
Easy test to do. If you want it to be valid, you should pull the AC power from your computer/file server and all your Ethernet switches/hubs/routers at the same time. The hard part is interpreting any differences you may hear, since you will be comparing different portions of the recording. (This can be avoided by the creation of the appropriate test files which consist of the same musical selection duplicated twice, interspersed with a slight pause to all for disconnections.)

 

This assumes that your rendering device has a sufficiently large buffer for the network I/O to capture useful amounts of audio.

 

What does pulling A/C power on Server and Switches do that unplugging the Ethernet cable doesn't do? In effect it does the same thing: Removes a possible source of noise. That's all I'm after troubleshooting and theory wise at this point.

 

2nd you can adjust the WASAPI buffer via registry up to 20 seconds I believe. But using JRiver it's default is 6 seconds and easily adjustable.

 

Also JRiver has a feature to fill up to 1GB of RAM and start playing out of RAM. So a GB connection will xfer a 650MB CD (1411 bitrate) in about 7-8 seconds.

 

You can then un-plug/plug as much as you like for say the next 50 minutes or so.

Link to comment
What does pulling A/C power on Server and Switches do that unplugging the Ethernet cable doesn't do? In effect it does the same thing: Removes a possible source of noise. That's all I'm after troubleshooting and theory wise at this point.

 

2nd you can adjust the WASAPI buffer via registry up to 20 seconds I believe. But using JRiver it's default is 6 seconds and easily adjustable.

 

Also JRiver has a feature to fill up to 1GB of RAM and start playing out of RAM. So a GB connection will xfer a 650MB CD (1411 bitrate) in about 7-8 seconds.

 

You can then un-plug/plug as much as you like for say the next 50 minutes or so.

 

Ethernet cables act as antennas. They may radiate noise from powered up boxes connected to them.

 

If one is going to bother to perform experiments I suggest conducting controlled experiments. The first step is to create a proper experimental design and this will require as a prelminary step becoming familiar with all of the known or suspected factors that might influence results.

Link to comment
Ethernet cables act as antennas. They may radiate noise from powered up boxes connected to them.

 

If one is going to bother to perform experiments I suggest conducting controlled experiments. The first step is to create a proper experimental design and this will require as a prelminary step becoming familiar with all of the known or suspected factors that might influence results.

 

Pulling the cable while playing back gives you that result without the effort.

Link to comment
High frequency trading requires low latency because one crook's application is interacting with another crook's application, trying to cheat by being faster

:) !

 

But Cisco has published evidence that ultra low latency also reduces the incidence of actual errors.

Link to comment
Pulling the cable while playing back gives you that result without the effort.

 

Pulling the cable closes one known path for coupling digital noise into sensitive analog components. It does not close other paths, which include radiation from cables and coupling through power wiring. That is why just disconnecting one cable is an improper experimental procedure, unless of course it is one part of a systematic series of tests (multi-factor experimental design).

 

If you doubt that computers create electronic noise, just get an AM radio and bring it nearby a computer that is powered up.If you doubt that audio equipment is affected by electronic noise, try sending a text message to a cell phone that is operating close to your equipment, etc...

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...