Melco S100 Ethernet Switch Measurements

[plissken]

10 hours ago, Confused said:

So this seems to back up the view that if your DAC is "properly engineered", then stuff like audiophile switches should not matter, however, it does go against the view that it is absolutely impossible for a switch to make any difference in any circumstances. 

 

You are talking about .4 dB spread over 146dB range. I'd ask for show of hands how many here would pay $2200 for .4 dB over that range.

 

Or you could not purchase a $2300 Lumin D2, a $2200 'audiophile switch'. Spend $40 on a used Cisco 2960 and spend the remainder on a competent streamer.

 

Again, these are data and not audio devices. I thing the subjective reviewer can't cash the check his ears are writing. My offer always stands.

 

 

 

 

[plissken]

2 hours ago, Confused said:

Would there be a range of measurable results?

 

Would there be same sample to sample variance? Either switch or streamer?

 

Again here is the problem: If you start playback on the Lumin D2 and pull the plug how long does it continue to play for?

 

Let's say you get 30 seconds at redbook. That means the data was transferred and buffered up locally 30 seconds ago.

 

So I would like to see this repeated with 48Khz 60 second sample played and then measured while playing out of buffer with the cable pulled.

[plissken]

27 minutes ago, Miska said:

As I suspected, in this case too, the ethernet isolation is spoiled by use of STP cable:

https://www.melco-audio.com/products/c1ae/

So likely source for the differences are ground currents through the cable shield. HFN doesn't tell what other equipment was connected to the switch and through what kind of cable, because now in this case it matters greatly.

 

Does the Lumin D2 have a shielded RJ45 port? Good catch. That's why I would like to see a write up of the entire testing regimen.

 

Critical thinking for the win 🙂

[plissken]

3 hours ago, R1200CL said:

Please do your homework 😀

 

The signal from the switch with jitter, noise etc, has already been injected into the buffer. 

 

Jitter is time domain error. It can't exist in a buffer. John will tell you that. Buffers represent clock domain boundaries.

[plissken]

6 hours ago, R1200CL said:

And good clocks wouldn’t matter. But they do. I probably need to do my homework as well then 😀

 

Sure clocks matter. The one on your DAC the most.

 

My JRiver system can buffer up to 1GB of data. My 10GBe connection maxes out at ~330MB/s.

 

I concatenated a ~45 minute album into one .wav file and flac'd it to 445MB.  I start playback and in the time it takes from clicking play to unplugging my network cable the entire song is in buffer.

 

What does any switch $20 or $2300 or any upstream clock have to do with it then?

[plissken]

2 hours ago, mecani said:

I can be a bit heavy but has anyone here heard the melco s100?

 

The Melco isn't an audio device. It produces only 25Mhz frequency. I can't hear that high. My best is 14.6KHz.

[plissken]

9 hours ago, R1200CL said:

I just got a Cisco 2960 G version. As an example, should I expect equal measurements from the RJ45 as the SFP port ?

 

Which measurements? Ping, and throughput should be the same.

[plissken]

1 minute ago, mecani said:

they talk about a product without having tried it

I heard that having your wall framing made of metal stud makes your sound system better vs wood framing...

[plissken]

2 minutes ago, mecani said:

A wall frame made of metal posts is not an audio device.

 

How do you know it doesn't. Have you had a listening room made with metal stud yet?

[plissken]

1 minute ago, R1200CL said:

Phase noice, jitter, and what ever make sense to measure. I think you know. (Much better than me). 

 

Measure jitter all you want. These are not real time systems. Jitter only appears on data transfer. The higher the speed obtainable the smaller the window of transfer.

 

You can't have jitter when the line isn't doing anything.

 

If you take 10GB and you can realize it's 1250MB/s you can transfer, on an appropriately engineered system, a CD in about .6 of a second. 

 

Even if you have a system that can only cache 30-60 seconds of audio your time on the wire at 10GB is going to scale just the same.

 

[plissken]

2 hours ago, R1200CL said:

