Johnseye Posted May 7, 2017 Author Share Posted May 7, 2017 7 hours ago, jhwalker said: Correct - latency will have no effect on sound quality. Dropped packets, however, could certainly be noticeable if they got numerous enough. Incorrect - Jitter is caused by latency. You are on target regarding the dropped packets. If the interface and buffer can not handle the speed in which packets are are arriving packets will be dropped or out of order. Latency is the delay before acknowledgement packets are received. 2 hours ago, vortecjr said: What Chris doesn't explicitly mention is that it works fine for him at those same rates with RoonReady. He did confirmed for me that there is no change between 2.3 and 2.5. He also advised that he can reproduce the issue 100% of the time with some Linux devices and he can stop it from happening by inserting something like a Baaske isolator to slow down the traffic. Anyway if you are dropping tons of packets you can tell...it sounds like machine gun fire. That would be jitter. Fortunately I'm not hearing any signs of jitter despite the latency. It's small enough to where the buffer is able to handle it and I'm not going to conjecture causes. I am going to analyze the traffic with Wireshark, something I should have done long ago. Audio System Link to comment
firedog Posted May 7, 2017 Share Posted May 7, 2017 2 minutes ago, Johnseye said: Incorrect - Jitter is caused by latency. You are on target regarding the dropped packets. If the interface and buffer can not handle the speed in which packets are are arriving packets will be dropped or out of order. Latency is the delay before acknowledgement packets are received. That would be jitter. Fortunately I'm not hearing any signs of jitter despite the latency. It's small enough to where the buffer is able to handle it and I'm not going to conjecture causes. I am going to analyze the traffic with Wireshark, something I should have done long ago. I think you don't know what jitter is or the many possible causes... jhwalker 1 Main listening (small home office): Main setup: Surge protector +>Isol-8 Mini sub Axis Power Strip/Isolation>QuietPC Low Noise Server>Roon (Audiolense DRC)>Stack Audio Link II>Kii Control>Kii Three (on their own electric circuit) >GIK Room Treatments. Secondary Path: Server with Audiolense RC>RPi4 or analog>Cayin iDAC6 MKII (tube mode) (XLR)>Kii Three BXT Bedroom: SBTouch to Cambridge Soundworks Desktop Setup. Living Room/Kitchen: Ropieee (RPi3b+ with touchscreen) + Schiit Modi3E to a pair of Morel Hogtalare. All absolute statements about audio are false Link to comment
Johnseye Posted May 7, 2017 Author Share Posted May 7, 2017 13 minutes ago, firedog said: I think you don't know what jitter is or the many possible causes... Instead of flaming why don't you explain. What did I state that is incorrect and would cause your derogatory comment? And to be clear, I'm talking about packet jitter. Audio System Link to comment
jhwalker Posted May 7, 2017 Share Posted May 7, 2017 9 hours ago, ogs said: My experience on 2.3 is that latency drops to a very low level below 1 ms when you play music. From 192.168.x.x: bytes=60 seq=0001 TTL=64 ID=cc74 time=0.578ms From 192.168.x.x: bytes=60 seq=0002 TTL=64 ID=cd1e time=0.669ms From 192.168.x.x: bytes=60 seq=0003 TTL=64 ID=cec8 time=0.720ms From 192.168.x.x: bytes=60 seq=0004 TTL=64 ID=cfa4 time=0.737ms From 192.168.x.x: bytes=60 seq=0005 TTL=64 ID=d128 time=0.436ms From 192.168.x.x: bytes=60 seq=0006 TTL=64 ID=d280 time=0.425ms From 192.168.x.x: bytes=60 seq=0007 TTL=64 ID=d37c time=0.634ms From 192.168.x.x: bytes=60 seq=0008 TTL=64 ID=d4ec time=0.550ms From 192.168.x.x: bytes=60 seq=0009 TTL=64 ID=d6a1 time=0.647ms When not playing it is not so good: From 192.168.x.x: bytes=60 seq=0001 TTL=64 ID=329c time=29.987ms From 192.168.x.x: bytes=60 seq=0002 TTL=64 ID=3413 time=1.187ms From 192.168.x.x: bytes=60 seq=0003 TTL=64 ID=358e time=4.582ms From 192.168.x.x: bytes=60 seq=0004 TTL=64 ID=36ea time=9.752ms From 192.168.x.x: bytes=60 seq=0005 TTL=64 ID=387b time=14.886ms From 192.168.x.x: bytes=60 seq=0006 TTL=64 ID=38d1 time=20.124ms From 192.168.x.x: bytes=60 seq=0007 TTL=64 ID=3a2f time=25.098ms From 192.168.x.x: bytes=60 seq=0008 TTL=64 ID=3a34 time=30.334ms From 192.168.x.x: bytes=60 seq=0009 TTL=64 ID=3bf3 time=35.440ms have you tried this? 2.5 is consistent whether music is playing or not. I never get <1ms latency on my network, probably because I have a wireless bridge from my switch to the back of the room where I have my headphone setup. Thankfully, this has no effect on the sound. John Walker - IT Executive Headphone - SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable Ethernet > mRendu Roon endpoint > Topping D90 > Topping A90d > Dan Clark Expanse / HiFiMan H6SE v2 / HiFiman Arya Stealth Home Theater / Music -SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable HDMI > Denon X3700h > Anthem Amp for front channels > Revel F208-based 5.2.4 Atmos speaker system Link to comment
jhwalker Posted May 7, 2017 Share Posted May 7, 2017 1 hour ago, Johnseye said: Incorrect - Jitter is caused by latency. You are on target regarding the dropped packets. If the interface and buffer can not handle the speed in which packets are are arriving packets will be dropped or out of order. Latency is the delay before acknowledgement packets are received. That would be jitter. Fortunately I'm not hearing any signs of jitter despite the latency. It's small enough to where the buffer is able to handle it and I'm not going to conjecture causes. I am going to analyze the traffic with Wireshark, something I should have done long ago. Jitter, in audio terms, has nothing to do with network latency, or network traffic at all. They are two totally different things. Networks also use the term "jitter" to describe *variation* in packet delivery timing (not latency) but, again, this would not impact audio output once the packets are received; i.e., latency could be 250ms and it would have no impact on the audio as long as no packets are dropped. Jitter in audio terms would refer to timing issues between either the sending device (in this case, the microRendu) and the DAC (over USB), or within components of the DAC itself. Anything upstream of the microRendu is irrelevant, at least as far as audio jitter is concerned. John Walker - IT Executive Headphone - SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable Ethernet > mRendu Roon endpoint > Topping D90 > Topping A90d > Dan Clark Expanse / HiFiMan H6SE v2 / HiFiman Arya Stealth Home Theater / Music -SonicTransporter i9 running Roon Server > Netgear Orbi > Blue Jeans Cable HDMI > Denon X3700h > Anthem Amp for front channels > Revel F208-based 5.2.4 Atmos speaker system Link to comment
Johnseye Posted May 7, 2017 Author Share Posted May 7, 2017 22 minutes ago, jhwalker said: Jitter, in audio terms, has nothing to do with network latency, or network traffic at all. They are two totally different things. Networks also use the term "jitter" to describe *variation* in packet delivery timing (not latency) but, again, this would not impact audio output once the packets are received; i.e., latency could be 250ms and it would have no impact on the audio as long as no packets are dropped. Jitter in audio terms would refer to timing issues between either the sending device (in this case, the microRendu) and the DAC (over USB), or within components of the DAC itself. Anything upstream of the microRendu is irrelevant, at least as far as audio jitter is concerned. I haven't been referring to audio jitter at all and perhaps this is where there's confusion. We are strictly talking about the network interface and latency. Network jitter can be caused by latency. A little research will verify this, which I've done for you here. This relates to voice traffic, which is audio. Understanding Jitter in Packet Voice Networks What Causes Jitter? Jitter is generally caused by congestion in the IP network. The congestion can occur either at the router interfaces or in a provider or carrier network if the circuit has not been provisioned correctly. Conclusion Jitter is a variation in packet latency for voice packets. The DSPs inside the router can make up for some jitter, but can be overcome by excessive jitter. This results in poor voice quality. The cause of jitter is that a packet gets queued or delayed somewhere in the circuit, where there was no delay or queueing for other packets. This causes a variation in latency. Again, I'm not trying to make any conjecture, only to point out fact. I do not hear any jitter with my mR, only higher than expected latency. Also, if you're seeing higher than 1ms latency on your home network then let's just say it can be improved. The distances we're working with here are minuscule. And Jesus, for the record I didn't want to get into this discussion again here. I'm only responding, not trying to ruffle feathers. Audio System Link to comment
ogs Posted May 7, 2017 Share Posted May 7, 2017 25 minutes ago, jhwalker said: 2.5 is consistent whether music is playing or not. I never get <1ms latency on my network, probably because I have a wireless bridge from my switch to the back of the room where I have my headphone setup. Thankfully, this has no effect on the sound. I'll probably get 2.5 in mail tomorrow. My network is cabled all the way so I will check the same then. Thanks Link to comment
vortecjr Posted May 7, 2017 Share Posted May 7, 2017 57 minutes ago, Johnseye said: I haven't been referring to audio jitter at all and perhaps this is where there's confusion. We are strictly talking about the network interface and latency. Network jitter can be caused by latency. A little research will verify this, which I've done for you here. This relates to voice traffic, which is audio. If you mention jitter in an audiophile forum... jhwalker 1 SONORE computer audio | opticalRendu | ultraRendu | microRendu | Signature Rendu SE | endPoint | opticalModule DX | Power Supplies | Link to comment
vortecjr Posted May 7, 2017 Share Posted May 7, 2017 1 hour ago, ogs said: I'll probably get 2.5 in mail tomorrow. My network is cabled all the way so I will check the same then. Thanks This post gave me an idea. In the past I have tested this with the laptop connected to the router wirelessly. Test metrics: laptop hardwired to router, microRendu with Sonicorbiter 2.5 hard wired to router, music not playing: 64 bytes from 192.168.0.33: icmp_seq=0 ttl=64 time=0.982 ms 64 bytes from 192.168.0.33: icmp_seq=1 ttl=64 time=0.654 ms 64 bytes from 192.168.0.33: icmp_seq=2 ttl=64 time=0.658 ms 64 bytes from 192.168.0.33: icmp_seq=3 ttl=64 time=0.630 ms 64 bytes from 192.168.0.33: icmp_seq=4 ttl=64 time=0.615 ms 64 bytes from 192.168.0.33: icmp_seq=5 ttl=64 time=0.645 ms 64 bytes from 192.168.0.33: icmp_seq=6 ttl=64 time=0.619 ms 64 bytes from 192.168.0.33: icmp_seq=7 ttl=64 time=0.645 ms 64 bytes from 192.168.0.33: icmp_seq=8 ttl=64 time=0.635 ms 64 bytes from 192.168.0.33: icmp_seq=9 ttl=64 time=0.618 ms Test metrics: laptop hardwired to router, microRendu Sonicorbiter 2.5 hard wired to router, music playing: 64 bytes from 192.168.0.33: icmp_seq=0 ttl=64 time=0.435 ms 64 bytes from 192.168.0.33: icmp_seq=1 ttl=64 time=0.445 ms 64 bytes from 192.168.0.33: icmp_seq=2 ttl=64 time=0.652 ms 64 bytes from 192.168.0.33: icmp_seq=3 ttl=64 time=0.380 ms 64 bytes from 192.168.0.33: icmp_seq=4 ttl=64 time=0.614 ms 64 bytes from 192.168.0.33: icmp_seq=5 ttl=64 time=0.743 ms 64 bytes from 192.168.0.33: icmp_seq=6 ttl=64 time=0.636 ms 64 bytes from 192.168.0.33: icmp_seq=7 ttl=64 time=0.635 ms 64 bytes from 192.168.0.33: icmp_seq=8 ttl=64 time=0.642 ms 64 bytes from 192.168.0.33: icmp_seq=9 ttl=64 time=0.628 ms Test metrics: laptop wireless to router, microRendu Sonicorbiter 2.5 hard wired to router, music not playing: 64 bytes from 192.168.0.33: icmp_seq=0 ttl=64 time=1.453 ms 64 bytes from 192.168.0.33: icmp_seq=1 ttl=64 time=1.691 ms 64 bytes from 192.168.0.33: icmp_seq=2 ttl=64 time=4.509 ms 64 bytes from 192.168.0.33: icmp_seq=3 ttl=64 time=4.124 ms 64 bytes from 192.168.0.33: icmp_seq=4 ttl=64 time=1.730 ms 64 bytes from 192.168.0.33: icmp_seq=5 ttl=64 time=3.948 ms 64 bytes from 192.168.0.33: icmp_seq=6 ttl=64 time=4.120 ms 64 bytes from 192.168.0.33: icmp_seq=7 ttl=64 time=4.896 ms 64 bytes from 192.168.0.33: icmp_seq=8 ttl=64 time=1.611 ms 64 bytes from 192.168.0.33: icmp_seq=9 ttl=64 time=4.161 ms Test metrics: laptop wireless to router, microRendu Sonicorbiter 2.5 hard wired to router, music playing: 64 bytes from 192.168.0.33: icmp_seq=0 ttl=64 time=3.884 ms 64 bytes from 192.168.0.33: icmp_seq=1 ttl=64 time=4.179 ms 64 bytes from 192.168.0.33: icmp_seq=2 ttl=64 time=4.026 ms 64 bytes from 192.168.0.33: icmp_seq=3 ttl=64 time=4.320 ms 64 bytes from 192.168.0.33: icmp_seq=4 ttl=64 time=4.129 ms 64 bytes from 192.168.0.33: icmp_seq=5 ttl=64 time=4.150 ms 64 bytes from 192.168.0.33: icmp_seq=6 ttl=64 time=6.710 ms 64 bytes from 192.168.0.33: icmp_seq=7 ttl=64 time=4.149 ms 64 bytes from 192.168.0.33: icmp_seq=8 ttl=64 time=1.858 ms 64 bytes from 192.168.0.33: icmp_seq=9 ttl=64 time=4.033 ms SONORE computer audio | opticalRendu | ultraRendu | microRendu | Signature Rendu SE | endPoint | opticalModule DX | Power Supplies | Link to comment
Johnseye Posted May 7, 2017 Author Share Posted May 7, 2017 17 minutes ago, vortecjr said: If you mention jitter in an audiophile forum... Yea but the context is network latency. I guess some people get easily confused, and I can understand when they read jitter automatically think audio. I'll see if I can figure anything out with a Wireshark analysis if you're interested. Anyway, thanks for moving the posts here. Audio System Link to comment
Johnseye Posted May 7, 2017 Author Share Posted May 7, 2017 8 minutes ago, vortecjr said: This post gave me an idea. In the past I have tested this with the laptop connected to the router wirelessly. Test metrics: laptop hardwired to router, microRendu with Sonicorbiter 2.5 hard wired to router, no music playing: PING 192.168.0.33 (192.168.0.33): 56 data bytes 64 bytes from 192.168.0.33: icmp_seq=0 ttl=64 time=0.982 ms 64 bytes from 192.168.0.33: icmp_seq=1 ttl=64 time=0.654 ms 64 bytes from 192.168.0.33: icmp_seq=2 ttl=64 time=0.658 ms 64 bytes from 192.168.0.33: icmp_seq=3 ttl=64 time=0.630 ms 64 bytes from 192.168.0.33: icmp_seq=4 ttl=64 time=0.615 ms 64 bytes from 192.168.0.33: icmp_seq=5 ttl=64 time=0.645 ms 64 bytes from 192.168.0.33: icmp_seq=6 ttl=64 time=0.619 ms 64 bytes from 192.168.0.33: icmp_seq=7 ttl=64 time=0.645 ms 64 bytes from 192.168.0.33: icmp_seq=8 ttl=64 time=0.635 ms 64 bytes from 192.168.0.33: icmp_seq=9 ttl=64 time=0.618 ms Test metrics: laptop hardwired to router, microRendu Sonicorbiter 2.5 hard wired to router, music playing: 64 bytes from 192.168.0.33: icmp_seq=0 ttl=64 time=0.435 ms 64 bytes from 192.168.0.33: icmp_seq=1 ttl=64 time=0.445 ms 64 bytes from 192.168.0.33: icmp_seq=2 ttl=64 time=0.652 ms 64 bytes from 192.168.0.33: icmp_seq=3 ttl=64 time=0.380 ms 64 bytes from 192.168.0.33: icmp_seq=4 ttl=64 time=0.614 ms 64 bytes from 192.168.0.33: icmp_seq=5 ttl=64 time=0.743 ms 64 bytes from 192.168.0.33: icmp_seq=6 ttl=64 time=0.636 ms 64 bytes from 192.168.0.33: icmp_seq=7 ttl=64 time=0.635 ms 64 bytes from 192.168.0.33: icmp_seq=8 ttl=64 time=0.642 ms 64 bytes from 192.168.0.33: icmp_seq=9 ttl=64 time=0.628 ms There we go! I'm a happy man. Case closed, no more concerns and I won't be doing an analysis. Thanks! Audio System Link to comment
Recommended Posts