[Jake2]

10 is the lucky number. Let it be rolled like it is in the package when you receive it. Just connects the ends to the units.



Numbers means nothing. If you like the sound you like it because you like it. Numbers has no influence of judgement to the objective ear....MUSIC.
There is only one place where numbers matters or have the theoritcal effect in fiber. Distance = The reason for inventing fiber in the first place.

Not quite sure I agree that specs - especially these specs - can mean nothing, but agree there’s often poor or nil correlation between a ‘better’ measurement and perceived sound quality, musical enjoyment. Case in point the Mini-circuits clock cable I ordered based on specs (very high RL and shielding attenuation, both in dB) a year back was a distant fourth best sounding, dry and edgy, incl behind a super cheap AliX LMR400 style cable. For me measurements are just another data point, albeit a lowly weighted one vs other folks’ or better yet my first hand impressions of an item’s sound. In the case of clock cables the most valuable input by far, short of first hand listening, was other users experiences and recommendations.

Anyway.. back to the item being discussed - optical cables - given the significant difference in measured RL performance, which is at least theoretically potentially beneficial - and the negligible additional cost (another $10 per cable), it’s absolutely worth it to me to give em a go to hear for myself if there is an audible benefit in my system. If not, no dramas, the cost of these cables are rounding errors vs my/our other cables let alone the overall cost of our systems. It’s clear from my experimentation to date that FMCs and SFPs can vary a lot in their effect on a system’s sound. Btw I swapped the order of the Afterdark Rosanna (still moonlighting as an FMC with its streamer board switched off) and Teradak FMC around a few times again last night (with Finisar 1318 + Corning cable in between) and boy does my system sound better with the Rosanna downstream - closer to the DAC. More refined (less grain in the treble and midrange) and resolving with a touch more body too.

Those high RL cables @TRHH linked to are back-ordered to May. If/when I get some I’ll update this thread with my impressions.

 

[NikBales]

Now is as appropriate of a time as ever! I actually performed this swap myself and found it worthwhile on the Netgear gs108:
I swapped the cap right after the dc input to an AudioNote Kaisei and it made the sq more spacious and refined. I found it to be a bit flabby earlier on but that settled after several days. This was done to a pair of switches, powered by a Sean Jacobs DC3.

Hi, what are the specs of the cap??

 

[OCC7N]

Another great topic to discuss is the way data is being stored/cached before it hits the D/A.

(This is the reason I would like to experiment with Dante between file and playback.)

Same computer: Foobar2000 vs Youtube/browser

Playing files from NAS/Foobar2000 I can hear difference between cables but not in the source that much(belief) from youtube.

Foobar2000 is installed on same source.

The way softwares process data is important.

*cables I mean ethernet cables

 

[Jake2]

What do you think about starting a thread about the LHY UIP? You have some experience with this device.
Thx

As requested sir!

https://www.head-fi.org/threads/lhy-uip-usb-audio-isolator.972463/

Mostly just placeholders for now, but I've also rounded up a couple of other UIP owners who will share their impressions in due course.

 

[OCC7N]

@cpurdy Could you enlighten me on ARP and other broadcast/multicast protocols, for better network communication and less collision/congestion?
-I want to know if there is something that I am missing.

 

[cpurdy]

@cpurdy Could you enlighten me on ARP and other broadcast/multicast protocols, for better network communication and less collision/congestion?
-I want to know if there is something that I am missing.

Do you have network issues? That's the first and most important question. And if you do, how do they appear, i.e. what symptoms show up?

I haven't worked directly with (i.e. implemented / consumed) ARP traffic, so I have to take a pass on that one. (ARP no relationship to ARPA i.e. ARPAnet, even though they were coincident.) ARP is an old protocol, so I'm sure it's very conservative by modern standards. It's low level ("link layer"), so you're not typically going to meet anyone who has ever had to interact with it, unless they build switch firmware etc.

I have a lot of experience with multicast protocols. I designed and implemented TCMP (see https://xkcd.com/269/ ) back in 2001, which was a mixed unicast/multicast protocol for server clustering. Relatively few things in the home use multicast and broadcast traffic, though. High throughput datagram protocols (e.g. multicast and broadcast) can be very destructive to other traffic on the network, because flow control is a hard thing to get right; it took us a few versions of TCMP to get it right. At any rate, you'll probably only have a tiny bit of multicast/broadcast/anycast traffic on your home network. Bonjour (Apple) uses a little bit, for example.

Most homes are probably more than sufficiently served with a gigabit wired network: The per port prices are very cheap, and it takes a lot of effort to chew through that much bandwidth, even with video streaming (I use Plex for example). Most protocols are on TCP/IP, which has exponential back-off on collision, so it auto modulates (this is "flow control") to deal with things like congestion. You can see some of the stats for packet loss etc. if you dive deep enough into your OS. The numbers of lost packets when connecting on a wired network at home should be tiny; connecting to services on the Internet will likely drive those numbers up, but those losses are almost certainly occurring outside of your home. Lost packets aren't a problem for TCP/IP; as long as anything at all is getting through, the protocol will adjust and not lose any data.

The biggest collision/congestion problems in the home tend to be related to WiFi, not wired Ethernet, and it's not usually a bandwidth problem as much as it is a distance/obstacle problem. WiFi signals degrade by the 3rd power with distance, and the higher the frequency, the more they degrade when going through floors and walls. Ideal WiFi connections are unobstructed line-of-sight, with relatively short distances. So the "mesh" WiFi networks (I like Deco by TPLink) are a pretty compelling choice, because you can sprinkle them strategically throughout a home or business, with Ethernet wired connections between the WiFi access points.

The other problem with WiFi is that everyone has it, so if you're in an apartment in New York, you'll see 400 other WiFis, and you can imagine how much noise there is on those channels. I use a product called WiFi scanner (e.g. runs on MacOS) that shows me what WiFis are using what channels, and various SNR data, so I can configure each access point to use an optimal channel. WiFi access points supposedly can do this all themselves, but they used to be very bad at it; at some point, it's going to be better to trust them to self-configure than to manually configure them, but I'm not sure if we have already passed that point or not.

Fortunately, when it comes to music transfer on a network, it's such a low-bandwidth use case that it's hard to imagine any issues. I use a RAID-5 NAS (Gigabit Ethernet, directly into one of my backbone switches) for storage, and an old Mac Pro (the "trashcan") to run Plex. The FLAC files are tiny -- maybe on the order of 40MB per song, so call it 10MB/minute. A gigabit network can easily handle 100MB/s, so 10MB/m is 3 orders of magnitude smaller, i.e. it's a miniscule amount of traffic. Even with a hop from the NAS to the Plex server, and another hop or two from the Plex server to some WiFi access point, and another hop to my phone, it's still a tiny rounding error of the available bandwidth on the network. And since players tend to buffer several minutes of music (at a minimum), even severe congestion shouldn't pose any problems.

 

[Exocer]

Hi, what are the specs of the cap??

I had to open it to check:

330uf
25v

Non-polar ANK

 

[NikBales]

...Many many thanks!!