So in what way should measurements of a switch be done ? 
What parameters matters ?

 

You are operating under the assumption that switches change your realtime sound quality. That is if you are listening to a 10 minute track it's for the duration.

 

This is simply not the way it works. I've been more than fair in offering cash to anyone that can demonstrate this.

[plissken]

3 minutes ago, R1200CL said:

So how does it work ?

 

If you've been keeping up with the thread both Miska and Myself have been explaining.

 

802.3az is something you should read up on for starts. Ethernet operates at full wirespeed. Copy over a 75MB 16/44.1 audio track and it will go at full speed. On GBe it will take a split second. Literally.

 

On well optimized playback systems it will do the same and then let the Ethernet connect sit idle and even bring down the power and also power down certain parts of the Ethernet PHY.

 

The point in time that you are listening was most likely delivered seconds before if not minutes before.

 

Again what does the switch have to do with audio after it's been copied over? You don't even need the switch.

 

 

[plissken]

3 hours ago, R1200CL said:

Instead of me arguing, can you explain why a switch like the etherRegen won’t matter based on Alex and John’s explanations here:

 

 

 

I'd rather use their own White Paper:

Q. What about systems in which a very large buffer holds a whole song or whole album?

 

A. A very large buffer where the input completely shuts down while all music is playing can eliminate the phase-noise overlay of upstream sources. However, leakage current is still there. As long as the cable is still plugged in leakage current is still flowing through the cable towards the DAC. So just not sending any packets does not make any difference—the cable has to be unplugged to stop it. Even if there are zero packets from the control system during playback you still have leakage coming from the switch and other upstream network components.

 

     1. They have yet, after years now, failed to show any measurements to this effect on a DAC output.

     2. Use wireless (I'm running two TP-Link Omada 1350 in VHT80 with 802.11K/R/V for seamless roaming) $112.

         I routinely get 38MB/s.

     3. Use fiber and while your at it use 10GBe if you can. My 10GBe setup cost 1/3 to 1/10th of 'Audiophile Switch'

         options ($210 for Cisco 2360, Solar Flare and Dell NIC's, and FS.COM SFP+ and fiber patch).

 

So we can effectively discount with item 1, and even if we don't I have two solutions at $112 and $210 that are better by their own admission.

 

 

Q. What about fiber-optic interfaces? Don’t these block everything?

 

A. In the case of a pure optical input (zero metal connection), this does block leakage current, but it does not block phase-noise affects. The optical connection is like any other isolator: jitter on the input is transmitted down the fiber and shows up at the receiver. If the receiver reclocks the data with a local clock, you still have the effects of the ground plane-noise from the data causing threshold changes on the reclocking circuit, thus overlaying on top of the local clock

 

         1. By omission it is left out that this only happens on Data Transfer.

         2. 10GBe and higher have much more stringent Jitter requirements. Most likely beyond what  

             boutique audio switch manufacturers can produce. I would say that a $20 multi-mode

             10GBe LC SFP+ tranceiver has tighter tolerances than any 'audio-phile switch'. @jabbr

             comment on that one.

 

 

 

 

[plissken]

7 minutes ago, R1200CL said:

@plissken

My understanding is you pull out the cable in order to eliminate leakage current, so with optical cables there isn’t a need for this. 
I suppose if a buffer is to be used in order to block phase noise (jitter), this buffer must be located after last network interface, so it can’t be inside a switch.  Maybe it can be inside the opticalRendu (I know there is one, but not sure how big, or if it does anything to reduce jitter). 
 

Where is your buffer located and what size does it have ?

 

1. Switches do have buffers and you can manipulate these with various commands to affect priority que.

2. A buffers sole job is to establish a clock domain boundary for systems that have different timings.

3. My buffer is 1GB of RAM on my JRiver based system. This is why I always point out 'correctly designed/engineered systems'.

4. Even a buffer of a single MB is enough. But what that does is keep the receiver PHY in play longer over the duration. I prefer as much wire speed as possible and buffer up front.

7 minutes ago, R1200CL said:

I suppose the only way this can work is if those 10GB switches also do 1 GB, and I don’t think they do. So it’s up to the SFP Small form-factor pluggable transceiver maybe ?

@jabbr Maybe you can explain what’s possible with 10GB into 1GB. 

 

Switches that have SFP+ (or SFP10) can do 1 GB. You just pop in the compatible 1GB modules on both ends. SFP* modules are fixed rate and have to match on both ends.

[plissken]

15 minutes ago, Blackmorec said:

Here’s the thing. Take a hi-res system with a server like an Extreme or an Innuos Statement and set it up for local (internal storage) and remote streaming (via Internet of Networked disc).  Both servers play files from internal RAM. Play the same recording and the SQ will generally favour the locally stored file. Add a Melco S100 to the network and the remote streaming improves, but generally, so too does the local streaming.  Add a high quality power supply to the Melco and the SQ of remote streaming improves, but so too the SQ of the locally stored files.  Disconnect the network entirely and the SQ of the locally stored files improves. So it would seem that the improvements have more to do with noise and how it affects processes within the DAC.

 

 

Here is a video I shot with an Audiophile Switch. It's short and to the point. I would love to see you tell when the switch is in and out of loop.

 

 

[plissken]

4 minutes ago, R1200CL said:

And is not affected by choice of SFP ? (No problem with 1GB versions on 10GB switches). 

 

1GB won't have as tight a tolerance as 10GB. From my understanding all the engineering is in the SFP transceiver.

[plissken]

9 hours ago, R1200CL said:

Wouldn't pulling the USB cable make same result? (You will have the same buffer there). 

 

You mean USB from computer to DAC? Pretty sure the DAC doesn't have 1gb of RAM buffer :-)

[plissken]

26 minutes ago, R1200CL said:

So you’re claiming your switch have ?

 

You watched the video?

[plissken]

2 hours ago, ASRMichael said:

Is it not fair to say currently the best method to analysis what's happening with digital audio (zeros and ones) is our ears?.

I totally agree. Now I've been offering $4,000 for anyone that will do this will ears only when it comes to audiophile network switches.

 

Can't give it away...

[plissken]

1 minute ago, ASRMichael said:

Can you explain a bit further?

If you watch the video it explains what I'm proposing.

[plissken]

1 minute ago, ASRMichael said:

Is the video not only showing what you can see happening with the technology we have to measure? 

It's a short video. I encourage you to watch it and hopefully it will prompt you to re-evaluate some of the incorrectly held misconceptions about computer playback and non-realtime audio.

[plissken]

14 minutes ago, ASRMichael said:

 I;m not that tech save to answer this, this is why I use my ears. 

 

Which is why I have made a standing offer for years now to pay off anyone that can, ears only, when it comes to audiophile switches/patch cable, tell the difference when they don't know what is in play.

[plissken]

27 minutes ago, Superdad said:

in which he sAnde are these as real as your eems to ignore the very real electrical effects that common-mode leakage currents, ground-plane noise, and clock-threshold jitter have when permitted to enter the DAC-attached endpoint.

 

Are these as real as the yet  un-released measurements that you've been promising?

 

My video shows how this could be done. The constraints are that the setup has to support LACP and streamer if used would have to support reconnecting to it's source automatically. That the participant wouldn't know what is in use.

 

As far as how it would be switched up I'm flexible to the point that we could select how many potential changes in a track and let the listener pick the times of potential change.

 

Although if the differences are that stark then you should  know when the change is made.

[plissken]

5 minutes ago, ASRMichael said:

Looking at your system do you have measurements for all your kit? Or did you choose by ear? 

 

That's only relevant to claims being made. 

 

If you say You can from a standstill jump straight up and clear a 10 foot high bar, I'm going to bring a bar and a tape measure. 

[plissken]

1 hour ago, ASRMichael said:

I’ll bring technology to make sure I’m measuring what you doing then! 👍! After all it needs to me measured! 

 

You bring the finest measuring instruments in human history according to many at A/S: Your ears.