Is optical mostly a waste of time versus Ethernet?


The only value I see with a fiber optical cable is if you have a long long run.

All the noise coming into an optical fiber is preserved and comes out the other side. I guess there is a value in not creating more noise while it is traveling through the optical cable. But if it's a short run of two Feet then is it really worth it.  Seems a well shielded Ethernet cable would do just as fine without all the hassle of converting to optical which is a pain in the ass.

I always thought there was value with optical but it seems they're really may not be. Maybe I'm wrong.  It seems a switch likely produces a lot of noise and inserting an audio grade switch is very prudent and going optical really doesn't solve switch noise problem.  The benefit of re-clocking offered by a decent switch to clean up the signal is worthwhile.

jumia

"here is the thing, I am guaranteed the foremost expert on networking on this site."

Who guaranteed this?

@yyzsantabarbara  here you go again… you just don’t know what you are talking about. Broadcast is not at a higher level than TCP or UDP (L4), broadcasts happen at L3, a lower level, and is used among other things for ARP. 
and for sure TCP can and will reduce throughput, but not by dropping packets like you say, rather it reduces what is called the window size. The window size is basically how much data can be transfer before the ACK is sent. TCP never intentionally drops packets, and what you are quoting doesn’t even say that.

what I have been saying, and continue to say, is that your hearing is up against trillions of secure and undisrupted banking transactions daily. The entire system is built to prevent what you say you can hear. You may think that is mocking, but I find it insanely arrogant to not at all understand networking, like yourself, and say you can hear a difference, which would invalidate everything the Internet able to provide today.

Here is a wiki article on packet loss. An explanation for my degraded ROON audio signal on that George Harrison song (the whistling part), when my ROON Core was behind a lower bandwidth PowerLine network is explained below.

The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to ensure reliable messaging. Packet loss in a TCP connection is also used to avoid congestion and thus produces an intentionally reduced throughput for the connection.

 

I am not going to belabor the BROADCAST message type I brought up into the conversation. It is at a level higher in the OSI stack than is relevant for audio streaming. So my mistake on bringing it up in this audio discussion. I assumed that audio streams were UDP BROADCAST messages.

However, the crux of the point I was making was that network packets are being dropped in audio streaming. Contrary to what this self-proclaimed EXPERT is saying. The Wiki article indicates that even under the TCP protocol, packets can be dropped (intentionally).

My reproduceable test with the George Harrison song shows me how to mangle a song on ROON 100% of the time. This is an example of network congestion causing poor audio quality in streaming.

I believe the EXPERT was making fun of the people on here with functioning ears and also potentially more expensive network cabling and routers et al, than the EXPERT themselves use.

 

 

 

 

I think you’re talking two different things. there is the physical network topology segmented into layers then there is the electrical noise associated within the wire separate from the ethernet packets. Fiber not being metal is impervious to external electrical noise but does need power to perform the conversion to light so it could actually be noisier than a cable depending upon the power supply used to drive it.

@fredrik222 

You may be a networking expert, which I respect unconditionally, but is there any possibility in your way of thinking that an analog waveform representing a secure digital financial transaction succesfully completes with added noise? Is there any possibility that a streamed song sounds different to the user if there is added noise on the ethernet feed? Is there any advantage in your way of thinking to limit the ethernet feed to 100mbps rather than “top speed”?

@jumia   so, I would skip the “audiophile” switches, and go with a enterprise switch. You can find cheap Cisco, Juniper, or other enterprise grade switches on eBay. 
 

“Audiophile” switches that I have seen actually have no real networking specs, just terms that doesn’t apply to networking at all. 

@sns here is the thing, I am guaranteed the foremost expert on networking on this site. I don’t know a lot about everything, but networking is the one thing I do know, love and have made my life and career off. 
 

Therefore, like I said, confirmation bias is a real thing, and what you are proposing, where you could modify, in your favor, the payload, in real time of encrypted and digitally signed protocols, is a joke. Trillions of bank transactions every single day happen securely just because you cannot do what you think you hear. Money talks, and billions, if not hundreds of billions of dollars move every day on the basis that what you say you hear, cannot under any circumstance happen, ever. 
 

those are the facts. 

