sMS-200 and microRendu Direct connection - Why does this improve Sound Quality

[Confused]

I have been following Romaz's thread regarding direct Ethernet connect connection of the mR / sMS-200 with some interest.

 

A novel way to massively improve the SQ of the sMS-200 and microRendu

 

However, I have found myself asking; why does this work? To be clear, I am not questioning that it does indeed work. Based on the responses of those that have tried it so far there appears to be a pretty firm consensus that this 'tweak' is offering improvements, in particular in the areas of clarity, realism, and so on.

 

In fact I have two basic questions:

1. Why does this work? What mechanisms are at play here and offering a positive influence?

2. Is there an alternative route to the direct connection solution, that would still offer the positive benefits per 1 above?

 

From a personal perspective, one thing I particularly like about the mR is that it works simply plugged into an Ethernet cable running of a switch, many metres remote from my PC. This suits me just perfectly! Without going into too much detail, I have thought of trying the Romaz mod, but in my set up, where the PC used for audio in on a nice desk, in a nice spot, about 6 meters or so away from the mR /hifi, direct connection just does not work for me. (not without buying more kit anyway, I could of course buy a new mini PC or something to sit on my rack)

 

The point of this thread is that I simply do not understand why direct connection works. Clearly it does, but why? Then following on from this, I think if we could fully understand the mechanisms directly involved with offing the sound quality improvements that are being obtained, then maybe a different route to this end could be established?

[Freann]

My personal belief: you bypass the router.

 

/speculation

A wifi router – by definition – emits a huge amount of em radiation (wifi signals). Mine has three high power radio transmitters (1x2.5 GHz, 2x5 Ghz). Computers as well as routers are em shielded to minimize external and internal interference. Maybe some of this em radiation finds its way into a endpoints such as the microRendu?

 

Now how goes the radiation enter a device? Maybe the CAT cables acts as wave guides funneling em radiation? I don’t know. I do hear a difference compared to straight connection and optical isolation.

/end speculation

[tboooe]

I have to agree with freann on this. I just did an experiment last night where I removed my Cisco SG300 fiber switch form my music network and connected my wireless bridge/switch directly to my HQP PC via FMC and fiber. I did this direct connection mainly because of romaz's thread. I figure if it worked for the microrendu or SMS200 it may work for an upstream PC server. To my surprise I liked the sound more with the switch. I think the old audiophile addage of simpler is better applies here.

[AudioPhil]

Hello

 

We recommend direct connections in our PDF guide since around 4 years now, so thats nothing new. :-) A direct connection from A to B is much less affected by jitter than when you use a switch or hub in between.

 

if the switch has an upgraded Clock and/or linear/battery power supply things might get a lot better.

 

Best,

AudiiPhil

[JohnSwenson]

I'm not sure of the mechanism involved, I have not done a lot of testing on this, and won't be able to for many months (packing up the house for moving).

 

I do have have some possible experiments if people are interested in running some tests. For all these tests the source and endpoint need to be the same to at least have SOME validity. These are about changing a variable and assessing SQ change (if any), it is important to change only one thing at a time. Resist the temptation to change multiple things at once.

 

I am assuming the overall system is some form of music file source, some form of network connection and a "renderer" at the other end (SMS200 microRendu).

 

The diagrams below show the flow of music packets from a source (computer, NAS) to a renderer. There can of course be many other devices on your network (other computers, printer etc). The diagrams are just concerned with how packets get from source to renderer. When reporting results it would be nice to list what else is connected to the router or switch.

 

Changes:

change topology:

 

1): source -> switch on router -> renderer

2): source -> switch on router -> switch -> renderer

3): source -> switch -> renderer

4): source -> renderer

 

Some details of these. Each of the "->" in the above is a wired connection (RJ45 copper cable). Use the same cable type for each connection. Keep the total length of wire for each configuration the same. Thus if #4 is 100 ft, #1 could have 10 ft and 90 ft, or both 50 ft etc.

 

For #1, your network may have an additional switch, but the packets from source to renderer do not go through it, they just go through the switch built in to the router.

 

For #2 the source is connected to the router, a cable goes from router to a switch and cable goes from switch to the renderer. You can experiment with cable distances between switch and renderer.

 

For #3, the switch can have a cable back to the router for the internet connection and DHCP, but the source and renderer are connected to the switch, the music packets just go through the switch, NOT the router.

 

Power supply changes:

Try changing the power supplies for the router or switch. Make sure to do the test with the PS that came with the device first, THEN try with a "better" supply.

 

Connection type:

Try changing cable type for a connection. (CAT_5e, CAT-6, CAT-7, cheap, expensive) Do one connection at a time, if you wish you can also try more than one connection at a time. But do that after trying one at a time.

 

