Thoughts around a Lejonklou Streamer
Moderator: Staff
Re: Thoughts around a Lejonklou Streamer
doze84: You need to learn about how jitter affects D/A conversions. It has nothing to do with loss of data. If you want a discussion, you need to catch up on this, otherwise we can’t communicate.
Re: Thoughts around a Lejonklou Streamer
Edit: Oh you mean ethernet jitter. It doesn't matter that the ethernet packets arrives with delays or at different pace, as long as the ethernet is faster than the playback of the music(as long as a buffer is used).Charlie1 wrote:Fair enough. Sounds like we have very different understanding jitter. I suppose mine is better described as network jitter.doze84 wrote:The only definition of jitter I have heard of, is errors that makes it into the data. These errors comes from clocks speaking at different pace(which always is the case), or noise that manages to cause the pulse signal to vary so much that a 0 becomes a 1 somewhere. But since TCP/IP resends every packet that has even one tiny bit of error, jitter is not a problem, until the last step(buffer to dac).
Last edited by doze84 on 2018-03-28 12:59, edited 1 time in total.
Re: Thoughts around a Lejonklou Streamer
I would love read up on this, do you have a link that can point me faster to the right information?lejonklou wrote:doze84: You need to learn about how jitter affects D/A conversions. It has nothing to do with loss of data. If you want a discussion, you need to catch up on this, otherwise we can’t communicate.
Re: Thoughts around a Lejonklou Streamer
I understand. The jitter I'm familiar with resides higher up the network stack, and is primarily concerned with voice traffic being sent over IP networks:Music at Home wrote:TCP/IP is a transport protocol within the digital domain. Jitter exists in the physical Ethernet layer, which is analog. It's in the conversion from analog to digital that jitter is removed, but a by-product of that conversion is noise, which TCP/IP has no control over.
The best description I can find is here: https://www.audiostream.com/content/upt ... uzd7OMw.97
https://www.cisco.com/c/en/us/support/d ... voice.html
Jitter is defined as a variation in the delay of received packets. At the sending side, packets are sent in a continuous stream with the packets spaced evenly apart. Due to network congestion, improper queuing, or configuration errors, this steady stream can become lumpy, or the delay between each packet can vary instead of remaining constant.
Re: Thoughts around a Lejonklou Streamer
Just google ”Jitter in da conversion”. The first hit from TNT Audio is good, read all five pages:doze84 wrote:I would love read up on this, do you have a link that can point me faster to the right information?lejonklou wrote:doze84: You need to learn about how jitter affects D/A conversions. It has nothing to do with loss of data. If you want a discussion, you need to catch up on this, otherwise we can’t communicate.
https://www.tnt-audio.com/clinica/diginterf1_e.html
Re: Thoughts around a Lejonklou Streamer
It doesn't need to be Ethernet at layer-2, but yes, packet based networks.doze84 wrote:Edit: Oh you mean ethernet jitter. It doesn't matter that the ethernet packets arrives with delays or at different pace, as long as the ethernet is faster than the playback of the music(as long as a buffer is used).
Re: Thoughts around a Lejonklou Streamer
So you need the least possible errors, hence Ethernet cables that better prevent cross-talk and any mis-reading of each bit will improve sound, I assume?Music at Home wrote:Doze84, There is a device in the receiver called a PHY chip. It's job is to translate the analog waveform on the Ethernet copper pairs into digital data. In order to do that, it needs to constantly adjust it's own clocks to match the clock that generated the analog waveform in the first place. Jitter and noise in the analog waveform causes the PHY chip to work harder, constantly adjusting itself so it can accurately track the incoming waveform and know exactly when to measure the "1"'s and "0"'s within the analog representation. The harder that job is the more noise is injected into the receiver and this noise can make it's way into the analog section of the device.
From what I read earlier, all the network standards (1000BASE-T, 10GBASE-T) etc currently use the same clock frequency so I guess there is no benefit in using a slower link speed, like 100BASE-TX, in order to try any get a more reliable link.
-
- Active member
- Posts: 120
- Joined: 2008-10-09 16:10
Re: Thoughts around a Lejonklou Streamer
The jitter I'm talking about is even lower down in the hierarchy than that. I'm talking about the clock that determines the timing of the leading and falling edges of individual bits. If the receiving clock drifts with respect to the transmitting clock it will end up drifting out of sync to such a degree it won't be looking at exactly the right time to interpret individual 1's and 0's. Not only is there an absolute difference to be corrected, no clock is perfectly accurate, but its a constantly moving target due the jitter, i.e. the frequency of the generating clock varying around a central frequencyCharlie1 wrote: I understand. The jitter I'm familiar with resides higher up the network stack, and is primarily concerned with voice traffic being sent over IP networks:
https://www.cisco.com/c/en/us/support/d ... voice.htmlJitter is defined as a variation in the delay of received packets. At the sending side, packets are sent in a continuous stream with the packets spaced evenly apart. Due to network congestion, improper queuing, or configuration errors, this steady stream can become lumpy, or the delay between each packet can vary instead of remaining constant.
Re: Thoughts around a Lejonklou Streamer
I've never had to get involved in this L1 stuff but it's interesting.Music at Home wrote:The jitter I'm talking about is even lower down in the hierarchy than that. I'm talking about the clock that determines the timing of the leading and falling edges of individual bits. If the receiving clock drifts with respect to the transmitting clock it will end up drifting out of sync to such a degree it won't be looking at exactly the right time to interpret individual 1's and 0's. Not only is there an absolute difference to be corrected, no clock is perfectly accurate, but its a constantly moving target due the jitter, i.e. the frequency of the generating clock varying around a central frequency
So, does the switchport ASIC ever play a part in this? Do people find one group of ports can sound better than another cos they are connected to a different ASIC?
Re: Thoughts around a Lejonklou Streamer
I have probably read 100 pages about jitter before, but it has always been people dealt with errors transferred data, and probably not very scientifically. But from this text it seems that definition is wider than I thought. What you referred to as jitters, I referred to as electrical noise. Stuff that adds up and travels besides the data. Then I'm with you that every clock adds jitter. I'm still in the process of going through the link you sent. But I need to ask, would this be a reasonable explanation how this could survive over an optical link?lejonklou wrote:doze84: You need to learn about how jitter affects D/A conversions. It has nothing to do with loss of data. If you want a discussion, you need to catch up on this, otherwise we can’t communicate.
Music at Home wrote:Doze84, There is a device in the receiver called a PHY chip. It's job is to translate the analog waveform on the Ethernet copper pairs into digital data. In order to do that, it needs to constantly adjust it's own clocks to match the clock that generated the analog waveform in the first place. Jitter and noise in the analog waveform causes the PHY chip to work harder, constantly adjusting itself so it can accurately track the incoming waveform and know exactly when to measure the "1"'s and "0"'s within the analog representation. The harder that job is the more noise is injected into the receiver and this noise can make it's way into the analog section of the device.
Noise in the transmitting device produces jitter in the output. So essentially, noise creates jitter and jitter creates noise and this cascades throughout the system.
I'm sure there are other effects at play as well but hopefully this helps to explain why bit perfect is not the end of the story
Last edited by doze84 on 2018-03-29 16:01, edited 1 time in total.
-
- Active member
- Posts: 120
- Joined: 2008-10-09 16:10
Re: Thoughts around a Lejonklou Streamer
Doze, people use optical links in an audio setup with the intention of breaking the RFI type noise picked up by copper cabling, generated in the NAS, etc. These optical fibre links require media converters at either end with the output of the downstream converter being plugged into a streamer. These media converters are generally of a standard consumer quality of the sort found in standard cheap consumer grade switches and there will be no special attention paid to the quality, i.e. amount of jitter and noise, of their output. So it's quite conceivable that compared to a good quality Ethernet switch, the media converter actually sounds worse, simply because the media converter's Ethernet output contains it's own noise and jitter.
Re: Thoughts around a Lejonklou Streamer
So does all this only ever impact the link between streamer and connected device (i.e. switch/laptop)? I assume subsequent links, a hop beyond, do not cause issues?
Or do you think that link errors on the switchport connected to the NAS can impact the PHY performance of the switchport connected to the streamer?
Maybe a piece of string would be preferable after all :)
Or do you think that link errors on the switchport connected to the NAS can impact the PHY performance of the switchport connected to the streamer?
Maybe a piece of string would be preferable after all :)
-
- Active member
- Posts: 120
- Joined: 2008-10-09 16:10
Re: Thoughts around a Lejonklou Streamer
I can understand it being a cascading effect throughout the network. E.g. noise in the NAS contributes to jitter on it's output, jitter on the input to the switch contributes to noise inside the switch, noise in the switch contributes to jitter on it's output, jitter on the input to the streamer contributes to noise inside the streamer.
Re: Thoughts around a Lejonklou Streamer
I wonder if those Twinax copper direct attach cables (DACs) are any less error prone than normal RJ-45 patch leads. They only extend up to about 5m though (passive) or 10m (actively powered). They use SFP+ transceiver interfaces instead of RJ-45:
https://cdn.shopify.com/s/files/1/0178/ ... 1458248906
Very limited on Cisco switch models though, unless a noisy fan is acceptable. No doubt other vendors offer something similar at much lower cost.
https://cdn.shopify.com/s/files/1/0178/ ... 1458248906
Very limited on Cisco switch models though, unless a noisy fan is acceptable. No doubt other vendors offer something similar at much lower cost.
-
- Active member
- Posts: 120
- Joined: 2008-10-09 16:10
Re: Thoughts around a Lejonklou Streamer
Completely coincidental, but after posting that link in an earlier post to an explanation of how/why that USB regenerator device offers audible improvements in a USB interface, I came across an announcement from the same company, Uptone Audio, to say that they're working on an Ethernet regenerator, based in the same principles as the USB regen.
Tentative details here: https://www.computeraudiophile.com/foru ... ent=798379
It doesn't look like it will be cheap, but I've used the USB Regen in the past and thought it extremely effective and worthwhile, so I'll be keeping on eye on this. I'd be keen to evaluate it against my Netgear G105 with Teddy Pardo power supply and/or an 8-port Cisco Catalyst 2960 that arrived here recently
EDIT: New link here: https://www.computeraudiophile.com/foru ... tions-yet/
Tentative details here: https://www.computeraudiophile.com/foru ... ent=798379
It doesn't look like it will be cheap, but I've used the USB Regen in the past and thought it extremely effective and worthwhile, so I'll be keeping on eye on this. I'd be keen to evaluate it against my Netgear G105 with Teddy Pardo power supply and/or an 8-port Cisco Catalyst 2960 that arrived here recently
EDIT: New link here: https://www.computeraudiophile.com/foru ... tions-yet/
Last edited by Music at Home on 2018-04-03 22:31, edited 1 time in total.
Re: Thoughts around a Lejonklou Streamer
Just an idea, but how about a streamer with two power supplies. The first supply feeds a small board with an RJ-45 network interface for external connection. The second supply feeds the main board. The two boards are then linked together with a short cable, perhaps a ribbon cable. Could this approach help minimise the negative impact of the PHY?
Re: Thoughts around a Lejonklou Streamer
Great read! This was an interesting reality check! Particularly part 5 was an eye-opener. This stuff is complicated! ;-)lejonklou wrote: ...hit from TNT Audio is good, read all five pages:
https://www.tnt-audio.com/clinica/diginterf1_e.html
Re: Thoughts around a Lejonklou Streamer
I agree.teatime wrote:Great read! This was an interesting reality check! Particularly part 5 was an eye-opener. This stuff is complicated! ;-)lejonklou wrote: ...hit from TNT Audio is good, read all five pages:
https://www.tnt-audio.com/clinica/diginterf1_e.html
The real eye opener to me is “data dependent” jitter. This is not something that can be fixed easily.
What strikes me is that with digital the music signal is kind of “attacked” from within.
Playing cd’s…………
-
- Very active member
- Posts: 2297
- Joined: 2008-01-24 21:46
- Location: North East of The Black Country, UK
Re: Thoughts around a Lejonklou Streamer
Yes, I agree, a real eye opener. I didn't know there were so many types of jitter!
I wonder how something like data induced jitter differs from analog inter modulation distortion, non linear transfer functions (if that's the right name) or such like?
I wonder how something like data induced jitter differs from analog inter modulation distortion, non linear transfer functions (if that's the right name) or such like?
Re: Thoughts around a Lejonklou Streamer
Yes, I was surprised to read about the various types of jitter.
Does seem like a real minefield.
I think I'd need to read that 2-3 times to fully understand it all.
Does seem like a real minefield.
I think I'd need to read that 2-3 times to fully understand it all.
-
- Very active member
- Posts: 1089
- Joined: 2012-04-04 15:19
- Location: North Wales
- Contact:
Re: Thoughts around a Lejonklou Streamer
I'm not sure that jitter can be applied to ethernet packets?
Each packet contains the data and a checksum. For jitter to have an effect on the packet, it would have to switch one or more bits of data in the packet, and change the checksum to make the error in the packet acceptable when checked against the checksum. Seems very unlikely?
Each packet contains the data and a checksum. For jitter to have an effect on the packet, it would have to switch one or more bits of data in the packet, and change the checksum to make the error in the packet acceptable when checked against the checksum. Seems very unlikely?
KSH/0; KEBox/2; 3x Tundra Stereo 2.5; PMC fact.12. Blogger. Exakt Design. SO measuring.
-
- Active member
- Posts: 120
- Joined: 2008-10-09 16:10
Re: Thoughts around a Lejonklou Streamer
Sunbeamgls, I'm talking about at the physical level where 1's and 0's are encoded into an electrical waveform on the twisted pairs of an ethernet cable. At this level we're not dealing with packets and checksums, just encoded 1's and 0's. The 1's and 0's will get assembled into packets later, but before that can happen the 1's and 0's represented by the electrical waveform need recovering by the receiving device. See the diagram half way down this page here:
https://en.wikipedia.org/wiki/Manchester_code
Notice the clock? What happens if the frequency of the clock isn't fixed but is continuously varying by small amounts? If the receiving device doesn't keep track of the varying originating clock frequency due to the inevitable presence of clock jitter the transmitter and receiver will become unsynchronised and the receiver won't be able to decode the encoding. Within a certain tolerance, this timing variance in the encoded waveform (signal edges not being in where expected by the receiving device) is tracked and corrected in the physical interface layer within a PHY device. See Texas Intruments white paper here
http://www.ti.com/lit/an/snla254/snla254.pdf
From the Introduction of the above:
"The timing variations in signal edges from their ideal values is called Jitter. With the increase in data rates,
jitter has become important factor in system design. A clock with high jitter can cause performance
degradation in Ethernet subsystem such as compliance failures, high Bit Error Rate etc. Clock jitter can be
caused due to factors such as thermal noise, power supply variations, loading conditions, device nosie
and interference coupled from other circuit on the subsystem."
https://en.wikipedia.org/wiki/Manchester_code
Notice the clock? What happens if the frequency of the clock isn't fixed but is continuously varying by small amounts? If the receiving device doesn't keep track of the varying originating clock frequency due to the inevitable presence of clock jitter the transmitter and receiver will become unsynchronised and the receiver won't be able to decode the encoding. Within a certain tolerance, this timing variance in the encoded waveform (signal edges not being in where expected by the receiving device) is tracked and corrected in the physical interface layer within a PHY device. See Texas Intruments white paper here
http://www.ti.com/lit/an/snla254/snla254.pdf
From the Introduction of the above:
"The timing variations in signal edges from their ideal values is called Jitter. With the increase in data rates,
jitter has become important factor in system design. A clock with high jitter can cause performance
degradation in Ethernet subsystem such as compliance failures, high Bit Error Rate etc. Clock jitter can be
caused due to factors such as thermal noise, power supply variations, loading conditions, device nosie
and interference coupled from other circuit on the subsystem."
-
- Very active member
- Posts: 1089
- Joined: 2012-04-04 15:19
- Location: North Wales
- Contact:
Re: Thoughts around a Lejonklou Streamer
Yes, no argument at all about jitter causing errors, the important part to consider is if that matters or not. And it shouldn't matter because if the corrupted data in the packet does not match the checksum then the whole packet is rejected and re-sent. So regardless of the errors at the individual bit level, the message should not be passed up the stack to the streamer as it will have been rejected. This is one of the very good reasons for having a buffer in the streamer - rejected and re-sent packets do not impact on the stream feed as they are not time critical due to the buffering. Unless, of course, the packets are rejected for a longer time period than the buffer capacity, which would then lead to drop-outs.Music at Home wrote:Sunbeamgls, I'm talking about at the physical level where 1's and 0's are encoded into an electrical waveform on the twisted pairs of an ethernet cable. At this level we're not dealing with packets and checksums, just encoded 1's and 0's. The 1's and 0's will get assembled into packets later, but before that can happen the 1's and 0's represented by the electrical waveform need recovering by the receiving device. See the diagram half way down this page here:
https://en.wikipedia.org/wiki/Manchester_code
Notice the clock? What happens if the frequency of the clock isn't fixed but is continuously varying by small amounts? If the receiving device doesn't keep track of the varying originating clock frequency due to the inevitable presence of clock jitter the transmitter and receiver will become unsynchronised and the receiver won't be able to decode the encoding. Within a certain tolerance, this timing variance in the encoded waveform (signal edges not being in where expected by the receiving device) is tracked and corrected in the physical interface layer within a PHY device. See Texas Intruments white paper here
http://www.ti.com/lit/an/snla254/snla254.pdf
From the Introduction of the above:
"The timing variations in signal edges from their ideal values is called Jitter. With the increase in data rates,
jitter has become important factor in system design. A clock with high jitter can cause performance
degradation in Ethernet subsystem such as compliance failures, high Bit Error Rate etc. Clock jitter can be
caused due to factors such as thermal noise, power supply variations, loading conditions, device nosie
and interference coupled from other circuit on the subsystem."
KSH/0; KEBox/2; 3x Tundra Stereo 2.5; PMC fact.12. Blogger. Exakt Design. SO measuring.
Re: Thoughts around a Lejonklou Streamer
What MoH was describing last week is that the PHY within the streamer's network interface has to work harder the more jitter there is on the circuit. And the PHY working harder has been found to adversely affect the analogue stage components within the steamer.
EDIT:
Here's the post:
EDIT:
Here's the post:
Music at Home wrote:Doze84, There is a device in the receiver called a PHY chip. It's job is to translate the analog waveform on the Ethernet copper pairs into digital data. In order to do that, it needs to constantly adjust it's own clocks to match the clock that generated the analog waveform in the first place. Jitter and noise in the analog waveform causes the PHY chip to work harder, constantly adjusting itself so it can accurately track the incoming waveform and know exactly when to measure the "1"'s and "0"'s within the analog representation. The harder that job is the more noise is injected into the receiver and this noise can make it's way into the analog section of the device.
-
- Active member
- Posts: 120
- Joined: 2008-10-09 16:10
Re: Thoughts around a Lejonklou Streamer
Yes, this has nothing whatsoever to do with data errors, checksums, resending, etc. There are mechanism that have audible impacts that are totally independent of 100% bit accuracy delivered to the DAC. This was covered a page or two back.
Just to re-iterate though, this kind of jitter is not a cause of data errors. That's because the receiving device is constantly adjusting itself to keep track of the varying clock frequency on the incoming waveform in order that the encdoded data is 100% recovered, without errors occurring or resending being necessary. A secondary effect of that is that noise is generated in the network interface that makes it's way into analogue stages, or the clock circuit feeding the DAC chip.
Just to re-iterate though, this kind of jitter is not a cause of data errors. That's because the receiving device is constantly adjusting itself to keep track of the varying clock frequency on the incoming waveform in order that the encdoded data is 100% recovered, without errors occurring or resending being necessary. A secondary effect of that is that noise is generated in the network interface that makes it's way into analogue stages, or the clock circuit feeding the DAC chip.