Jump to content
IGNORED

microRendu, NUC, JRiver and Roon


Recommended Posts

This is significant because a general purpose computer is difficult to run off of one of these recent supplies that block leakage currents or batteries, but the low powered microRendu will run very well off of them. (other low powered computers can also do that, but they may not have as high an SI). Thus a microRendu running off a leakage blocking supply, will probably give better sound than a highly optimized computer running off a SMPS or regular linear supply driving a REGEN.

 

There is the other issue of network implementations also affecting sound from the DAC, but I am not sure what is going on there. I personally have not heard this, but others have, I don't know what is going on with this. At this point none of the possible hypothesis make any sense to me, so there is a lot of work needed to be done to find out what is going on with this.

 

Did this help with your understanding of what is going on here?

 

John S.

 

Thanks for this post. But I have to disagree that general purpose computers are hard to configure in this manner. I've setup the ECS Liva with Windows 10 and JRiver, running off a 20 amp worth of battery for portability. Run times in excess of 10 hours.

 

The setup is small and uses Belkin 3 foot USB A/B cabling.

 

In my hypervisor I can show you a Windows 10 instance running at ~ 900MB out of 2GB RAM. You can move up the chain to 4GB RAM with their other SKU's. They do just fine with 24/192, MQA, etc...

 

On the networking side don't discount cognitive bias. I've setup an A/D to capture my DAC output and no one, so far with the tracks I posted, have been able to tell the difference in 315 of Berk-Tek CAT5e off the spool and terminated by me, and $330 12 foot CAT8.

Link to comment
Background: I currently have a very simple Windows 2012 R2 Server (think CAPS) with everything non-essential turned off, using Audiophile Optimizer...what else is there that can host JRiver and/or Roon and connect directly to the DAC?

 

I'm in a similar situation but have turned away from Roon because, if I understand correctly, it will not run on a PC in Audiophile Optimizer core mode, which I finally got running with my exaSound DAC. Am I mistaken on this?

Link to comment
  • 3 weeks later...
Can anyone with a microRendu tell me what their ping time to the microRendu is in ms (milliseconds)?

 

Thanks

 

64 bytes from 192.168.0.121: icmp_seq=0 ttl=64 time=25.745 ms64 bytes from 192.168.0.121: icmp_seq=1 ttl=64 time=30.252 ms64 bytes from 192.168.0.121: icmp_seq=2 ttl=64 time=39.382 ms64 bytes from 192.168.0.121: icmp_seq=3 ttl=64 time=47.800 ms64 bytes from 192.168.0.121: icmp_seq=4 ttl=64 time=56.633 ms64 bytes from 192.168.0.121: icmp_seq=5 ttl=64 time=23.813 ms64 bytes from 192.168.0.121: icmp_seq=6 ttl=64 time=67.559 ms64 bytes from 192.168.0.121: icmp_seq=7 ttl=64 time=50.209 ms64 bytes from 192.168.0.121: icmp_seq=8 ttl=64 time=81.230 ms64 bytes from 192.168.0.121: icmp_seq=9 ttl=64 time=3.106 ms64 bytes from 192.168.0.121: icmp_seq=10 ttl=64 time=11.679 ms64 bytes from 192.168.0.121: icmp_seq=11 ttl=64 time=20.797 ms64 bytes from 192.168.0.121: icmp_seq=12 ttl=64 time=29.590 ms64 bytes from 192.168.0.121: icmp_seq=13 ttl=64 time=36.964 ms64 bytes from 192.168.0.121: icmp_seq=14 ttl=64 time=46.842 ms64 bytes from 192.168.0.121: icmp_seq=15 ttl=64 time=55.561 ms64 bytes from 192.168.0.121: icmp_seq=16 ttl=64 time=64.603 ms64 bytes from 192.168.0.121: icmp_seq=17 ttl=64 time=57.705 ms64 bytes from 192.168.0.121: icmp_seq=18 ttl=64 time=82.802 ms64 bytes from 192.168.0.121: icmp_seq=19 ttl=64 time=58.924 ms64 bytes from 192.168.0.121: icmp_seq=20 ttl=64 time=101.686 ms64 bytes from 192.168.0.121: icmp_seq=21 ttl=64 time=6.818 ms64 bytes from 192.168.0.121: icmp_seq=22 ttl=64 time=14.992 ms64 bytes from 192.168.0.121: icmp_seq=23 ttl=64 time=22.933 ms64 bytes from 192.168.0.121: icmp_seq=24 ttl=64 time=29.263 ms64 bytes from 192.168.0.121: icmp_seq=25 ttl=64 time=38.830 ms64 bytes from 192.168.0.121: icmp_seq=26 ttl=64 time=49.262 ms64 bytes from 192.168.0.121: icmp_seq=27 ttl=64 time=54.914 ms64 bytes from 192.168.0.121: icmp_seq=28 ttl=64 time=61.937 ms64 bytes from 192.168.0.121: icmp_seq=29 ttl=64 time=54.941 ms64 bytes from 192.168.0.121: icmp_seq=30 ttl=64 time=79.521 ms64 bytes from 192.168.0.121: icmp_seq=31 ttl=64 time=56.641 ms64 bytes from 192.168.0.121: icmp_seq=32 ttl=64 time=89.202 ms64 bytes from 192.168.0.121: icmp_seq=33 ttl=64 time=3.429 ms64 bytes from 192.168.0.121: icmp_seq=34 ttl=64 time=14.715 ms64 bytes from 192.168.0.121: icmp_seq=35 ttl=64 time=23.412 ms64 bytes from 192.168.0.121: icmp_seq=36 ttl=64 time=29.704 ms64 bytes from 192.168.0.121: icmp_seq=37 ttl=64 time=38.064 ms64 bytes from 192.168.0.121: icmp_seq=38 ttl=64 time=46.310 ms64 bytes from 192.168.0.121: icmp_seq=39 ttl=64 time=57.054 ms64 bytes from 192.168.0.121: icmp_seq=40 ttl=64 time=65.280 ms

 

