Jump to content
IGNORED

From 0 to NUC/AL/RAM in 2 hours


Recommended Posts

hi Bob

I have installed the system by following your instructions. really helpful!

 

I have a few silly questions

 

1. do you keep your NUC on all the time?

2. After powering off the system, when restart it, do you have to keep the USB stick in the machine to boot?

3. For each ram boot, it asks me to "ram boot or not y/n" and needs to type Y. Is there any possibility to auto boot the system into ram once you push the power button? So I don't need to connect it to a screen when I play music?

 

Many thanks!

Link to comment

John,

 

When I did the work of documenting in one place the process of setting up the NUC endpoint I hoped that it would help others to replicate it.  The NUC is one step in a larger project to improve what we are listening to.  I will update the master post to include your questions.

 

Sit back and listen for a while!

 

Bob

Link to comment
  • 2 weeks later...

As a DIY-averse kinda guy, I'm getting close to dipping my toes into these NUC-infested waters 😀.

In the first instance, to replace my microRendu Roon endpoint.  If that's successful, I'll then replace my W10 server, also with a NUC, as I use very minimal Roon DSP.

This thread has been extremely useful, but still I have a couple of questions...

 

1. Why bother with the cost and effort of a fanless case, when the low power settings (along with careful fan settings) shouldn't cause the fan to come on anyway for such a seemingly low CPU load? I'm thinking of starting with a NUC7I7DNHE package, as that doesn't cost that much more than the bare board, but allows me to get going very quickly. I can transfer the board to an Asaka case later on only if it fan noise beomes an issue in practice.

 

2. How is the NUC endpoint recognised across the network by the Roon server? Does it have a static IP address?

The microRendu does not have a static IP address, which means I'm forced to use a router to dynamically allocate an IP address - which for various reasons is a PITA in my particular situation.

 

 

Link to comment

The fans in the Intel NUC cases never seem to shut off.    Things get warmer in there than you think.  

 

I like what the folks at SimplyNUC have done.  I have not purchased one yet.

 

IP address is controlled by the OS.  I have not looked at Audio Linux to see how to do that, I use DHCP.  Roon has a discovery protocol that  it runs on the network to find devices.

Link to comment
1 hour ago, TheAttorney said:

2. How is the NUC endpoint recognised across the network by the Roon server? Does it have a static IP address?

The microRendu does not have a static IP address, which means I'm forced to use a router to dynamically allocate an IP address - which for various reasons is a PITA in my particular situation.

 

Roon does not need the Server or the Bridge on the endpoint to have static IP addresses. As Bob said, all Roon components advertise their presence on the network, so get discovered automatically.

 

If you like, you can certainly set your server, endpoint or both boxes to static IP addresses. I've always done this manually, and I noticed AL does not have a menu option to do this, which shouldn't be a big deal to implement. I've asked Piero to consider doing so.

Link to comment

Thank you Bob and Rajiv.

 

But there's still something I'm missing here regarding IP addresses. You make it sound as if Roon server just automatically finds its endpoint. But I think it can only make that discovery if the end point has an IP address allocated to it - either statically or dynamically by a DHCP server.

 

In my case of W10 laptop server bridging ethernet to wifi, with a wifi-connected router,  that bridging process is fiddly and unreliable. It sounds as if the same will apply to a NUC end point. I can live with that, but a static IP address would mean that Roon server could find its endpoint without the wifi router being involved - which removes a level of complication at start up time.

 

Link to comment
4 hours ago, TheAttorney said:

Thank you Bob and Rajiv.

 

But there's still something I'm missing here regarding IP addresses. You make it sound as if Roon server just automatically finds its endpoint. But I think it can only make that discovery if the end point has an IP address allocated to it - either statically or dynamically by a DHCP server.

 

OK you lost me, because this is exactly how Roon works! The endpoint has to have an IP address on the same subnet as the Roon Core. For Roon to work, each of these machines has to have its own IP address:

  • Roon Core (aka Roonserver)
  • Roon Bridge (aka endpoint)
  • Roon control app (if running on an iDevice or other system)

Once both the Roon Core and the Roon Bridge applications are up and running, they become visible to each other and the control app.

 

4 hours ago, TheAttorney said:

In my case of W10 laptop server bridging ethernet to wifi, with a wifi-connected router,  that bridging process is fiddly and unreliable. It sounds as if the same will apply to a NUC end point. I can live with that, but a static IP address would mean that Roon server could find its endpoint without the wifi router being involved - which removes a level of complication at start up time.

 

 

