AUDIO over IP - REDNET 3 & 16 Review. AES67 Sets A New Standard for Computer Audio

Jun 21, 2016 at 10:42 AM Post #526 of 3,694
I also think that matrix screen really stumps folks - but I found it intuitive - my hang up was just getting the DC screen up.  I checked the manual and saw to find the dialogue box to open Dante Controller you just right click the front of the Virtual RN face.
 
The little wrench button to change the ADAT/AES-SPDIF outputs and clock source.
 
Important!  Be sure to set the clock source to INTERNAL!  Not SPDIF!  Unless using an ext Word Clock of course.
 
On that matrix screen just be concerned with 01 and 02 - all the others ignore.  When you get the green checks on the connection matrix you are good to go!
 
Most important:

 
Jun 21, 2016 at 10:51 AM Post #527 of 3,694
  For setting 176Khz use the Dante Controller SW and not the RedNet Control SW. For some reason (at least in my set-up), the RedNet Control SW is missing 176Khz. However, I just went to JRMC and was able to upsample to 176Khz without any problems.
 
 

Your 150 usec 'Device Latency' is grayed out as well.  Mine isn't - and that's what I use.
 

 
Jun 21, 2016 at 11:23 AM Post #529 of 3,694
  Yes the inherent communication protocol - total absence of a analog like wave form - or should I say 'signal intregrity' issues that require AGC schemes.  You should be right  - but then why do STP ethernet cables exist at all?  As you are in the tech field maybe can help understand a little about this.
 
One major attraction of AOIP was the doing away with all the USB gizmos and gadgets.  So not super keen on adding more to the AOIP chain - but if it does improve the SQ well by all means.   Coolness can mean snake oil to some folks:
http://www.ebay.com/itm/111931217341?_trksid=p2060353.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT
 
Will know Friday on the effect of optical ethernet on the SQ in my systems.!

 
http://www.techrepublic.com/blog/data-center/some-interesting-twists-about-ethernet-cabling/
 
STP is for extreme cases. If you have that much potential for interference in a home environment, you're going to have much bigger issues with interference and noise in other parts of the system.
 
From a data standpoint:
 
Every packet is checksummed and re-transmitted if there are failures. If a packet starts off with X data, and the checksum passes at the other end, then the *exact* data got there, period. If there are packet re-transmits and packet loss, that will show up - you can monitor the interfaces for that, though in practice if you're just running a 2-channel audio stream you'll probably never even notice since you're using such a small portion of the available bandwidth.
 
We run 10Gb to full saturation over copper and fiber, some of our systems will happily saturate 40Gb LACP trunks. In all cases those cables are run through racks and under floors with literally thousands upon thousands of other cables both for data and power. If we see even a small amount of packet loss, it is immediately noticeable. In almost every case the issue is at one of the endpoints, not the cable itself. GBICs go bad, switch ports or line cards have issues, NICs fail. Rarely, if ever, is it due to an issue with the cabling, and when it is it is most likely at one of the connectors, physical damage along the way or a cable that fails spec.
 
I'll say it again, in a home network, running tiny amounts of data across cable that has specs which far exceed anything you'll put through it, interference is not going to be an issue.
 
From an analog "noise" standpoint:
 
If by some chance there is noise picked up in the cable that doesn't impact the integrity of the packets - it is electrically isolated from the end point by design. Even if you're using the fibre converters, the remote end converts back to copper and is then isolated at the NIC port.
 
Most likely the change in sound is coming from the 2 additional steps of conversion to/from copper. I haven't heard that myself, so I won't make any claim to whether that is better, worse or just different, but most likely it's something in the conversion.
 
  -Mike
 
Jun 21, 2016 at 11:27 AM Post #530 of 3,694
Didn't your Rednet arrive with the update already applied? You can check what you have, if you've never applied an update most likely you have 3.7 already programmed in. The older is 3.4 iirc

Correct, you'll want a newer machine even if your older pc is capable of 24/192khz over usb or is seemingly fast with multitasking jobs. Quad core 1.7ghz i7
+1 That's why I think it might be better to just get it working with the shipped firmware.

You had an issue with an older WIN machine not getting 192k only 96k on your RN3 right?  It was a 7 yr old Dell laptop I think.

So maybe a warning to folks with older machines that might be an issue.

Also with the DVS being s/w based the SQ may not be as good as on a more powerful new machine.   Mine is a Haswell iCore 7 4790, WIN10.
 
Jun 21, 2016 at 11:37 AM Post #532 of 3,694
Didn't your Rednet arrive with the update already applied? You can check what you have, if you've never applied an update most likely you have 3.7 already programmed in. The older is 3.4 iirc

Correct, you'll want a newer machine even if your older pc is capable of 24/192khz over usb or is seemingly fast with multitasking jobs. Quad core 1.7ghz i7


No it had the old firmware - yes 3.4.1 was the original.  I check that before updating -so I could rollback if need be.
 
Jun 21, 2016 at 11:41 AM Post #533 of 3,694
 