By comparison, other devices on my network tend to respond at about 3ms.

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
64 bytes from 192.168.0.121: icmp_seq=0 ttl=64 time=25.745 ms64 bytes from 192.168.0.121: icmp_seq=1 ttl=64 time=30.252 ms64 bytes from 192.168.0.121: icmp_seq=2 ttl=64 time=39.382 ms64 bytes from 192.168.0.121: icmp_seq=3 ttl=64 time=47.800 ms64 bytes from 192.168.0.121: icmp_seq=4 ttl=64 time=56.633 ms64 bytes from 192.168.0.121: icmp_seq=5 ttl=64 time=23.813 ms64 bytes from 192.168.0.121: icmp_seq=6 ttl=64 time=67.559 ms64 bytes from 192.168.0.121: icmp_seq=7 ttl=64 time=50.209 ms64 bytes from 192.168.0.121: icmp_seq=8 ttl=64 time=81.230 ms64 bytes from 192.168.0.121: icmp_seq=9 ttl=64 time=3.106 ms64 bytes from 192.168.0.121: icmp_seq=10 ttl=64 time=11.679 ms64 bytes from 192.168.0.121: icmp_seq=11 ttl=64 time=20.797 ms64 bytes from 192.168.0.121: icmp_seq=12 ttl=64 time=29.590 ms64 bytes from 192.168.0.121: icmp_seq=13 ttl=64 time=36.964 ms64 bytes from 192.168.0.121: icmp_seq=14 ttl=64 time=46.842 ms64 bytes from 192.168.0.121: icmp_seq=15 ttl=64 time=55.561 ms64 bytes from 192.168.0.121: icmp_seq=16 ttl=64 time=64.603 ms64 bytes from 192.168.0.121: icmp_seq=17 ttl=64 time=57.705 ms64 bytes from 192.168.0.121: icmp_seq=18 ttl=64 time=82.802 ms64 bytes from 192.168.0.121: icmp_seq=19 ttl=64 time=58.924 ms64 bytes from 192.168.0.121: icmp_seq=20 ttl=64 time=101.686 ms64 bytes from 192.168.0.121: icmp_seq=21 ttl=64 time=6.818 ms64 bytes from 192.168.0.121: icmp_seq=22 ttl=64 time=14.992 ms64 bytes from 192.168.0.121: icmp_seq=23 ttl=64 time=22.933 ms64 bytes from 192.168.0.121: icmp_seq=24 ttl=64 time=29.263 ms64 bytes from 192.168.0.121: icmp_seq=25 ttl=64 time=38.830 ms64 bytes from 192.168.0.121: icmp_seq=26 ttl=64 time=49.262 ms64 bytes from 192.168.0.121: icmp_seq=27 ttl=64 time=54.914 ms64 bytes from 192.168.0.121: icmp_seq=28 ttl=64 time=61.937 ms64 bytes from 192.168.0.121: icmp_seq=29 ttl=64 time=54.941 ms64 bytes from 192.168.0.121: icmp_seq=30 ttl=64 time=79.521 ms64 bytes from 192.168.0.121: icmp_seq=31 ttl=64 time=56.641 ms64 bytes from 192.168.0.121: icmp_seq=32 ttl=64 time=89.202 ms64 bytes from 192.168.0.121: icmp_seq=33 ttl=64 time=3.429 ms64 bytes from 192.168.0.121: icmp_seq=34 ttl=64 time=14.715 ms64 bytes from 192.168.0.121: icmp_seq=35 ttl=64 time=23.412 ms64 bytes from 192.168.0.121: icmp_seq=36 ttl=64 time=29.704 ms64 bytes from 192.168.0.121: icmp_seq=37 ttl=64 time=38.064 ms64 bytes from 192.168.0.121: icmp_seq=38 ttl=64 time=46.310 ms64 bytes from 192.168.0.121: icmp_seq=39 ttl=64 time=57.054 ms64 bytes from 192.168.0.121: icmp_seq=40 ttl=64 time=65.280 ms

 

