microRendu, NUC, JRiver and Roon

[udis]

Similar to mine in that it is inconsistent and high. All other devices on my network are 1ms

 

Reply from 192.168.0.22: bytes=32 time=70ms TTL=64Reply from 192.168.0.22: bytes=32 time=77ms TTL=64Reply from 192.168.0.22: bytes=32 time=84ms TTL=64Reply from 192.168.0.22: bytes=32 time=91ms TTL=64Reply from 192.168.0.22: bytes=32 time=98ms TTL=64Reply from 192.168.0.22: bytes=32 time=4ms TTL=64Reply from 192.168.0.22: bytes=32 time=11ms TTL=64Reply from 192.168.0.22: bytes=32 time=18ms TTL=64Reply from 192.168.0.22: bytes=32 time=25ms TTL=64Reply from 192.168.0.22: bytes=32 time=32ms TTL=64Reply from 192.168.0.22: bytes=32 time=39ms TTL=64Reply from 192.168.0.22: bytes=32 time=46ms TTL=64Reply from 192.168.0.22: bytes=32 time=52ms TTL=64Reply from 192.168.0.22: bytes=32 time=59ms TTL=64Reply from 192.168.0.22: bytes=32 time=66ms TTL=64Ping statistics for 192.168.0.22: Packets: Sent = 15, Received = 15, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 4ms, Maximum = 98ms, Average = 51ms

 

 

Because ping is a measure of latency or delay and a basic measurement of network health. I would ping from the mRendu if I could, but it doesn't appear possible. I can ping California from Chicago in less time than it takes to ping 30 ft in my house with the mRendu. I'm trying to determine if something is wrong with the device or if there's an actual reason for the high latency. I don't care about GUI access, I care about network throughput and error, packet loss, etc. There doesn't appear to be any loss, but inconsistent and high ping times from network devices indicate a problem. If this was by design I'd just like to know why so I can have piece of mind.

 

I have a similar ping results, i.e. inconsistent and high. Does anyone have experience with sms 200 ping performance?

[Johnseye]

I have a similar ping results, i.e. inconsistent and high. Does anyone have experience with sms 200 ping performance?

I would like to know as well. I'm tempted to buy an sms-200 to compare the two devices.

 

John S. who developed the hardware for the microRendu was very helpful in testing the hardware by installing another version of Linux on an SD card inserted into the mRendu. He found the pings were less than 1ms. That conversation was pulled from the microRendu thread and put here: http://www.computeraudiophile.com/f26-sonore-sponsored/sporadic-ping-times-31869/

 

Because it is unlikely a hardware issue that leaves the OS configuration or driver as highly probable causes. The other two involved in developing the microRendu are Andrew from Small Green and Jesus at Sonore. When asked about the issue in the Sonore vendor forum Jesus stated they will be releasing the 2.4 version of Sonic Orbiter OS soon, but will not evaluate the ping issue for that release. He stated they would look into the issue for the next 2.5 release. I asked if they would consider it for 2.4 and received defensive and angry responses. There is acknowledgement of a problem, but no known cause for the high, inconsistent pings.

 

I have received private communication expressing additional concerns and asking me to politely press Sonore, which I did in the microRendu thread. The response I received was increasingly defensive and angry. The bottom line is that they are not going to do anything about it soon, and will not provide any information that they might know about it.

 

Multiple people including John S himself have found the microRendu to exhibit this behavior. Random people have replied that it shouldn't be considered a problem because they don't hear anything wrong. They would prefer nothing be said. Where does saying or doing nothing get us? Who knows, maybe it has no impact, but then again maybe it does. The ping times don't lie.

 

I've just started looking into the repercussions of latency in audio. It has an impact on the AD and DA conversion as well as USB clock timing. This PreSonus website goes into some detail. They address it from a live music recording standpoint because the impact of latency in that scenario is critical. Listening back to the music in a DA conversion is less critical for us casual music listeners, but latency has an impact. There is also a buffer involved which can help, but at a performance cost. Here is some of the info from that site, but I'd recommend giving the site a quick read as it's all very helpful.

 

"our brain is wired so that it doesn’t notice if sounds are delayed 3 to 10 milliseconds (ms). Studies have shown that sound reflections in an acoustic space must be delayed by 20 to 30 ms before your brain will perceive them as separate. However, by around 12 to 15 ms (depending on the listener), you will start to “feel” the effects of a delayed signal. It is this amount of delay that we must battle constantly when recording and monitoring digitally."

 

 