I see - thanks! 

 
 
I just updated the post to add some more info.  For the argument that it's audio and not data, the reality is that it IS data. We are not sending analog signals across these cables. Ethernet does not care what's in the packet. As long as the packet is structured correctly and the checksum passes, the data is exact. If even one bit is off in the packet the checksum will fail.
 
Jun 21, 2016 at 11:47 AM Post #535 of 3,694
   
 
I just updated the post to add some more info.  For the argument that it's audio and not data, the reality is that it IS data. We are not sending analog signals across these cables. Ethernet does not care what's in the packet. As long as the packet is structured correctly and the checksum passes, the data is exact. If even one bit is off in the packet the checksum will fail.

 
Exactly. I monitor my switch at home and have never had a single packet fail. I think the audio/data difference arises in people's mind possibly because USB Audio transmits audio as data with CRC but upon failure does not retransmit errors, making possible the chance of interference etc affecting the data integrity. As Ethernet as you point out would retransmit any failed packets immediately thus preserving data integrity, it's a non-issue. Happy to be corrected if I'm wrong...
 
Jun 21, 2016 at 12:06 PM Post #538 of 3,694
I get my data direct from the engineers who design things. But anyways my DAC discussion days are over around here. A better place for that is on my own forum if anyone has questions.
 
Jun 21, 2016 at 12:28 PM Post #539 of 3,694
 I monitor my switch at home and have never had a single packet fail.

 
Hi,
With respect, - and I don't wish to belabor the point here too much: this doesn't have anything to do with failed packets, or data integrity. What it's about is the accurate transmission of packets in TIME. It's all about timing, & the more accurate the clock at both the sender and receiving end, (DAC), - the less "work" the DAC's clocks do in cleaning up the signal. This is similar (if you think about it) to disc spinners: - software/firmware error correction doesn't do the job with wobbly discs, and wimpy motors. The VRDS NEO transport with its magnesium disc clamping mechanism & beefy motor "proves" that a great transport improves the SQ, - & substantially. 
A faster cable (10GB) fiber that has galvanic isolation sounds better than a CAT 5e, due to its speed, carrying "less" noise, & perhaps even conducting less vibration. CAT7 cable with CAT6a connectors with it's "higher" specs also sounds better than CAT5e. (Another test is try plugging in an EMO EN-30 Isolator.
 
https://www.amazon.com/gp/product/B00OL54Y7U/ref=ox_sc_sfl_title_23?ie=UTF8&psc=1&smid=A3DA2BLSV4J2D1
 
Personally, I have never used the SMPS wall-warts that came with my MC200s. I got some $12 LPSs from JameCo. I heard differences with all 3 cable types.
 
I would suggest trying fiber to hear for yourself, - if no difference, - you lose almost nothing. A 30ft fiber run with two FMCs costs less than $150.
 
Cheers,
 
Jun 21, 2016 at 12:48 PM Post #540 of 3,694
   
Hi,
With respect, - and I don't wish to belabor the point here too much: this doesn't have anything to do with failed packets, or data integrity. What it's about is the accurate transmission of packets in TIME. It's all about timing, & the more accurate the clock at both the sender and receiving end, (DAC), - the less "work" the DAC's clocks do in cleaning up the signal. This is similar (if you think about it) to disc spinners: - software/firmware error correction doesn't do the job with wobbly discs, and wimpy motors. The VRDS NEO transport with its magnesium disc clamping mechanism & beefy motor "proves" that a great transport improves the SQ, - & substantially. 
A faster cable (10GB) fiber that has galvanic isolation sounds better than a CAT 5e, due to its speed, carrying "less" noise, & perhaps even conducting less vibration. CAT7 cable with CAT6a connectors with it's "higher" specs also sounds better than CAT5e. (Another test is try plugging in an EMO EN-30 Isolator.
 
https://www.amazon.com/gp/product/B00OL54Y7U/ref=ox_sc_sfl_title_23?ie=UTF8&psc=1&smid=A3DA2BLSV4J2D1
 
Personally, I have never used the SMPS wall-warts that came with my MC200s. I got some $12 LPSs from JameCo. I heard differences with all 3 cable types.
 
I would suggest trying fiber to hear for yourself, - if no difference, - you lose almost nothing. A 30ft fiber run with two FMCs costs less than $150.
 
Cheers,

 
I completely understand what's being discussed...
 
A few things, also with respect. The cable itself has no "speed" - a 10g spec cable isn't going to do any more or less on a 1g network than 1g.
 
Per the other Mike, from previous posts, clocking doesn't matter in this case as long as the data gets there intact, due to the way it's handled. 
 
I do plan to try fiber if for nothing else than to hear (or not) the changes for myself - which is why I haven't and won't comment on what they may or may not be - there would be no validity to my comments if I did. What I am saying is that I think if there are changes it is most likely due to the conversion. Not to mention, if timing is so critical with this tech, adding extra conversion steps would skew that, I would think.
 

Users who are viewing this thread

Back
Top