By comparison, other devices on my network tend to respond at about 3ms.

 

Not sure how ping is relevant since normal communication with the micro rendu is recieve only. 60ms to use the GUI isn't a big deal

Regards,

Dave

 

Audio system

Link to comment

By comparison, other devices on my network tend to respond at about 3ms.

 

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

 

Not sure how ping is relevant since normal communication with the micro rendu is recieve only. 60ms to use the GUI isn't a big deal

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.

Link to comment
64 bytes from 192.168.0.121: icmp_seq=0 ttl=64 time=25.745 ms64 bytes from 192.168.0.121: icmp_seq=1 ttl=64 time=30.252 ms64 bytes from 192.168.0.121: icmp_seq=2 ttl=64 time=39.382 ms64 bytes from 192.168.0.121: icmp_seq=3 ttl=64 time=47.800 ms64 bytes from 192.168.0.121: icmp_seq=4 ttl=64 time=56.633 ms64 bytes from 192.168.0.121: icmp_seq=5 ttl=64 time=23.813 ms64 bytes from 192.168.0.121: icmp_seq=6 ttl=64 time=67.559 ms64 bytes from 192.168.0.121: icmp_seq=7 ttl=64 time=50.209 ms64 bytes from 192.168.0.121: icmp_seq=8 ttl=64 time=81.230 ms64 bytes from 192.168.0.121: icmp_seq=9 ttl=64 time=3.106 ms64 bytes from 192.168.0.121: icmp_seq=10 ttl=64 time=11.679 ms64 bytes from 192.168.0.121: icmp_seq=11 ttl=64 time=20.797 ms64 bytes from 192.168.0.121: icmp_seq=12 ttl=64 time=29.590 ms64 bytes from 192.168.0.121: icmp_seq=13 ttl=64 time=36.964 ms64 bytes from 192.168.0.121: icmp_seq=14 ttl=64 time=46.842 ms64 bytes from 192.168.0.121: icmp_seq=15 ttl=64 time=55.561 ms64 bytes from 192.168.0.121: icmp_seq=16 ttl=64 time=64.603 ms64 bytes from 192.168.0.121: icmp_seq=17 ttl=64 time=57.705 ms64 bytes from 192.168.0.121: icmp_seq=18 ttl=64 time=82.802 ms64 bytes from 192.168.0.121: icmp_seq=19 ttl=64 time=58.924 ms64 bytes from 192.168.0.121: icmp_seq=20 ttl=64 time=101.686 ms64 bytes from 192.168.0.121: icmp_seq=21 ttl=64 time=6.818 ms64 bytes from 192.168.0.121: icmp_seq=22 ttl=64 time=14.992 ms64 bytes from 192.168.0.121: icmp_seq=23 ttl=64 time=22.933 ms64 bytes from 192.168.0.121: icmp_seq=24 ttl=64 time=29.263 ms64 bytes from 192.168.0.121: icmp_seq=25 ttl=64 time=38.830 ms64 bytes from 192.168.0.121: icmp_seq=26 ttl=64 time=49.262 ms64 bytes from 192.168.0.121: icmp_seq=27 ttl=64 time=54.914 ms64 bytes from 192.168.0.121: icmp_seq=28 ttl=64 time=61.937 ms64 bytes from 192.168.0.121: icmp_seq=29 ttl=64 time=54.941 ms64 bytes from 192.168.0.121: icmp_seq=30 ttl=64 time=79.521 ms64 bytes from 192.168.0.121: icmp_seq=31 ttl=64 time=56.641 ms64 bytes from 192.168.0.121: icmp_seq=32 ttl=64 time=89.202 ms64 bytes from 192.168.0.121: icmp_seq=33 ttl=64 time=3.429 ms64 bytes from 192.168.0.121: icmp_seq=34 ttl=64 time=14.715 ms64 bytes from 192.168.0.121: icmp_seq=35 ttl=64 time=23.412 ms64 bytes from 192.168.0.121: icmp_seq=36 ttl=64 time=29.704 ms64 bytes from 192.168.0.121: icmp_seq=37 ttl=64 time=38.064 ms64 bytes from 192.168.0.121: icmp_seq=38 ttl=64 time=46.310 ms64 bytes from 192.168.0.121: icmp_seq=39 ttl=64 time=57.054 ms64 bytes from 192.168.0.121: icmp_seq=40 ttl=64 time=65.280 ms

 