For us generalists and/or audiophiles not expert in all the technicalities of streaming we have to rely on the designers of streaming equipment. @fredrik222  proposes himself as the expert above all experts, simply ignores designers of the steaming audio equipment audiophiles use to good effect. Many of us have used general service or streaming equipment not designed with audiophile in mind, we've heard improvements in sound quality with specialty equipment, he dismisses our perceptions as faulty. 

 

For the novice, you can go with ones and zeros or you can go with trust in your senses. The one thing the objectivist can never answer is why we hear things they can't measure,

So maybe a router that is Wi-Fi free should be used to connect all the audio stuff and you can then connect a router with a Wi-Fi daisychained to the first router, because everyone needs Wi-Fi.

Does this seem like a really good idea?

To me the Wi-Fi free router looks like a switch. Maybe connect an audiophile Grade switch directly to the modem and then connect a router to the switch for all those non-audiophile related item. And then connect all the audio equipment stuff to the first switch that is connected to the modem. Does this solve anything?

Of course excluding gear from a router may impair security concern issues.

A router and a switch are two different components of a network. The router is actually a computer that assigns the IP address to a Mac Address (network card) so that multiple MAC addresses can use the connection at the same time. The switch is a different component that reads the packets destination and sends them to the correct endpoint.

WIFI is a separate component that uses radio frequencies instead of hard wire to transmit and receive ethernet packets. As WIFI is now so prominent it’s built in but you can still purchase routers without WIFI.

https://www.amazon.com/MikroTik-Gigabit-Ethernet-Router-RB760iGS/dp/B07F7HDRKX/ref=sr_1_5?keywords=Non+Wireless+Router&qid=1660763397&sr=8-5

Routers can do a lot of cool things like separate groups of users to share / hide resources from each other for instance creating a departmental printer that can only be used by assigned users or limiting access to the payroll computer only to the payroll department.

Everyone should look at the routers admin pages to see what can be accomplished BUT DON’T MAKE CHANGES UNLESS YOU KNOW WHAT YOU ARE DOING AS IT’S EASY TO DOWN THE WHOLE NETWORK WITH A SINGLE SETTING!!!

 

 

@jumia  No clocking benefits, if noise is entering your streamer/DAC through Ethernet, you have some serious other issues. 
 

so the take away is that you should not waste your money. Like I have pointed out and proven, the likes @sns ​​​​and @yyzsantabarbara have no clue about how networking works. 

This thread has become a waste of time. There are some really good answers included here but some of the tangents really disappointing.

In summary it’s all about the noise passing through the ethernet cable and dealing with it. Network switches help by not adding noise, maybe canceling out some of it, and offer clocking benefits. Enough said

@yyzsantabarbara oh wow. You are special! Can’t even admit you have no idea what your are talking about after your vendor of choice throws it in your face.

 

UDP is not broadcast. It is a stateless L3 protocol. And no, it is not just Roon. You still don’t get it, if you lose a packer when you send a compressed stream, you can’t uncompressed that part of the stream at all. In addition, DRM requires at least digitally signed music, so, the entire song must be received in its entirety for it to work for downloads, and larger chucks of the stream that is digitally signed. The only thing you have proven is that your really have no clue, which I don’t blame you for, it is infinite more complex than a speaker cable, except that you keep saying you know something about it, which you absolutely  do not.
 

from Wikipedia “ The Internet Protocol Version 4 (IPv4), which is the primary networking protocol in use today on the Internet and all networks connected to it, supports broadcast, but the broadcast domain is the broadcasting host's subnet, which is typically small; there is no way to do an Internet-wide broadcast. ”

 

 

 

 

but hey, you “program this stuff”. 
 

 

We have decades of experience building audio streaming protocols around UDP, and it has generally been our first choice, but we also know that both TCP and UDP, when implemented properly, are suitable for high-bandwidth, high-quality media streaming, so it was worth undertaking an exploration of “the other side” to see if there was actually a reason to consider switching.

After a series of experiments and prototypes, and a detailed exploration of both approaches, we found that we were able to extract more performance and reliability from TCP, so we took it to the next phase and started experimenting with TCP in our alpha environment a couple of months ago.

UDP is what I was referring to as BROADCAST.  I forgot the term but network BROADCAST messages in software are usually done via UDP. This type of message delivery is not guaranteed and can lose packets. So it looks like ROON  was using UDP and switched to TCP in June 2017. I was wrong thinking they still used UDP. However, that is just for ROON. 

