ROCK Dual Ethernet - Primary Port Not Exposed [RESOLVED]

I thought that ROCK was about simplicity.

What you are suggesting is just taking away the simplicity and making it more confusing and complicated for those that want simple.

Audiophile paranoia might even lead some to think that they are missing out on a SQ improvement that might not be their in the first place.

IMHO This kind of idea belongs in the Tinkering section.

I had this idea in the tinkering section and nobody paid attention to it until it came here thru another poster. This probably isn’t for ROCK users who are into simplicity.:sunglasses:

1 Like

Aha! Thank you for article.

SQ aside, this will allow turn-key buyers to have Nucleus with its shiny Roon logo sit next to their $30,000 units with the added benefit of halving their cable length and instead of having it sit behind the closet with cheap routers and switches at the basement. :wink:

This is great! I didn’t know that typing “nothing” to the setup is possible. I would think this can only be possible if the music renderer (SOtM sMS-200 in this case) have static IP capability. Shout to @May_Park here. :slight_smile:

1 Like

I didn’t mean you can type “nothing”, I meant to leave the field blank

I really thought you put some scripts there because it does take “nothing”. :grin:

Anyway, I tried leaving them blank and it defaults to 0.0.0.0. Errors ensued. Maybe I’m missing something?

Edit:
I modified the network setting using your instruction at \server\rock\Data\MachineSettings\network. I was able to get in but it needs static ip on the music renderer. Dynamic ip will not work.

I also tried switching the ethernet ports to where the Intel ethernet port is directly connected to the music renderer. That didn’t work. Ideally, the Intel port connects to the music renderer directly to bypass the USB in the USB ethernet adapter.

Anyway, I got a message from Mr. Lee of SOtM that static IP is possible with the sMS-200. I’m waiting for further instruction how to set this in my unit.

Mark J quote: “do not need to use the not-so-good comms layers that sit underneath RAAT”

What does he mean by this @danny :cry:

I thought networked audio was Roon’s focus, even while they support legacy connections like USB and SPDIF at the moment. If networked audio is the future (and present for most of us) this isn’t the best compliment.

I guess we’ll never know what he means unless we ask him directly. And it’s just one person’s view/experience.

Still, I do wonder what issues in RAAT he’s referring to :cry:

They’re a Roon Partner too :cry:

Whatever issues he’s experienced, I hope as a Roon Partner he’s in close discussion with Roon to improve things :+1:

Be very wary when entering discussions like the CA-thread mentioned above – far-reaching statements are by be some that obviously don’t have a grasp at basic networking. That thread also handily touches on the audible differences of SATA-cabling and the use of Indian copper plates for grounding purposes. Not saying all of it is nonsense – but don’t believe everything that’s said there at face value.

As for Antipodes – they use a RoonReady implementation on top of Roon core. Not sure what to make of that – and since I’ve never seen or heard an Antipodes box I’ll withhold my opinion. AFAIK, underneath RAAT is a basic TCP stack – I would take that statement about ‘not-so-good comms layers’ with a pinch of salt (or a bucket, for that matter). Maybe @danny or @brian feels compelled to shed a bit more light on this.

If you feel the need to do so – by all means, tweak your heart out. But keep in mind most of this is networking and data transport – the usual fare of audiophile voodoo does not apply here.

3 Likes

I just tried this setting and it works fine. Thanks for the tip.

As always, let your own ears decide if there’s any sonic value in trying this approach. My personal philosophy in audio (and much else in life) is the K.I.S.S. approach - simplicity. So much of audio is a bandaid, adding devices to fix problems, created by bad design or technologies.

I suspect he is referring to the OS supplied comm functions.

A bit of an explanation as to why it doesn’t apply here would probably be helpful.

You are a good advocate for a sensible DIY approach that focuses on audio and not slight of hand. Continue to enlighten.

@anon49565150

Hey, that’s great. How did you setup your network settings in your music server? Did you match the ip to the 2nd ethernet port of ROCK? How about other settings like gateway?

I was able to set my music server to static ip but Roon still cannot see it using Danny’s proposed setup.

Hi,

I first set up the second ethernet port on the server on which Rock is located to the setting described (using the web page). I then changed the network settings on my RaspberryPi, which has the DietPi distribution, using also those same settings (fixed ip address…). Plugged an l’an cable from the second ethernet port of the server to the ethernet port of the Pi and it works. Only issue now is you can no longer access the player (RaspberryPi)…
Hope that helps,
Stephane

Edit: both the IP on the server and player are fixed, but they need to be different

1 Like

I’ll get fix out for optional gateway and dns out this week.

2 Likes

just pushed out release of ROCK with this fix… check Settings -> About in roon to update.

Bummer I’m at work. Can’t wait to try this tonight. Thanks for the quick fix!

@danny Will it allow the non-Intel port (USB Ethernet Adapter) to connect to the router?

That already worked fine, but it is highly discouraged, as you will be limited to the performance of your USB2 ethernet adapter (which is quite bad).

That USB2 adapter would perform fine for a single stream to your audio renderer, but you wouldn’t want this degraded performance to talk to your NAS, or for updates, or anything else…

1 Like

ROCK rocks. This is awesomeness. :+1: