Sporadic ping times (case closed)

[Johnseye]

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.

[firedog]

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...

[Johnseye]

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.

[jhwalker]

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.

[jhwalker]

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.

[Johnseye]

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.

[ogs]

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

[vortecjr]

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...

[vortecjr]

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

 

 

[Johnseye]

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. 

[Johnseye]

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!