By comparison, other devices on my network tend to respond at about 3ms.

 

I find those numbers hard to believe. Way to high IMO.

Link to comment
Not sure how ping is relevant since normal communication with the micro rendu is recieve only. 60ms to use the GUI isn't a big deal

 

It's relevant because it shouldn't be that high. Something it causing serious delay. We use the Lantronix Xport ($37 each in quantity) and even it's at 1ms or less.

Link to comment
It's relevant because it shouldn't be that high. Something it causing serious delay. We use the Lantronix Xport ($37 each in quantity) and even it's at 1ms or less.

 

I responded to this in the Sonore section, but my guess is that the audio threads have been given high priority so when a ping packet comes along the thread that replies has to wait for the audio thread. On a general purpose setup many threads have the same priority so the ping reply doesn't have to wait for other threads.

 

Thus I don't think this is any serious hardware malfunction, but a byproduct of the increase in priority of the audio threads.

 

John S.

Link to comment
I responded to this in the Sonore section, but my guess is that the audio threads have been given high priority so when a ping packet comes along the thread that replies has to wait for the audio thread. On a general purpose setup many threads have the same priority so the ping reply doesn't have to wait for other threads.

 

Thus I don't think this is any serious hardware malfunction, but a byproduct of the increase in priority of the audio threads.

 

John S.

 

John, I'll respond in the Sonore section to keep this conversation in one place, but considering you're the developer of the microRendu and use language such as "guess", then that concerns me. Please take this in the nicest way possible as I've appreciated your informative and detailed posts, including a great one in this thread. Not knowing your development role with the microRendu I don't understand why you wouldn't know exactly why this is occurring. Considering you can't state definitively why this is being caused, that uncertainty makes me even more skeptical.

 

The microRendu exhibits this behavior even when there is no audio being passed to the device. No audio threads being processed.

Link to comment
The microRendu exhibits this behavior even when there is no audio being passed to the device. No audio threads being processed.

I just made the same observation in the micro rendu thread earlier today.

Pareto Audio AMD 7700 Server --> Berkeley Alpha USB --> Jeff Rowland Aeris --> Jeff Rowland 625 S2 --> Focal Utopia 3 Diablos with 2 x Focal Electra SW 1000 BE subs

 

i7-6700K/Windows 10  --> EVGA Nu Audio Card --> Focal CMS50's 

Link to comment
I responded to this in the Sonore section, but my guess is that the audio threads have been given high priority so when a ping packet comes along the thread that replies has to wait for the audio thread. On a general purpose setup many threads have the same priority so the ping reply doesn't have to wait for other threads.

 

Thus I don't think this is any serious hardware malfunction, but a byproduct of the increase in priority of the audio threads.

 

John S.

 

I don't buy that. Even when I QOS portions of a network I still get ping rates sub 1 and 2 ms.

Link to comment
Thanks for this post. But I have to disagree that general purpose computers are hard to configure in this manner. I've setup the ECS Liva with Windows 10 and JRiver, running off a 20 amp worth of battery for portability. Run times in excess of 10 hours.

 

The setup is small and uses Belkin 3 foot USB A/B cabling.

 

In my hypervisor I can show you a Windows 10 instance running at ~ 900MB out of 2GB RAM. You can move up the chain to 4GB RAM with their other SKU's. They do just fine with 24/192, MQA, etc...

 

On the networking side don't discount cognitive bias. I've setup an A/D to capture my DAC output and no one, so far with the tracks I posted, have been able to tell the difference in 315 of Berk-Tek CAT5e off the spool and terminated by me, and $330 12 foot CAT8.

 

No one?????? Statistically speaking that seems improbable. Not bashing you, as tend to agree with your premise but I would expect some to get it right given the testing parameters (50/50 chance vs double blind)