The test I described previously shows me that ROON does not do a perfect stream today when something is limiting them on the network. The distortion I heard on a repeatable manner tells me that even with TCP something is going on that is giving a less than perfect stream to the DAC.

 

 

@yyzsantabarbara man up now. You don’t know what you are talking about, it is as simple as that. But don’t take my word for it, ROON says so. At least admit it.

@yyzsantabarbara  lol, you miss again. You really compared gaming and voice chat to Hires streaming? And you “program this stuff”.

where is your explanation on broadcast streaming?

 

since you use Roon, let me educate you : 

RAAT overview

https://help.roonlabs.com/portal/en/kb/articles/raat#Design_Goals

Release notes 1.3 detailing why they switched to TCP

 

 

so, you are simply wrong. 

This is my last post on this thread because I seem to be conversing with an EXPERT and there is no point in telling an EXPERT anything new.

I discovered this thing called GOOGLE and in 10 seconds a lot of info on packet loss on music streaming came up. Here is one that looks interesting. Though I have not tried it.

 

Activities like gaming and voice chat usually do not need much raw bandwidth, but they need prompt and reliable responses. These programs also do not usually resend information if it fails to get there, so if packets get lost in transmission, they are gone for good, which can also have a significant impact.

 

I wrote about the audible effects of packet loss on my home network about 6 months ago on this site. It happened when I had my ROON CORE PC behind a PowerLine network. The bandwidth of the PowerLine was not sufficient to handle the George Harrision's ALL THINGS MUST PASS album in h-res. I forgot the song but one song where he whistles caused the music to get distorted on my system.

When I moved the ROON CORE to the other side of the PowerLine network (to my normal Ethernet) the distortion goes away. This problem was reproduceable 100% of the time at an exact timestamp on the music. Now if streaming was not loosing packets then I would not have had the distortion.

This discussion was a slight divergence on whether to buy expensive cabling for streaming. 

@sns  absolutely. What it would take to actually make a difference is that you modify the payload. I put every thing you said against the trillion of bank transactions every minute happening globally. Because if FMC actually had a impact and could change the payload, people would be stealing money with the technology. 
 

you don’t understand the technology, that is very obvious, and that is why you can fool yourself in believing it. It is not the same as a speaker cable, interconnect, or even a power cable. It is infinite more complex system with built in safe guards against what you are trying to achieve. The entire protocol set is built to withstand your efforts, and you think you can do anything to impact it. It is laughable.

Like I said, if your premise is correct, trillions of bank transactions are at risk. You really think so? 
 

or do you think a few hundred, maybe even thousands, audiophiles have confirmation bias? 

So, with all these streaming devices, designers with white papers, a multitude of individuals hearing the benefits of these devices. I guess we're all deluded dupes of snake oil salesmen trying to drain us of our hard earned money.

 

Afraid that ain't going nowhere at this site, ASR is the place for absolutes. In the meantime, we're all having fun experimenting with streaming topologies, experiential learning is our bag, pronouncements from high above not!

 

 

@jumia the summary of this thread is, either you believe the impossible, or you teach yourself about the realities of streaming and networking, and spend your money elsewhere. 

@yyzsantabarbara lol, can’t you humor us and explain how a compressed, and in most cases digitally signed or encrypted signal is broadcasted and lost packets are not retransmitted. Can’t wait for the laughs!

 

@sns and you, you think that your optical cable and FMC somehow can modify the payload, which is where the music resides during transmission. Again, this fmc and optical cable somehow figured out how to break encryption, flac decoding and pcm in real-time and then modifies it to sound better. I have a few bridges for you, just send me all the money you and your children will ever make up front.

I listen plenty, don’t worry about me.

So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard. 
 

but fiber for super short runs like 5ft is crazy waste of money.

100% agree. And I work in the IT Industry. I have all standard power supplies in my rig except for my Power Amplifier (1500VA Toroidal/55,000uF of filtering). From the house Demark to my  DSL Modem/Router, maybe a 50ft. of RG59 Coax followed by another 40ft. of cheap, simple Amazon Basic shielded RJ-45 going to a cheap Netgear "Switch/Router" and it's Wal-Wart. I run 10AWG stranded AC wire inside Armoured Conduit from the Breaker Panel to the Stereo Rig. I have no/hash/hum/grunge noise in my system even when I put my ear to the Tweeter/Midrange of my Cornwall IV's.