[rickca]

I have a similar ping results, i.e. inconsistent and high. Does anyone have experience with sms 200 ping performance?

Perhaps @romaz can give us an answer?

[vortecjr]

Let's have a look at some of the things you have been saying for the past few days. Not mentions other insinuations, innuendo and threating to post in the non sponsored thread.

1. it's the on board NIC

2. the unit is defective

3. NIC on the microRendu is faulty

4. something else is going on

5. due to CPU lag

6. problems due to temperature

7. a driver issue, etc

8. its a bug

9. exhibiting faulty behavior

10. caused a clock issue

 

Meanwhile your unit is actually working fine as noted by you. I said I would happy to look into it, but somehow that is not good enough for you.

 

Anyway, I had a look at your PreSonus white paper and I really fail to see the relevancy of it and your quote above. That article is talking about the delay from speaking into a microphone, passing it thought a recording system and listening to the output all in real time. Of course there will be a delay with that setup. However, this has nothing to do with the ping time of the microRendu on the network. This has even less to do with the microRendu playing music in real time. Clearly, you didn't give this much thought.

[Johnseye]

Let's have a look at some of the things you have been saying for the past few days. Not mentions other insinuations, innuendo and threating to post in the non sponsored thread.

1. it's the on board NIC

2. the unit is defective

3. NIC on the microRendu is faulty

4. something else is going on

5. due to CPU lag

6. problems due to temperature

7. a driver issue, etc

8. its a bug

9. exhibiting faulty behavior

10. caused a clock issue

 

Meanwhile your unit is actually working fine as noted by you. I said I would happy to look into it, but somehow that is not good enough for you.

 

Anyway, I had a look at your PreSonus white paper and I really fail to see the relevancy of it and your quote above. That article is talking about the delay from speaking into a microphone, passing it thought a recording system and listening to the output all in real time. Of course there will be a delay with that setup. However, this has nothing to do with the ping time of the microRendu on the network. This has even less to do with the microRendu playing music in real time. Clearly, you didn't give this much thought.

The article has to do with digital latency which ping time is a measurement of.

 

I sent you an email. Maybe we can discuss this offline.

[plissken]

I've just started looking into the repercussions of latency in audio. It has an impact on the AD and DA conversion as well as USB clock timing. This PreSonus website goes into some detail. They address it from a live music recording standpoint because the impact of latency in that scenario is critical. Listening back to the music in a DA conversion is less critical for us casual music listeners, but latency has an impact. There is also a buffer involved which can help, but at a performance cost. Here is some of the info from that site, but I'd recommend giving the site a quick read as it's all very helpful.

 

our brain is wired so that it doesn’t notice if sounds are delayed 3 to 10 milliseconds (ms). Studies have shown that sound reflections in an acoustic space must be delayed by 20 to 30 ms before your brain will perceive them as separate. However, by around 12 to 15 ms (depending on the listener), you will start to “feel” the effects of a delayed signal. It is this amount of delay that we must battle constantly when recording and monitoring digitally."

 

 

To be fair, the PreSonus article is talking about Operating System and USB Bus delay with real time A to D. They aren't speaking to non-real time playback.

 

As long as the system has a buffer that is larger than the 60ms for the types of bitrates it can support then it won't be an issue for that particular line item.

 

Does anyone have an idea of how much buffer is set aside. For a vertical product like this I would really like to see 128MB set aside. Is the buffer OS addressable?

 

128MB would allow for a minute of 24/192 to be buffered.

[plissken]

Why can't the unit be SSH'd into?

 

Run top and start killing processes while running a constant ping? That will at least start answering some questions.

[Johnseye]

To be fair, the PreSonus article is talking about Operating System and USB Bus delay with real time A to D. They aren't speaking to non-real time playback.

 

As long as the system has a buffer that is larger than the 60ms for the types of bitrates it can support then it won't be an issue for that particular line item.

 

Does anyone have an idea of how much buffer is set aside. For a vertical product like this I would really like to see 128MB set aside. Is the buffer OS addressable?

 

128MB would allow for a minute of 24/192 to be buffered.

Correct and I did state this in my post.

[plissken]

Correct and I did state this in my post.

 

Yes you did :-)

[Johnseye]

Yes you did :-)