Try replacing one of the copper wired connections with a fiber optic connection. A sub test is to try changing the power supply for the fiber connection.

 

Cable length:

try significantly changing the cable length of a cable connection. By significant make it a big change ( say from 15 ft to 50 ft). Keep the other connections the same. Try this on each connection.

 

This should be enough tests to find some correlations, these are going to be the cornerstone of trying to get a handle on what is happening.

 

Note that for purposes of this thread, the purpose of the test is to find correlations of what affects what, NOT finding the best configuration in your system. So if you do the tests, please report on all the tests you did, not just what sounded the best. Configurations that made things sound worse are also important, not just what made things better.

 

The good thing is this does not take any test equipment, just a lot of listening time! I know this is going to take a LOT of time to do the whole suite. You do NOT have to do ALL of it to make a contribution, but please start at the top first, if you run out of steam you can leave out the tests lower on down in the post. You can report on one set of tests before doing others.

 

The more people that do this and report results the more useful the results are going to be.

 

I know it seems like a lot of work, but this is how you get from "I have no idea what is happening" to a theory about what is happening.

 

Thanks,

 

John S.

[romaz]

Hello

 

We recommend direct connections in our PDF guide since around 4 years now, so thats nothing new. :-) A direct connection from A to B is much less affected by jitter than when you use a switch or hub in between.

 

if the switch has an upgraded Clock and/or linear/battery power supply things might get a lot better.

 

Best,

AudiiPhil

But is it just a jitter issue? I own a Paul Pang switch with TCXO clock powered by an LPS-1 ultra-cap PSU and have placed it between my router and Mac Mini and yet this direct connection via bridged NICs still yields far superior SQ. I have heard single and dual box systems with JPlay/AO and while there is a definite improvement with a well-implemented dual box setup, the delta I heard was not quite this large.

 

In your manual, Phil, you suggest that in a dual PC setup, the control PC could get away with AO in GUI mode suggesting that optimization in the control PC isn't as critical as the playback PC but with this direct connection using bridged NICs, when I applied AO to my control PC (a Mac Mini running W2012R2 + AO), the improvement with minimal server over GUI mode was quite significant! It suggests to me that this direct connection is very revealing of the quality of the upstream source, much more than when a microRendu is connected by standard methods. Since I struggle to understand what exactly is going on with this direct connection via bridged NICs, it is hard to know if it does the same thing as JPLAY.

[romaz]

I'm not sure of the mechanism involved, I have not done a lot of testing on this, and won't be able to for many months (packing up the house for moving).

 

I do have have some possible experiments if people are interested in running some tests. For all these tests the source and endpoint need to be the same to at least have SOME validity. These are about changing a variable and assessing SQ change (if any), it is important to change only one thing at a time. Resist the temptation to change multiple things at once.

 

I am assuming the overall system is some form of music file source, some form of network connection and a "renderer" at the other end (SMS200 microRendu).

 

The diagrams below show the flow of music packets from a source (computer, NAS) to a renderer. There can of course be many other devices on your network (other computers, printer etc). The diagrams are just concerned with how packets get from source to renderer. When reporting results it would be nice to list what else is connected to the router or switch.

 

Changes:

change topology:

 

1): source -> switch on router -> renderer

2): source -> switch on router -> switch -> renderer

3): source -> switch -> renderer

4): source -> renderer

 

Some details of these. Each of the "->" in the above is a wired connection (RJ45 copper cable). Use the same cable type for each connection. Keep the total length of wire for each configuration the same. Thus if #4 is 100 ft, #1 could have 10 ft and 90 ft, or both 50 ft etc.

 

For #1, your network may have an additional switch, but the packets from source to renderer do not go through it, they just go through the switch built in to the router.

 

For #2 the source is connected to the router, a cable goes from router to a switch and cable goes from switch to the renderer. You can experiment with cable distances between switch and renderer.

 

For #3, the switch can have a cable back to the router for the internet connection and DHCP, but the source and renderer are connected to the switch, the music packets just go through the switch, NOT the router.

 

Power supply changes:

Try changing the power supplies for the router or switch. Make sure to do the test with the PS that came with the device first, THEN try with a "better" supply.

 

Connection type:

Try changing cable type for a connection. (CAT_5e, CAT-6, CAT-7, cheap, expensive) Do one connection at a time, if you wish you can also try more than one connection at a time. But do that after trying one at a time.

 

Try replacing one of the copper wired connections with a fiber optic connection. A sub test is to try changing the power supply for the fiber connection.

 

Cable length:

try significantly changing the cable length of a cable connection. By significant make it a big change ( say from 15 ft to 50 ft). Keep the other connections the same. Try this on each connection.

 