So am I one of the "few" of lucky ones ? From the posts on this forum, I must be. 

Not having to waste my money on Ethernet Regen's, Electrical to Optical adapters, SFP modules, overpriced RJ45 switches/routers, and crazy analog power supplies in my computer chain gives me more money to spend on SACD's, legal digital downloads, and CD's. My Streamer is a Bluesound Node 2i and it's stock Power Supply as is my P.o.S. Apple M1 Mac Mini (bought it only because I've gone through 2 Win10 based PC's).

Hater's may go ahead and Hate...😂.

 

Router connects to server via AQ Vodka ethernet cable, server out connects to first in line FMC via AQ Vodka ethernet cable.

 

@fredrik222 Obvious listening not your cup of tea, how you getting along over at audiophilestyle forum?

That goes against the grain of humanity. Utopia is what it is you describe and that simply is taboo

For whatever reason, evil challenges efforts to explain things so they are understood. Genius is the ability to explain things so they can be understood and successfully dispel interfering demons. Always good that someone explaining something truly understands the subject as well as possessing the ability to clearly communicate. To have both is a strong indicator that the Angels of Genius are involved.

 

Is there one device that addresses everything from the internet line entering the house, to the transport that feeds into the DAC?

The fact that all the data packets arrive in the proper order and number isn't the key thing here. Right?

Isn't the real issue the quality and speed of the clocking that occurs within a switch?  The noise is certainly an issue and also is worthy of attention.

And another key issue is the bit rate through the ports. Audiophile Grade switches I believe better control the ports. Basic switches leave the ports wide open Vs. Higher grade switches for sound are scaled down to a much lower Data rate and by doing so it reduces noise. Not sure why but it sort of makes sense.

But key Is the clocking which when done well favorably impacts jitter and improve sound obviously. Basic stuff I guess.

@fredrik222 So you are saying that dropped packets are resent in streaming? I do not think so. That is what I am referring to by BROADCAST. Maybe 1 level up from the TCP  level you started EXPERTING on.

@jumia just because you have 2 ethernet ports, doesn't change the protocols involved. It's still bidirectional, and it's still error detection and correction involved. 

 

Go with what is proven, and not what someone else is trying to tell you will work better. 

sns, thank you again for your answer.

OK so 2 ethernet ports is what you use. I guess my problem is, a server generally only has one Ethernet port. My nucleus has only a Single ethernet port.

What do you physically connect your ethernet cables to relating to server.

Thank you

@yyzsantabarbara  I certainly did not, here was my answer:

"@yyzsantabarbara yeah, no. Read up on what you are typing before you type is my suggestion. If you program this “stuff”, you really should know more than what your post implies, which is 0."

You don't know what you are talking about. There is no broadcast protocols in streaming. 

@fredrik222 

Did you forget to answer to my question of how streaming is done? Here is your statement.

If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.

 

@yyzsantabarbara yeah, no. Read up on what you are typing before you type is my suggestion. If you program this “stuff”, you really should know more than what your post implies, which is 0.

look at the cable itself. 


 

 

@sns you have never heard of it because it is not your area of expertise, or even foundational knowledge… largest manufacturer of networking equipment in the world and its landing page for routers :

 

Well, certainly there is bidirectionality on ethernet between router and server, router needs to know server there. The difference is information from music player (Roon in my case) doesn't follow that path, it goes out second ethernet port directly to FMC (in my case) could be streamer or renderer for someone else. Without the second ethernet port information from music player has to go back through the ethernet cable connecting to router or switch.

 

Isn't a router without wifi a switch, never heard of a router without wifi.

Thank you, although still unclear how are you have cured bidirectional Ethernet connection with a server.  Unfortunately isn't two way communication integral to the process?

A router without Wi-Fi means you should be using a switch if needed.  Not really practical though.

 

So, here we go again, another thread about bunch of people applying pseudoscience audiophile terms to Ethernet. Nope. Ethernet does not work that way. Ethernet, along with the TCP/IP stack are several layers of error detection and in some layers error correction. If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.

So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard. 
 

but fiber for super short runs like 5ft is crazy waste of money. 