And I am being hard. It could be any of the 10 things listed, although #1 & 3 are the same and John S eliminated that one. I don't know if I ever actually said it was defective so #2 counts for 1/2. I don't know what #4 something else is going on means exactly so that doesn't really count and #9 exhibiting faulty behavior kind of covers them all so let's take away another 1/2. So that's like 6 actual possibilities, all of which are plausible, but there can be only one actual cause. I'm done guessing and that's all I can do because no information is being provided other than John S's test, and I don't think anything is really known at this point.

[plissken]

And I am being hard. It could be any of the 10 things listed, although #1 & 3 are the same and John S eliminated that one. I don't know if I ever actually said it was defective so #2 counts for 1/2. I don't know what #4 something else is going on means exactly so that doesn't really count and #9 exhibiting faulty behavior kind of covers them all so let's take away another 1/2. So that's like 6 actual possibilities, all of which are plausible, but there can be only one actual cause. I'm done guessing and that's all I can do because no information is being provided other than John S's test, and I don't think anything is really known at this point.

 

I think a potentially larger issue at play, and there is another thread here where Chris passed on a developer's name with expertise in TCP/IP and device drivers to an outfit, is that audio people may not understand the data busses like they may need to.

 

IMO if I personally put together an audio playback computer that exhibited like behavior a certain contingent would be out for my blood and all sorts of name calling would ensue. It's fickle around here.

[vortecjr]

Here is the ping time on my system with the unit at idle:

64 bytes from 192.168.0.228: icmp_seq=0 ttl=64 time=43.476 ms

64 bytes from 192.168.0.228: icmp_seq=1 ttl=64 time=46.293 ms

64 bytes from 192.168.0.228: icmp_seq=2 ttl=64 time=41.179 ms

64 bytes from 192.168.0.228: icmp_seq=3 ttl=64 time=34.044 ms

64 bytes from 192.168.0.228: icmp_seq=4 ttl=64 time=28.942 ms

 

Here is the ping time on my system with the unit playing DSD256:

64 bytes from 192.168.0.228: icmp_seq=0 ttl=64 time=1.337 ms

64 bytes from 192.168.0.228: icmp_seq=1 ttl=64 time=1.824 ms

64 bytes from 192.168.0.228: icmp_seq=2 ttl=64 time=1.570 ms

64 bytes from 192.168.0.228: icmp_seq=3 ttl=64 time=1.426 ms

64 bytes from 192.168.0.228: icmp_seq=4 ttl=64 time=1.994 ms

 

Someone actually gave you the hint back in one of threads...just listen to music.

[Peter_T]

