advertisement


New blog - Making Light Work: Optimising Optical

Sorry Nigel I can't open the link. I'm hoping your blogs haven't been ruined by certain people not too far away as I was interested in reading them.
 
I think the last series of posts shot the credibility of this product down in flames.
Do you really need to cross-pollute, Dave? It's unnecessary and, having kindly been invited to your home, I know you pride yourself on building your own stuff so I'm not sure how much there is here in the trade discussions section for your interest.

Sorry Nigel I can't open the link. I'm hoping your blogs haven't been ruined by certain people not too far away as I was interested in reading them.
Link now fixed with thanks to you for pointing it out (sorry I missed this) and to @Sloop John B for providing the correct link. I don't think there's much fun in using Trade Announcements rather than Trade Discussions but I think we can all see why there are more announcements than discussions!

If it gets a little loud again, we can pick up by PM; that shouldn't be necessary.
 
Do we have any IT systems engineers that would care to comment on this at all?

One of our companies works in the the high speed digital signal area in certain circumstances fibre would be preferred for high speed digital communications as the the limit of copper is getting very close. However this is around 50Ghz somewhat higher than the 40MB/s of say 768Khz upsampled audio data. While most are closer to 10MB/s (192Khz). Yes the removal of electrical interference is desirable, you still have to convert the incoming / outgoing signals from electrical <> Light pipe and back again of coarse there will be very zero losses in this process.

Then you have the ability of 'cadge' to offer a different 'flavour' of output, it all gets overally complex and instills that FOMO feeling (fear of missing out)
 
I'm an IT guy.

There is no need for it to get complex, though some do enjoy making it so!

I agree, there are zero digital losses. There is no digital magic going on in an optical connection - data goes in and data goes out in the same sequence of packets/frames just like it does on a CATn copper cable and it would be an extremely badly engineered component which cocked things up (the 7 layers of ethernet protocol are there precisely to ensure robust transmission of data across a huge diversity of equipment).

Audio needs reliable data transmission just like the rest of the internet does. The difference in audio applications is that we don't want any of the noise which goes along a copper cable, we just want the data. That's the mission. The article is not about making optical work for data transmission, it's about making optical work optimally for audio, which is all about eliminating noise not doing some sort of data magic.
 
Very interesting response, and one we deal with on very regular basis we even have test fixtures specifically for proving this in many applications, we can directly measure the entire Tx & Rx transmission line and even charactorise everything from stripline /Light pipe / connectors / what ever you wish. While the protocols maybe the strengths of the DTS the rest of the surporting infrastructure may not be so robust.
So you can see the exact eye pattens and how much ISI (coding issues that produce generator timing issues) and other forms of jitter are exposed.

If this is the case then products like the ether-regen and audiophile network switches would make zero difference, dispite a great deal of evidence to the contray?

One could say Yet ANOTHER total money-grab scam based on the ZyXel GS-108B v3 switch board--which anyone can purchase for $20 on Amazon. they do not even bother to change the 20-cent crystal or do anything at all besides putting the board in a fancy milled enclosure (blocking 6 of the 8 ports), writing some BS about EMI and how clocks in Ethernet do not do anything--and then changing more than $1,100. Will this ever end?
:S


We do get asked these products a great deal, the above from a USA based customer observations, Have seen at least six different products similar to this format in the last 18 months and asked to improve, then when benchmarked its a big disappiontment.

Granted they many other products that do benefit in this area.

More definate proof of real world operation is required on these products imho.
 
Last edited:
Very interesting response, and one we deal with on very regular basis we even have test fixtures specifically for proving this in many applications, we can directly measure the entire Tx & Rx transmission line and even charactorise everything from stripline /Light pipe / connectors / what ever you wish. While the protocols maybe the strengths of the DTS the rest of the surporting infrastructure may not be so robust.
So you can see the exact eye pattens and how much ISI (coding issues that produce generator timing issues) and other forms of jitter are exposed.
Jitter in the ethernet domain? Really?
If this is the case then products like the ether-regen and audiophile network switches would make zero difference, dispite a great deal of evidence to the contray?
The difference any switch, audiophile or not, can make to sound quality is nothing to do with jitter. It is nothing to do with digital. It's solely to do with RFI noise reduction. Which is why and how they make a difference. Optical connections are a different technological solution to the same challenge.
One could say Yet ANOTHER total money-grab scam based on the ZyXel GS-108B v3 switch board--which anyone can purchase for $20 on Amazon. they do not even bother to change the 20-cent crystal or do anything at all besides putting the board in a fancy milled enclosure (blocking 6 of the 8 ports), writing some BS about EMI and how clocks in Ethernet do not do anything--and then changing more than $1,100. Will this ever end?
:S
One could, but why would one? Why change a crystal? Clocks have no impact on sound quality in etherent; those who claim they do simply don't understand ethernet and are erroneously extrapolating from the digital bitstream world of streamers and DACs where clocks absolutely do. I have said repeatedly, here and elsewhere, that no digital magic can or does happen; a stock board is fine if its design is low noise.

But we're not talking about switches here are we. The blog article is about optical alternatives to switches.
We do get asked these products a great deal, the above from a USA based customer observations, Have seen at least six different products similar to this format in the last 18 months and asked to improve, then when benchmarked its a big disappiontment.
I don't know which format you're talking about now.
Granted they many other products that do benefit in this area.

More definate proof of real world operation is required on these products imho.
Well there is plenty of that.

Anyway, nice chatting, I'm off to announce the award my SuperSwitch has just won. Catch you later.
 
Jitter in the ethernet domain? Really?