Are you saying that bits of music are going to be retransmitted in a stream if an error occurs. I doubt it. I believe a BROADCAST protocol is used instead of the REQUEST/RESPONSE I think you are alluding to. Yes, I program this stuff.

The reason to use Fibre in audio is not for transmission length specifically but for Fibre's ability to stop analog noise from traversing the cable and getting into your DAC. It is very easy to test and more importantly to HEAR the difference.

What I hear with Fibre over Ethernet is improved clarity, especially when using my Benchmark gear, AHB2 + LA4.

 

 

And, final point, Ethernet is a layer 2 protocol. The type of cable does not change this, as the cable is layer 1, regardless if it is fiber or copper, or barbwire (yes, you can run Ethernet over barbwire).

So, here we go again, another thread about bunch of people applying pseudoscience audiophile terms to Ethernet. Nope. Ethernet does not work that way. Ethernet, along with the TCP/IP stack are several layers of error detection and in some layers error correction. If an error is detected the frame, or packet, or datagram is discarded, or in the case of error correction, discarded and the retransmit requested.

So why fiber at all? Copper Ethernet cabling has limited range, 100ft is a safe bet, but depends on speed and cable standard. 
 

but fiber for super short runs like 5ft is crazy waste of money. 

@emergingsoul You have that correct, one ethernet in, one out. Most servers have one ethernet port in which case you bidirectional flow back and forth to router or switch. Doing this I've avoided an extra piece of equipment, in my case server>FMC>OpticalRendu(convert to usb)>dac. Also made sense to me that one would want to avoid the bidirectional flow,

 

I did try adding an audiophile switch, lesser sound quality than above setup, only makes for an unneeded detour.

 

@mitch2 Seems logical to me minimizing noise earlier in chain would be more effective than later, in this case optical router would seem preferable. Ethernet  vs optical router, any single ethernet router could create less noise than a certain optical router,  implementation key. If ethernet router superior to optical the isolator may be way to go.

 

Assuming you're using wifi with all other equipment connected to router, only audio system using ethernet. Router is likely noisiest component in streaming chain, switch is there to minimize noise from router. Now if that router isn't supplying wifi, replacing router with the quieter switch would be way to go, superior clocking and better power supply in audiophile switch a further step up. ;Problem for vast majority of us is we need wifi, have to put up with noisy routers. Nice way to go, have two ethernet services coming into home, one for audio system, other for rest of home (wifi). Audio branch feeds audiophile switch, just got rid of one very noisy component (router). My proposed optimized/simplified streaming chain would be, modem>switch>server ethernet port in>server ethernet port out>streamer>dac. One could substitute all optical for the ethernet, could also take server ethernet/optical out to streamer/dac, could also substitute integrated server/streamer for the separate server and streamer.

 

 

Do you really need to run fiber from the router to the server or is an optical isolator (such as Gigafoilv4)  just in front of the server sufficient to clean up any noise on the Ethernet cable?  Is a transformer isolator (such as the NA ENO or Muon) just in front of the server sufficient for the same purpose?  If your only wired connection out of the router is your audio system, why do you even need a switch and how can the switch possibly improve sound quality in that situation?  It does seem that simplifying the digital signal path and removing converters and power supplies should in general reduce noise, unless there is something amiss with the digital signal delivery.

Sns, you wrote about in one of your other posts about using a server with a incoming Port and an outgoing port versus the traditional Single ethernet cable that involves a 2 directional flow. I hope I’m getting that correctly.

I’m trying to understand the flow of your optical versus Ethernet Signal path and all the streaming gear that you have. I also took a look at your system and found it a Little scary because i had trouble following all that’s going on.

But focusing back on the traditional server set up using a single Ethernet Cable it does present an interesting question as to whether there is a better way to do this.

The music data flows into a nucleus and then flows back to the switch and then to the streamer/dac. Not sure if I understand the originating flow of Sonic data as it finds its way into the streamer/dac. It would seem to be a very turbulent journey for all those packets before getting to the comfort offered by a streamer.

Router and/or switch with optical out could be contender, one issue could be lack of choices with optical. Some claim audiophile switches superior to generic, don't know of one with optical.

 

Don't know if I already mentioned in this thread, but thus far I prefer ethernet vs generic FMC going to server, optical post server best for me.

Seems router that does optical output would be ideal and why would this not be a great ? 