This should be enough tests to find some correlations, these are going to be the cornerstone of trying to get a handle on what is happening.

 

Note that for purposes of this thread, the purpose of the test is to find correlations of what affects what, NOT finding the best configuration in your system. So if you do the tests, please report on all the tests you did, not just what sounded the best. Configurations that made things sound worse are also important, not just what made things better.

 

The good thing is this does not take any test equipment, just a lot of listening time! I know this is going to take a LOT of time to do the whole suite. You do NOT have to do ALL of it to make a contribution, but please start at the top first, if you run out of steam you can leave out the tests lower on down in the post. You can report on one set of tests before doing others.

 

The more people that do this and report results the more useful the results are going to be.

 

I know it seems like a lot of work, but this is how you get from "I have no idea what is happening" to a theory about what is happening.

 

Thanks,

 

John S.

Hi John,

 

Thanks for weighing in on this. Yours is always a valued opinion.

 

While I don't have a source and endpoint that are identical, I have done much of what you have suggested already.

 

My chain is fairly simple. Here is my original chain:

 

Combination internet modem/router/switch powered by a Paul Hynes SR7 LPSU > BJC CAT6A (1m length) > TP Link 100Mbit FMCs separated by a 1m length of optical cable with the receiving FMC powered by an LPS-1 > BJC CAT 6A (1m length) > Paul Pang 5V 100Mbit switch with TCXO clock (uses no regulators) powered by LPS-1 > BJC CAT 6A (1m length) > Mac Mini with MMK and powered by 12V lead from Paul Hynes SR7 LPSU.

 

As I own both a microRendu and sMS-200, I have either endpoint directly connected to my Paul Pang switch with TCXO clock. Both endpoints are powered by a 9V lead from my Paul Hynes SR7, which I have found to be a bit better than your truly spectacular LPS-1. Initially, this connection was via a BJC CAT6A cable (1m) but I replaced it some time ago with an SOtM dCBL-CAT6A (STP) cable as I found it had resulted in a slightly smoother yet still equally detailed presentation which I attributed to a "filtering" effect.

 

Without changing another variable in my chain, I detached this SOtM CAT6 cable that I used to connect my microRendu (or sMS-200) to my Paul Pang TXCO switch and instead directly connected it to a second LAN port in my Mac Mini. This is the only change that was made but in order for my router to be able to assign the mR an IP address, I was forced to bridge the two LAN ports together.

 

What I got with this direct connection was this uncanny clarity that I had never before witnessed with either of these endpoints as if one very large veil had been lifted.

 

To try and simply things, I removed the TP-Link FMCs and Paul Pang TCXO switch believing that perhaps they were possibly hindering SQ in my system and so I directly connected my Mac Mini to my internet modem/router/switch. SQ worsened slightly. I re-introduced the FMCs with minimal improvement in SQ. I followed this by re-introducing the Paul Pang TCXO switch and this improved SQ further even though its impact was one again only minimal. Despite their small contributions, it was at least clear to me that neither were harming SQ.

 

Here is what is interesting. With my Mac Mini directly connected to my internet modem/router/switch, I then decided to introduce the pair of FMCs into the "direct connection" path. With the receiving FMC still powered by my LPS-1, as before, there was a very minor improvement that I felt I could hear while unblinded but could not differentiate while blinded. This suggested to me that there wasn't much of an RF noise issue in this direct connection between source and endpoint. When I introduced the Paul Pang TCXO switch into this "direct connection" path (with the switch powered by my LPS-1), there was considerable improvement as far as a more open soundstage and this improvement was now much more pronounced than when I had this switch (which I call my ethernet Regen) positioned before the Mac Mini. In many of your posts, you have suggested that presenting a DAC with as high SI integrity as possible can only lead to good things with the DAC. The impact of this ethernet Regen on the mR/sMS-200 would suggest the same thing with regards to these endpoints.

 

Many have suggested that because of the galvanic isolation that is inherent in the transformer-coupled ethernet protocol and because this is an error-correcting packet protocol that results in guaranteed bit-perfect delivery, the microRendu (and sMS-200) are largely immune to what is upstream and to a large degree, I had found this to be true but now with this "direct connection" via bridged NICs, the microRendu (and sMS-200) now seem to be much more sensitive to what is upstream but in a good way. What I mean by this is that the inherent galvanic isolation and error-free delivery is still there to the extent that no source sounds horrible but when care and attention is placed to the source (ie better PSU, optimized OS, etc), the improvements are very much appreciated.

 

It would seem to me that somehow, directly bypassing some evil "comms" introduced by an intermediary router between source and endpoint is responsible for this improvement even though the router is still responsible for assigning these endpoints an IP address. Most are suggesting that improvement can be heard to a varying degree with other endpoints but it seems the most notable improvements are with the microRendu and sMS-200.