Yes indeed, not in the protocol, I am talking about the Tx and Rx hardware which is entirely measurable.


The difference any switch, audiophile or not, can make to sound quality is nothing to do with jitter. It is nothing to do with digital. It's solely to do with RFI noise reduction. Which is why and how they make a difference. Optical connections are a different technological solution to the same challenge.
Taking your comment here, RFI (radio refequency interferance) occurs aross many frequenices and at different amplitutudes depends on what sources are acting on the the device under test conducted/radiated/ and immuntiy derived. These can further be catorgised in to common mode and differenital types. RFI can and does effect jitter (timining errors) due to its proximty to sensitive items like clocks/FET's/operational amplifiers/sensors etc. Especially if generated by FPGA's/Microprocessors/Local regulation devices/poor board layout/Connector mis impedence match.

The really nice side of this is its is simple to prove this by the use of RF near and far field probes in conjuction with RF current probes on the input and output side. RFi can be mittigated by many means, however fundemental issues need to be addressed by a redesign of the circuit board and surrounding devices.


One could, but why would one? Why change a crystal? Clocks have no impact on sound quality in etherent; those who claim they do simply don't understand ethernet and are erroneously extrapolating from the digital bitstream world of streamers and DACs where clocks absolutely do. I have said repeatedly, here and elsewhere, that no digital magic can or does happen; a stock board is fine if its design is low noise.
I am sorry I totally disagree with clocks make zero difference to this serial data transport method of ethernet 1000 base-T in relation to the subject we are talking about. Happy to prove this and with the same board you use in your product no problem at all.

We can use this device to enable us to demonstrate the differenices along with a suitable high definition 12 bit scope, we have these devices in our lab. Ideal for exactly identifying many different aspects of protocol and transmission line issues when designing products for this standard.

Ethernet testing protocol fixture
I don't know which format you're talking about now.
I was suggesting ethernet switches and I was pointing out that I agree they make a difference despite many feel to the contrary.

Well there is plenty of that.

Anyway, nice chatting, I'm off to announce the award my SuperSwitch has just won. Catch you later.

Indeed well done on ther award :cool:
 
The quoting functionality here doesn't seem to help as it won't show both the response and what it was to.

Sorry, Tx and Rx hardware are working entirely in the ethernet domain so whatever you define jitter as, it is not and cannot become anything which impacts sound quality. Jitter in the bitstream of streamer output (the streamer's job is obviously to convert ethernet frames to bitstream as well as control playback) yes, jitter in the DAC yes, jitter in ethernet including switches, no.

Yes RFI has the impacts you describe, but these only affect sound quality in the bitstream space. Timing in ethernet is necessary for the protocol to function; it does not relate to sound quality. It might be measurable, and a probe might help do this, but it's simply not relevant to why people buy switches for audio.

Whatever you can measure regarding ethernet clocks, the measurements won't correlate to sound quality. If you can measure RFI on the input signal of a switch and compare this with RFI on the output signal of the same switch, that might be interesting as the onward forwarded RFI which accompanies the data signal is our focus here because it impacts sound quality further down the line.

Thanks re your congrats.
 
From your description, i'm reading that the problem you believe is happening is that common mode rejection on the ethernet cabling is insufficient to avoid some degree of bleed across to the receiving equipment, and if this is the case, then moving to optical would resolve this problem (and as you point out, may introduce other problems from the circuitry which would need investigating).

It would be interesting to know whether it's possible to intentionally add common mode noise to an ethernet switch, by, say, fiddling with the power rails. If so, it would probably be a decent test bed if you can vary the added noise and see how the receiver handles this.

My experience with SFP+ transceivers is limited to SR installations (typically within the rack). You would probably want to look at the different optical standards as these might alter how the transceivers operate, so for example, LR or LR multimode might have different properties. Probably a lot of options to explore if you are so inclined.

As for jitter on packets being audible, that does stretch the imagination. You'd need the jitter to somehow affect in a negative way the data being written to the circular buffer employed within the streamer, such as to produce some sort of audible characteristic. Given packets are being read intermittently due to the much great bandwidth of the network compared to that required for the stream, it is I think unlikely this would bleed through in any way, even if you could come up with a mechanism (which I doubt).

In your article, i'm in the 'it can't make a difference' camp, but i'm totally fine with you exploring this and would welcome evidence to prove me wrong (not anecdotal) as this is how progress is made.
 
I'd take a good set of Tony's measurements aligned with a solid double blind test over speculation any day.
 
As for jitter on packets being audible, that does stretch the imagination. You'd need the jitter to somehow affect in a negative way the data being written to the circular buffer employed within the streamer, such as to produce some sort of audible characteristic. Given packets are being read intermittently due to the much great bandwidth of the network compared to that required for the stream, it is I think unlikely this would bleed through in any way, even if you could come up with a mechanism (which I doubt).
Why do you mention “jitter on packets”? I’ve been clear in all my posts and blogs that the idea of timing accuracy in ethernet affecting sound quality is a nonsense.

EDIT: ah, gotcha. You are referring to the preceding post. You and I agree.
 
Why do you mention “jitter on packets”? I’ve been clear in all my posts and blogs that the idea of timing accuracy in ethernet affecting sound quality is a nonsense.

EDIT: ah, gotcha. You are referring to the preceding post. You and I agree.

Yes, that's what I was referring to. Sorry, should have made that clearer in the post.
 
I'd measure the output from the dac the usual thd+n, imd, snr, then run a null test using deltawave to check for a residual. If its below -100db I'm ignoring it.
 
Cool. If I send you one of my SuperSwitches (or Optical Bridge), do you have the measuring instruments?
 


advertisement


Back
Top