I have my SOTM200 connected directly to NIC1 of my NUC and NIC2 connected to my router. No network bridge (not possible in W2016-core) but with a DHCP server program (http://www.dhcpserver.de).

 

Ping times (100x 64 bytes) all <1 ms without music playing and the same < 1 ms with music playing (Jriver DLNA server on my NUC, music on my NAS, connected to router) up to DSD128.

[jimmy.kl]

FWIW here is my MicroRendu at idle, it is connected by cat6 directly to my router, ping from my laptop on 801.11n wifi:

 

PING 192.168.1.12 (192.168.1.12): 56 data bytes

64 bytes from 192.168.1.12: icmp_seq=0 ttl=64 time=438.994 ms

64 bytes from 192.168.1.12: icmp_seq=1 ttl=64 time=89.284 ms

64 bytes from 192.168.1.12: icmp_seq=2 ttl=64 time=95.554 ms

64 bytes from 192.168.1.12: icmp_seq=3 ttl=64 time=103.931 ms

64 bytes from 192.168.1.12: icmp_seq=4 ttl=64 time=10.969 ms

64 bytes from 192.168.1.12: icmp_seq=5 ttl=64 time=20.030 ms

 

And when playing 44.1/16 FLAC in MPD mode via Minimserver on my NAS (also ethernet):

 

PING 192.168.1.12 (192.168.1.12): 56 data bytes

64 bytes from 192.168.1.12: icmp_seq=0 ttl=64 time=6.120 ms

64 bytes from 192.168.1.12: icmp_seq=1 ttl=64 time=8.691 ms

64 bytes from 192.168.1.12: icmp_seq=2 ttl=64 time=7.814 ms

64 bytes from 192.168.1.12: icmp_seq=3 ttl=64 time=4.317 ms

64 bytes from 192.168.1.12: icmp_seq=4 ttl=64 time=6.797 ms

64 bytes from 192.168.1.12: icmp_seq=5 ttl=64 time=5.701 ms

 

And in RoonReady mode via Roon on my laptop:

 

PING 192.168.1.12 (192.168.1.12): 56 data bytes

64 bytes from 192.168.1.12: icmp_seq=0 ttl=64 time=1.121 ms

64 bytes from 192.168.1.12: icmp_seq=1 ttl=64 time=1.097 ms

64 bytes from 192.168.1.12: icmp_seq=2 ttl=64 time=5.497 ms

64 bytes from 192.168.1.12: icmp_seq=3 ttl=64 time=3.106 ms

64 bytes from 192.168.1.12: icmp_seq=4 ttl=64 time=6.514 ms

64 bytes from 192.168.1.12: icmp_seq=5 ttl=64 time=0.980 ms

 

For a baseline, always important when you're testing, here's that laptop's ping directly to the router:

 

PING 192.168.1.1 (192.168.1.1): 56 data bytes

64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.970 ms

64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.078 ms

64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.982 ms

64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.029 ms

64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.800 ms

64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.953 ms

 

So really I can't see how the MicroRendu can do much better…

 

My best guess is when audio is inactive the system is throttled back and ping's ICMP packets just aren't important enough to make the system jump up in a hurry.

 

There's probably some gnarly config or kernel module wrangling Andrew could do to 'improve' the ping response but personally I like a device which sounds great and don't really care if it responds really, really quickly to me pinging it!

 

Enough time at the terminal, back to the music…

[Johnseye]

Here is the ping time on my system with the unit at idle:

64 bytes from 192.168.0.228: icmp_seq=0 ttl=64 time=43.476 ms

64 bytes from 192.168.0.228: icmp_seq=1 ttl=64 time=46.293 ms

64 bytes from 192.168.0.228: icmp_seq=2 ttl=64 time=41.179 ms

64 bytes from 192.168.0.228: icmp_seq=3 ttl=64 time=34.044 ms

64 bytes from 192.168.0.228: icmp_seq=4 ttl=64 time=28.942 ms

 

Here is the ping time on my system with the unit playing DSD256:

64 bytes from 192.168.0.228: icmp_seq=0 ttl=64 time=1.337 ms

64 bytes from 192.168.0.228: icmp_seq=1 ttl=64 time=1.824 ms

64 bytes from 192.168.0.228: icmp_seq=2 ttl=64 time=1.570 ms

64 bytes from 192.168.0.228: icmp_seq=3 ttl=64 time=1.426 ms

64 bytes from 192.168.0.228: icmp_seq=4 ttl=64 time=1.994 ms

 

Someone actually gave you the hint back in one of threads...just listen to music.

 

You'll never get a network engineer to say high, sporadic ping times is normal. If it were done intentionally then there is a reason to explain what is typically an indication of a problem. Now would you be kind enough to tell us why your timing is different when idle? If it is intentional then that's all we're really looking for. All this back and forth could have been and still can be over.

 

I emailed this to you yesterday, but have not received a response. Would you respectfully accept the return of my microRendu which was delivered to me on Feb. 9th. Order #5HK27547J1920041F. Thanks.

[Kevin M.]

I'm also highly suspicious of network rendering as a means of improving SQ. You have to understand that it looks counter-intuitive to add several active components which re-create a square wave several times over...just to get rid of source-generated electrical noise? The DAC's receiver is still creating self-noise from processing USB packets.

 

Since the only option for high rate DSD is USB/I2S these schemes can't work for me anyway. I got a Paul Pang v3 USB card...with external power and a 24MHz OCXO clock I really doubt you'd get better out of a series of cheap consumer network devices and rendering gadget.

 

 

Sent from my iPad using Computer Audiophile

I too am baffled. The theory of isolation between the devices and the core server seems to be refuted by the fact that the sound improves with a direct LAN connection. Yet, there seem to be a consensus that it does work. Do you know of anyone that has compared the Paul Pang V3 vs the mrendu and the host of tweak devices connected to it?

[Peter_T]

I have my SOTM200 connected directly to NIC1 of my NUC and NIC2 connected to my router. No network bridge (not possible in W2016-core) but with a DHCP server program (www.dhcpserver.de). Ping times (100x 64 bytes) all <1 ms without music playing and the same < 1 ms with music playing (Jriver DLNA server on my NUC, music on my NAS, connected to router) up to DSD128.

I checked also the setup with the SOTM200 and NUC connected to a TPlink 5-port Gb switch and the switch connected to my router. No difference in ping times NUC>SOTM from the "direct connection" described above. All pings < 1ms with or without music.

[udis]

I would like to know as well. I'm tempted to buy an sms-200 to compare the two devices.

 

Me too. However, i am waiting for the release of the sms-200 ultra. Should have a much better clock among other things...

[Johnseye]

So really I can't see how the MicroRendu can do much better…

 

My best guess is when audio is inactive the system is throttled back and ping's ICMP packets just aren't important enough to make the system jump up in a hurry.

 

There's probably some gnarly config or kernel module wrangling Andrew could do to 'improve' the ping response but personally I like a device which sounds great and don't really care if it responds really, really quickly to me pinging it!

This is great info and much more than the idle pings everyone else has done. I'll do the same, but would expect similar results as the idle results have been consistent across the board.

 

As you stated, it is still a guess. This is in fact what John S already stated he was guessing is going on. Again, he was just guessing as well and he's a co-designer. Why throttle ICMP when the OS is in an idle state? You would want to do that when it's processing audio. Your guess is as good as mine and it probably is related to either the kernel or driver config. I don't care either as long as I know that was the design, that it can't or shouldn't be corrected or improved, and that is the one piece of information that has yet to be provided.

 

I want to be told this is occurring, because it is how the mR was designed because of X. Until then it is your best guess, my innuendo or whatever we want to call it. Neither of us have the answer, and yes I'm going to enjoy listening to the music with it regardless because it's improved my sound from before, and it's made my DAC placement more flexible.

[Johnseye]

I'm listening to music through the microRendu now and F me the ping times are <1ms. I pause the music and it jumps up, high and inconsistent. I start playing music again, and it doesn't matter what sample rate PCM or DSD, the ping time goes back down to under 1ms.

 

So @jimmy\.kl stepped in. Thanks for that jimmy.

 

In the heat of my frustration and back and forth with Jesus I asked him if he'd take back my microRendu. He wouldn't as I don't think they do returns. He would help me sell it though which was pretty fair imo. But, I also placed an order for the sMS-200. So I'm going to have fun with both of these very special end point filters and see which I like more. I originally started this thread because I wanted to understand what the benefit would be by using an endpoint instead of direct from PC. I had to hear it for myself. The change is subtle, but it's there and I wouldn't go back. It also allows me to use fiber ethernet and after hearing the subtle difference that has, I wouldn't go back. There is no question to my ears that we are removing noise by doing this.

 

At the same time I also made some macro changes. I was also in the market for a new pair of speakers and ultimately found some I like a lot. In that discussion it was recommended I look into a different amp, so I changed that as well. That journey is here http://www.computeraudiophile.com/f12-headphones-and-speakers/reference-2-channel-speaker-recommendations-31596/ . I've completely changed my 2 channel sound for the better. Thanks to all those who've helped with their suggestions.

[plissken]

Today I was busy imaging up computers with Acronis. While imaging from the .tid file on my NAS to the SSD drive plugged into a USB 3.0 2.5" drive adapter and watching an HD movie from Netflix while doing so my ping times were still under 1ms regardless of load.

 

I can understand why people are curious about behavior of a device that doesn't trend with what is considered normal for any other device.

 

I'm certainly interested in what is being implemented the cause this behavior. IMO it IS odd behavior.

[Johnseye]

I have been in communication with Jesus who indicates v2.5 addresses the high latency found in 2.3.  He shared some of the ping times with me, but I'll wait to post anything until I receive the 2.5 update and test myself.  I'm glad this issue is being addressed and it looks like things are headed in the right direction.

 

For those who are using Roon, HQ Player and the microRendu or sMS-200, are you using Roon to HQ Player with NAA to the mR or sMS as an HQ Player endpoint, and not the Roon endpoint?  This is how I've been able to use HQ Player in the chain, but am wondering if there's a better way.

[rickca]

1 hour ago, Johnseye said:

I have been in communication with Jesus who indicates v2.5 addresses the high latency found in 2.3.  He shared some of the ping times with me, but I'll wait to post anything until I receive the 2.5 update and test myself.  I'm glad this issue is being addressed and it looks like things are headed in the right direction.

 

Didn't Sonore previously claim that the wide fluctuation in ping times on an idle micro rendu was a non-issue?  If so, why are they fixing it?

[Johnseye]

1 hour ago, rickca said:

Didn't Sonore previously claim that the wide fluctuation in ping times on an idle micro rendu was a non-issue?  If so, why are they fixing it?

[rickca]

Excuse me for being dense, but I don't get the joke.  Is it that the obvious droids are wearing stupid disguises?  What has that got to do with my question?