[greenleo]

Hi John,

 

Why can't the microRendu and the PC be connected directly?

 

sMS-200 with old firmware provides the static IP feature. Anybody knows, if it means that no router is needed between a PC and an sMS-200? If so the router may be eliminated.

 

I guess it would be interesting to check if the SQ can be further improved.

[Pepsican]

Hi John,

 

Why can't the microRendu and the PC be connected directly?

 

sMS-200 with old firmware provides the static IP feature. Anybody knows, if it means that no router is needed between a PC and an sMS-200? If so the router may be eliminated.

 

I guess it would be interesting to check if the SQ can be further improved.

 

What you need is DHCP; one thingy that hands out the IP addresses. Whether that is on the modem, switch, router, the NAS or the PC does not matter. So, when you set up the PC to hand out IP addresses, you're in principle in business.

[Peter_T]

What you need is DHCP; one thingy that hands out the IP addresses. Whether that is on the modem, switch, router, the NAS or the PC does not matter. So, when you set up the PC to hand out IP addresses, you're in principle in business.

You can make the Ethernet-NIC that is attached to your renderer act as separate DHCP server : see my earlier post in this thread.

[greenleo]

Hi Peter,

 

It seems that http://www.dhcpserver.de cannot be reached. What's the software that you mentioned in your post in that thread?

[Peter_T]

Hi Peter,

It seems that www.dhcpserver.de cannot be reached. What's the software that you mentioned in your post in that thread?

 

Must be a local problem : I just tried and had no problem in reaching dhcpserver's website.

[hifi_swlon]

What you need is DHCP; one thingy that hands out the IP addresses. Whether that is on the modem, switch, router, the NAS or the PC does not matter. So, when you set up the PC to hand out IP addresses, you're in principle in business.

 

Or a fixed IP config option to be added to the microRendu web gui.

 

A 5 min job.....

 

Also an option to disable the network mount for the SD card while they're at it. I thought the idea was to keep the processes to a bear minimum, not add unnecessary ones....

[rickca]

Or a fixed IP config option to be added to the microRendu web gui.

IIRC Jesus has not wanted users to know how to assign a static IP address to the micro Rendu. I recall someone did this back when the product was first introduced, either to review the product or to demonstrate it at a show. If it's a Sonore support issue with people mucking about with Sonicorbiter, I think a configuration option is a great idea. It leaves things under Sonore control.

[scan80269]

I just tested a direct Ethernet connection between microRendu and my HQPlayer/music library Win10 PC, and it worked beautifully. A DHCP server app was installed into this PC. I used Tiny PXE Server as I'm familiar with it from my diskless PC endeavors, but any Windows-based DHCP server app should also work. The PC was given a static IP address, and Tiny PXE Server doles out an IP address to microRendu NAA whenever it comes online. Instead of using a motherboard gigabit Ethernet port, I used a USB2-to-Fast Ethernet adapter to set Ethernet speed to 100Mbps for the microRendu.

 

One caveat: I severed the internet connection for this PC, since I didn't want to mess with networking bridging, but just focus on the feasibility of a direct connection. I suspect Windows 10 will get confused as soon as I reconnect to the internet with another Ethernet port, and that will be a separate exercise.

[hifi_swlon]

IIRC Jesus has not wanted users to know how to assign a static IP address to the micro Rendu. I recall someone did this back when the product was first introduced, either to review the product or to demonstrate it at a show. If it's a Sonore support issue with people mucking about with Sonicorbiter, I think a configuration option is a great idea. It leaves things under Sonore control.

 

Ability to set a fixed IP/netmask/gateway at the device level is a standard setting on every other networked device I have. I just don't understand the reluctance to provide the option, if anything all it would do is make the unit more reliable, and remove the DHCP service if not required.

 

Same for mounting the device as a drive on the network. Why not allow us to disable it? Why would anyone not using the feature want it showing up across their whole network? It must also surely use resources.

 

There are are some other gui tweaks that would make the device better, like allowing specific network modes to be updated (it often says it's up to date but then when you update anyway, you get a new version of RoonReady you didn't know existed), and a button renaming if for example pressing my save can also restart the mode. Anyway, off topic.

[R1200CL]

I just don't understand the reluctance to provide the option, .......

 

I think this may cause the company support center to overload with idiots (like me), that have started to fiddle with things by themselves.

 

In addition the company knows what's best for you [emoji3]

 

You may hope for the company R&D department will have enough resources to offer more features in the future.

 

You may have to open a channel here in CA in order to get in touch with the company. Probably not in the sponsored area.

Last time a communication channel was established, it was deleted, since there was some idiots asking questions the company didn't like.