Perhaps you can describe your network topology? Which machines are running Roon Core and Roon Bridge? How are they connected?

Link to comment

My system is a direct line of Roon Server on W10 laptop > Anker USB/Ethernet dongle > ethernet cable > Roon Ready mR > ISORegen > DAVE.

 

The router (with internet access) is in a different room and all connections to it are via wifi. There are no switches involved anywhere.

 

The laptop’s touchscreen & keyboard controls Roon (but I can additionally control it from my  smartphone via wifi if I want to). I use Windows to bridge ethernet to wifi within my laptop.

I find that setup very convenient for my circumstance, but occasionally the bridging fails on server start-up , which causes Roon server to not find its end point on the mR. So I have to go through a ritual to get things working again.

 

That ritual was tolerable, but has recently become almost farcical after moving house with a new broadband supplier with their dedicated router. I simply cannot get bridging to work with the new router – everything looks properly bridged, but the mR cannot be seen by Roon server (or even seen on the network by the new router).  So I use my old router to do the bridging, then I can switch off the old router and bridging continues for a couple of days until, presumably, the dynamic IP lease runs out (or I restart my laptop).

 

But then I wanted to try the free Qobuz trial with Roon intergration, so I needed internet access via the new router. I was somewhat surprised to find I could bridge using the old router, then connect to the new router – and amazingly the bridge still held whilst giving me access to Qobuz. I could even put the old router away for couple of days – until the lease ran out. But this clearly can’t continue like this.

 

There are probably a dozen ways to handle such networking/bridging issues, but the simplest solution to my mind would be if the end point had a static IP address. But I don’t want to unduly divert this thread by discussing network issues – the key NUC-related point here is that audiolinux currently has no option to set a static IP address, so therefore it will be no better than my current mR in handling my particular network/bridging situation.        

 

Link to comment
26 minutes ago, TheAttorney said:

My system is a direct line of Roon Server on W10 laptop > Anker USB/Ethernet dongle > ethernet cable > Roon Ready mR > ISORegen > DAVE.

 

The router (with internet access) is in a different room and all connections to it are via wifi. There are no switches involved anywhere.

 

The laptop’s touchscreen & keyboard controls Roon (but I can additionally control it from my  smartphone via wifi if I want to). I use Windows to bridge ethernet to wifi within my laptop.

I find that setup very convenient for my circumstance, but occasionally the bridging fails on server start-up , which causes Roon server to not find its end point on the mR. So I have to go through a ritual to get things working again.

 

That ritual was tolerable, but has recently become almost farcical after moving house with a new broadband supplier with their dedicated router. I simply cannot get bridging to work with the new router – everything looks properly bridged, but the mR cannot be seen by Roon server (or even seen on the network by the new router).  So I use my old router to do the bridging, then I can switch off the old router and bridging continues for a couple of days until, presumably, the dynamic IP lease runs out (or I restart my laptop).

 

But then I wanted to try the free Qobuz trial with Roon intergration, so I needed internet access via the new router. I was somewhat surprised to find I could bridge using the old router, then connect to the new router – and amazingly the bridge still held whilst giving me access to Qobuz. I could even put the old router away for couple of days – until the lease ran out. But this clearly can’t continue like this.

 

There are probably a dozen ways to handle such networking/bridging issues, but the simplest solution to my mind would be if the end point had a static IP address. But I don’t want to unduly divert this thread by discussing network issues – the key NUC-related point here is that audiolinux currently has no option to set a static IP address, so therefore it will be no better than my current mR in handling my particular network/bridging situation.        

 

 

Yes, sounds like you have some networking issues going on.

  1. Router issues:
    • One thing I always check, especially with the crappy routers ISPs provide, is whether UPNP and multicast are enabled. Usually you can go into the router's web UI and find these. Ensure they are enabled. Instead of multicast, you may see the option called IGMP. Anyway, when these are off, they can impede discovery, so turn them on.
    • My preference is to have the ISP to just give me a modem (or supply my own) and set it in "passthrough" mode. Then you can use a "good" router of your own choosing. Not sure if UK ISPs offer this option.
  2. Bridging issues: as has been reported from day 1 on the novel thread, bridging sometimes doesn't work on Windows 10. Not sure why, but probably due to driver issues. I remember several people (myself included) found relief by adding a 3rd network adapter to the bridge, even if it was not connected. You could try switching to a different dongle (check the chipset). I think on my machine, the Anker (with the Realtek chipset) worked well, but I had to add a 3rd adapter (wifi) to the bridge. In your case, you could just add another Ethernet dongle, add it to the bridge, but just leave it unconnected.
  3. Static IP: Finally, if you do feel static IP addresses are necessary, you can definitely do static IP on AL. See http://www.audio-linux.com/#GUIDE and search for "static address" within the page. I asked Piero about adding a simple menu option for non-geeks to do this, and he said it will come out in version 105.