Link to comment
No one?????? Statistically speaking that seems improbable. Not bashing you, as tend to agree with your premise but I would expect some to get it right given the testing parameters (50/50 chance vs double blind)

 

Correct. As of yet, no one that has listened to the tracks have reliably identified the times or numbers of swaps. It certainly needs more of a N but that's not up to me. That's up to the people that believe they can hear a difference.

Link to comment
Correct. As of yet, no one that has listened to the tracks have reliably identified the times or numbers of swaps. It certainly needs more of a N but that's not up to me. That's up to the people that believe they can hear a difference.

 

Ah ok, so you have introduced some variability into your test. It sounded like a simple A/B test, which would invariably lead to a high number of false positives.

Link to comment
Ah ok, so you have introduced some variability into your test. It sounded like a simple A/B test, which would invariably lead to a high number of false positives.

 

What I have done is post two tracks with swapping of cable being made during playback. My only questions are when was the swap made and what cable was in-situ during playback.

Link to comment
No one?????? Statistically speaking that seems improbable. Not bashing you, as tend to agree with your premise but I would expect some to get it right given the testing parameters (50/50 chance vs double blind)

 

Correct. As of yet, no one that has listened to the tracks have reliably identified the times or numbers of swaps. It certainly needs more of a N but that's not up to me. That's up to the people that believe they can hear a difference.

 

There would have to be significant interference in a home environment for a difference to be heard. Cat5e should be good enough within the recommended length let alone cat6 or 7. No special shielding beyond those cable's specs or special metals are going to change the data packets or sound. I think your test shows this is the case. Network cable is not analog cable.

Link to comment
There would have to be significant interference in a home environment for a difference to be heard. Cat5e should be good enough within the recommended length let alone cat6 or 7. No special shielding beyond those cable's specs or special metals are going to change the data packets or sound. I think your test shows this is the case. Network cable is not analog cable.

 

It is possible that there is some quality difference between cables within a class of cable. I am in the video technology industry and we recommend cat6a for all new premise based installations. I have found quite a bit of variability in USB cables unfortunately. That being said, one high quality USB 2.0 cable vs another is not going to make any difference.

Link to comment
It is possible that there is some quality difference between cables within a class of cable. I am in the video technology industry and we recommend cat6a for all new premise based installations. I have found quite a bit of variability in USB cables unfortunately. That being said, one high quality USB 2.0 cable vs another is not going to make any difference.

In video you have significant bandwidth utilization and it really comes down to the length of the run. Within the distance spec you'll be fine. Cat6 allows for a bit more length. If we're under let's say, 200ft there should be no issue. Unless there's significant EMI, which there shouldn't be in your home, "special" cable isn't necessary. The cost of cat6 or even 7 is so low it's worth it. Cat8 or what you might get from Audioquest Vodka cable isn't going to make any difference. Besides, no one is buying +300 ft. rolls of that cable.

Link to comment
In video you have significant bandwidth utilization and it really comes down to the length of the run. Within the distance spec you'll be fine. Cat6 allows for a bit more length. If we're under let's say, 200ft there should be no issue. Unless there's significant EMI, which there shouldn't be in your home, "special" cable isn't necessary. The cost of cat6 or even 7 is so low it's worth it. Cat8 or what you might get from Audioquest Vodka cable isn't going to make any difference. Besides, no one is buying +300 ft. rolls of that cable.

 

My testing is that 315' CAT5e had sub 1ms averaged ping response and 107MB/second transfer. Exactly the sames as the expensive CAT8.

Link to comment
It is possible that there is some quality difference between cables within a class of cable. I am in the video technology industry and we recommend cat6a for all new premise based installations. I have found quite a bit of variability in USB cables unfortunately. That being said, one high quality USB 2.0 cable vs another is not going to make any difference.

 

Given the costs and future speeds there's not reason not to just go with CAT6/a as default in a business.

Link to comment
John, I'll respond in the Sonore section to keep this conversation in one place, but considering you're the developer of the microRendu and use language such as "guess", then that concerns me. Please take this in the nicest way possible as I've appreciated your informative and detailed posts, including a great one in this thread. Not knowing your development role with the microRendu I don't understand why you wouldn't know exactly why this is occurring. Considering you can't state definitively why this is being caused, that uncertainty makes me even more skeptical.

 

The microRendu exhibits this behavior even when there is no audio being passed to the device. No audio threads being processed.

 

I developed the hardware, Andrew and Jesus worked on the software. I have more info on this I'll put it in the other thread.

 

John S.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...