Relationship between Ethernet Switch and SQ


This one will probably invite some withering mockery, but I will ask....

I only stream, and my streamer (Bryston BDP) is fed with an ethernet cable that runs back to my router.  Literally back to my router; there are enough output jacks on the router that I have a long run to the streamer and no ethernet switch in the chain (or the house system for that matter).   (There is an Eno filter right before the streamer).

I happen to OWN a nice LHY ethernet switch.  I am assuming that there is no reason to use it in this configuration, that is, assuming there are noisier switches, and less noisy switches, there is still no net benefit of adding any switch to this chain.  But maybe, just maybe, in the metaphysics of electrons that I do not understand, there is some reason why a nice switch prior to the streamer accomplishes something (in theory...I get that I can A/B test and try to fool myself whether I can hear a difference).  For the first person with a correct answer, I will mail a nice $600 switch to the address you specify! (JK)

mathiasmingus

audphile1

I am using a network renderer in my DAC (Bricasti M3) as a Roon endpoint (Roon core duties are handled by Mac Mini) without an outboard dedicated streamer. I also occasionally use MConnect to bypass Roon and stream direct from streaming services (Qobuz and Tidal).

It seems to me that something is badly amiss if you suffer dropped bits while using that equipment with Qobuz, as you describe below, @audphile1. I'm not a Roon user, so I don't know if maybe that's where your problem is. But you should be getting bit-perfect delivery from Qobuz and if you're not, you be better served by fixing your network issues than anything else. If all of your wiring and connections are tight and secure, you might want to look at that DAC as the culprit.

"isn’t fast enough for streaming so error checking goes out the window, replaced by ’error correction’ meaning that if a bit is dropped, some value between the 2 adjoining bits is chosen (interpolation) "

Man, there is some different opinions. But we all have them.

I am using an EtherRegen in my computer room that converts the ethernet to fiber which then goes to my Lumin X1 in my audio room. Pretty much clutter free.

To me, the fiber was a game changer in sound quality. The music became calmer and more natural. I suppose the transceivers are important. I am using Finisar

ozzy

@cleeds  ha? Dropped bits? Man who’s saying anything about dropped bits?

I’m talking about difference in sound quality that’s influenced more by a component design and implementation as well as parts quality that impact the sonics more than the network switches, or converting copper to fiber and back to copper, using switches and upgrading power supplies on routers, switches and fiber optic converters. This is the topic of this discussion. Let’s not highjack it.

@ozzy your setup makes sense - using fiber into Lumin that accepts it. One step convert copper to fiber optic and clean up the EMI and RFI on the copper data line. 

@mathiasmingus

there is a very simple answer to your question, and it is the only answer, adding a switch in the chain can only deteriorate, it can never under any circumstance enhance. It is absolutely impossible and anyone telling you differently does not understand the technology.

a good switch only adds a bit of latency, a bad switch can cause frame drops and cause audible issues. that said, the switch needs to be pretty bad to cause issues for streaming services.

and on the topic of streaming, there is no such thing as continues stream, it is a series of downloads into a buffer. Any media over TCP/IP and Ethernet buffers. Regarding caching, at least according to Qobuz all players are supposed to cache, but some manufacturers want to fool their buyers by saving it is a better experience if you don’t cache, but that is just BS.

anyone with foundational knowledge of the topic can verify all of the above with a packet capture. 

@fredrik222 there is no downloading into a buffer. Buffering will let you buffer some data to help manage the data stream to allow other processing to take place. Let’s say for example it will buffer 1.5min or even less of a 5min track. This allows the processing to do what it should be doing. It’s not an uninterrupted stream as t never should be. Typically buffering is done in memory.
Caching on the other hand will cache the entire result set and the streamer will process the data from the cache (much larger solid stare drive or larger memory area). Aurender, for example, leverages a 240GB cache. If you pause in the middle of the playlist that was cached earlier and come back to it an hour later, the same data will continue to reside there until the cache is cleared. The same exact concepts apply on the database either you use SQL, Oracle on premises or Google or AWS in the cloud. When the user runs a query, if caching is enabled, the results will be cached. So that you can run and rerun the same exact data query - the result will be pulled from cache and not from the database again. Unless the criteria changes. With buffering it will always be re-pulled.

But one thing we can finally agree on, you and I, is the addition of switches. In every scenario I ever tried a switch caused degradation in sound quality.