@sbank Good post, one little nit, OpticalRendu requires optical cable input, thus, requires FMC, unless one's router, switch, server has optical output.

 

And yes, I believe highest quality lps a must to extract max potential from OR. Sonicorbiter OS very easy to navigate, easy to implement OR into streaming system.

By using a simple Linux OS focused only on doing audio, these(and many other good streamers) eliminate lots of this noise.

I believe this to be an important point.  Many of these add-on enhancers originated in response to cleaning up EMI/RFI noise resulting from computer sources.  While today's dedicated servers are essentially still computers, many have been significantly improved by using Linux OS, upgraded power supplies, and improved connection interfaces.  This may be one reason why there is such a wide range of impact and improvements reported by users of these add-on enhancers.   My server uses a Linux OS, choke power supply, and the well-regarded JCAT USB Card XE audio output board, and the changes/improvements I have heard from a variety of this stuff (such as the ENO, Gigafoil, switches, and fiber) have been subtle at most.  

@jumia happy to try to help with that....

Sonore opticalRendu project is an extension of the microRendu and ultraRendu projects that came before it. 

micro & ultra were earlier model streamers that take ethernet as input and output USB to your DAC. opticalRendu came later and added conversion of ethernet-to-optical, followed by conversion from optical-to-USB output to your DAC.

The design is inspired by audiophile gear and meant to bring grace and simplicity to a microcomputer. 

Rendus all follow the high end principle of simpler circuits and better ,quieter parts. Many, including me, find that regular computers with big operating systems(e.g. Windows, Mac) run many tasks unrelated to audio and those add noise. By using a simple Linux OS focused only on doing audio, these(and many other good streamers) eliminate lots of this noise.

The opticalRendu can be powered by your favorite power supply. 

A good quality linear power supply is highly recommended. Costs vary widely.

The opticalRendu has optical Ethernet input and USB-Audio output with all the connectors located on the rear of the unit for easy cable routing. 

Just plug a standard RJ45 ethernet cable coming from your internet router, switch or wifi extender into the Rendu as your input. Standard USB A-B type goes from Rendu output to your DAC input.

The opticalRendu utilizes a new proprietary printed circuit board with only the essential components and many updates to match its optical designation. 

It uses a small number of good parts to sound good.

 The best way to connect the opticalRendu to a USB device is via your favorite USB cable. 

Years ago, USB sucked pretty bad, now it doesn't, if care is taken. Some users used to add converters to instead connect a different digital cable type to their DAC. Since they put lots of effort into making their USB output sound good, you shouldn't bother with any of those converters and instead just connect a USB to your DAC.

The opticalRendu is easy to configure, accepts streams from various sources, and includes our latest version of our operating system Sonicorbiter.

You use your web browser on any device to adjust settings. It's pretty easy. When they do software updates every couple of years, you can buy it for ~$30. They mail you a little micro-SD card, and you just pop it in to replace the old one. Takes 2minutes.

Does that help? Cheers,

Spencer

This is the description from the Sonore website: it is pretty darn confusing for those of us with lower IQs.
 

Sonore opticalRendu project is an extension of the microRendu and ultraRendu projects that came before it. The design is inspired by audiophile gear and meant to bring grace and simplicity to a microcomputer. The original microRendu was very small and intended to be hidden out of sight behind your other gear. The opticalRendu can be powered by your favorite power supply. The opticalRendu has optical Ethernet input and USB-Audio output with all the connectors located on the rear of the unit for easy cable routing. The opticalRendu utilizes a new proprietary printed circuit board with only the essential components and many updates to match its optical designation. The best way to connect the opticalRendu to a USB device is via your favorite USB cable. The opticalRendu is easy to configure, accepts streams from various sources, and includes our latest version of our operating system Sonicorbiter.

 

That's the beginning of the product description for the opticalRendu on SGC's site.

If that's not clear...<snarky comment of choice here>. 

So it's a streamer and yet it didn't say this when I was trying to figure out what it was. 

The OpticalRendu is streamer for optical. It takes place of second in line FMC with streamer and usb output to dac. Advantages include one less conversion to ethernet (FMC only have ethernet outputs), better clock, less noise than generic FMC, very nice streamer with nice clock less noise on usb out, no usb cleansing devices needed. Love my OpticalRendu, one of the largest if not largest streaming upgrade I've experienced.