Link to comment

I've got to disagree that enabling uPNP on the route is a good idea.  It opens the opportunity for any malicious software to be able to open outbound connections to command-control hosts.

 

Multicast/IGMP proxy yes, it will often help Roon communications but uPNP, no.

Link to comment
1 minute ago, lpost said:

I've got to disagree that enabling uPNP on the route is a good idea.  It opens the opportunity for any malicious software to be able to open outbound connections to command-control hosts.

 

Multicast/IGMP proxy yes, it will often help Roon communications but uPNP, no.

 

You may be right. I first ran into the UPNP issue years ago when I was running minimServer, so it may well be unnecessary on Roon. I just set it on for consistency, but didn’t consider there may be a security risk.

 

Thanks for the warning.

Link to comment
On 3/16/2019 at 1:53 PM, TheAttorney said:

Thank you Bob and Rajiv.

 

But there's still something I'm missing here regarding IP addresses. You make it sound as if Roon server just automatically finds its endpoint. But I think it can only make that discovery if the end point has an IP address allocated to it - either statically or dynamically by a DHCP server.

 

In my case of W10 laptop server bridging ethernet to wifi, with a wifi-connected router,  that bridging process is fiddly and unreliable. It sounds as if the same will apply to a NUC end point. I can live with that, but a static IP address would mean that Roon server could find its endpoint without the wifi router being involved - which removes a level of complication at start up time.

 

You may want to do some reading on network discovery and the use of local DNS

Regards,

Dave

 

Audio system

Link to comment
4 hours ago, austinpop said:

@TheAttorney

 

@hifi25nl just added a menu-driven way to set static IP to the latest Audiolinux menu version 105. So if you need it, it's there.

@hifi25nl never quits making little changes to improve the headless OS.  I think we are at the point now that you can boot the USB stick and create a Roon Server on an Optane or other SSD and never touch the command line!  Kudos again!

Link to comment

I think I have the opportunity to try this setup. I have cabled my home with Cat6a RJ45 cables, 3M shielded everywhere.

I think I'm going to try a roon server with the music in my room, and a nuc connected to the dac I want (the chord Qutest) on my living room where my setup is.

Just a question though, those NUC setup are great, but they are connected to the dac via USB, right? so is there space to drop a more capable USB card in there or is this a "weakspot" on the nuc setup?

Link to comment

confirmed the only NUC I can get easely (and not bare board) is the NUC7I7DNH2E which cost roughly 600 euro/630$ for me.

I guess to begin with this is going to be my endpoint of choice with 1 8gb ram stick and a 32gb USB. The akasa case cost a hell lot to get to my remonte island.

Link to comment
3 minutes ago, deanorthk said:

confirmed the only NUC I can get easely (and not bare board) is the NUC7I7DNH2E which cost roughly 600 euro/630$ for me.

I guess to begin with this is going to be my endpoint of choice with 1 8gb ram stick and a 32gb USB. The akasa case cost a hell lot to get to my remonte island.

If you did not order yet.  Look at the simplynuc fanless case system.  Called the porcoolpine.  It is all built up for you. 

Link to comment
On 3/18/2019 at 8:57 AM, austinpop said:

@TheAttorney

 

@hifi25nl just added a menu-driven way to set static IP to the latest Audiolinux menu version 105. So if you need it, it's there.

 

I should know this but where is the menu version visible?  When I run Update Menu, it reports I have the latest, but I don't see the new static IP option.  (I don't need it just curious why it reports up to date but doesn't show).   Thx.

Link to comment

Nope, still just says AudioLinux menu - Version (with nothing where I would expect a version number).  No big deal.  I'm happy with the system as it stands, plus my few other tweaks to disable other unneeded services.  No plans to update until something major comes along...

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