Jump to content
IGNORED

AudioLinux and NUC Troubleshooting and Tuning


rickca
Message added by austinpop

Summary of useful findings and recommendations

 

This section will be a living repository of useful info from this thread. It's very similar to a wiki and will be maintained by a small group of thread moderators.

 

Before you get started please refer to the Audio-Linux website to ensure you have the latest info and the proper versions of the OS. Audio-Linux.com  

 

**** Updated for AL 1.30 menu 118 or later.

 

  "First Run" setup for headless.  

 

Setup your NUC with a keyboard, mouse, and monitor to the NUC BIOS settings.  From the menu note the IP address of the machine to SSH into.  From a MAC the macOS terminal program supports SSH:

324537708_ScreenShot2019-01-28at3_02_19PM.thumb.png.739dc7f9cdb05e04da806c7c66877332.png

 

Then it is simpler to cut and paste into the terminal session. After entering the password for the audiolinuxuser you will be presented with the AL headless menu:

 

1518375894_ScreenShot2019-01-28at3_04_18PM.thumb.png.a7b2867a163f8f014e56e52ff69f94b4.png

 

Option 8 takes you to the command line for the following basic setup.  You will need to be the Root user for this setup and the su command first:

 

su

 

Fix the time zone:  (this is my timezone - look in directory /usr/share/zoneinfo)

 

timedatectl set-timezone America/Chicago
 

Setup and Start NTP daemon (to keep the system time in sync)

 

*** the config file is now properly filled in.

 

Now Start the daemon

 

timedatectl set-ntp true

 

 

NOTE: Sometimes the system takes a little while to get synced up.
 

Set hostname  (this provides a unique name for the machine on your network.  Replace <NAME> with your chosen name)

 

hostnamectl set-hostname <NAME> 
 

Once the above items are set up your machine is ready to be configured for say a Roon bridge/endpoint. That is done using the AL menu.  To return to the menu do the following commands.

 

exit

menu

 

----------------------------------

 

For most of us, the following basic settings are key.

From the configuration menu:

6. START and enable Roonbridge

15. SET Realtime Priority to extreme

16. ENABLE ramroot (reboot after)

 

Return to the main menu and reboot the NUC using 

 

11 Reboot

 

------------------

Roon Server setup is a bit more complex and we will cover it completely a bit later.  The key is where you are booting from and where the Roon database is stored.  In general; say a 32gb OPTANE "SSD".

 

  • You have to partition the SSD into a boot drive and a storage drive.  
  • The transfer the USB stick install to the boot partition.  
  • Reboot from the boot partition.  
  • Do the basic setup. Timezone and name
  • Transfer the Roon Database to the storage drive
  • Start the Roon Server
  • .....

 

----------------- 

The machine will reboot and from the display attached to the NUC you can watch it boot up and load into RAM.  Once the AudioLinux menu is showing the endpoint should be available in Roon.    This completes the basic startup sequence.  The system is ready to start testing.    

 

 

Recommended Posts

16 minutes ago, ray-dude said:

Quick question for those that have been playing with LMS as their music server.  I'm finding it plays much nicer with the squeezelite end point vs Roon Server, but I would like to do an apples to apples comparison.

 

Which processes are folks singling out to include in /opt/rtapp/rtapp.conf to give the server process realtime priority?  It seems to be running as a daemon, with a lot of subprocesses,, but I'm getting a bit lost tracking them down to see which should have a priority boost.

 

 

 

Hi Ray,

 

LMS runs as a perl script. You can verify this by looking at running processes (ps -ef). This is the LMS process:

 

logitec+ 17987     1  0 23:48 ?        00:00:01 /usr/bin/perl /opt/logitechmediaserver-git/slimserver.pl --prefsdir /opt/logitechmediaserver-git/prefs --cachedir /opt/logitechmediaserver-git/cache --logdir /opt/logitechmediaserver-git/Logs

 

For realtime optimization on my server, I made the following changes - this is on top of what the menu script does when you Set Realtime priority to Extreme:

  • In /etc/rtirq.conf:  
    • RTIRQ_NAME_LIST="eth en"
    • Rationale: on the server, we want the network interrupts to have highest priority.
    • If you're bridging, I'd give higher priority (list it first in RTIRQ_NAME_LIST) to the downstream interface - the one connected to the endpoint. 
  • In /etc/rtapp/rtapp.conf:
    • APPLICATIONS="RoonServer RoonAppliance RAATServer perl"

I've not A/B'ed with and without these changes, so who knows if this makes an audible difference!

Link to comment

Thank you Rajiv! I was assuming the Perl script was invoking some binary process that actually connected to the end point.  Back in the day, Perl was a write once, rewrite many scripting language for me, so I twitch a bit whenever I have to figure out someone else’s Perl code ;)  I may have some leftover eggnog tomorrow and see if there is a gem in there that actually manages the interface with the end point. 

 

 

ATT Fiber -> EdgeRouter X SFP -> Taiko Audio Extreme -> Vinnie Rossi L2i-SE w/ Level 2 DAC -> Voxativ 9.87 speakers w/ 4D drivers

Link to comment
7 minutes ago, ray-dude said:

Thank you Rajiv! I was assuming the Perl script was invoking some binary process that actually connected to the end point.  Back in the day, Perl was a write once, rewrite many scripting language for me, so I twitch a bit whenever I have to figure out someone else’s Perl code ;)  I may have some leftover eggnog tomorrow and see if there is a gem in there that actually manages the interface with the end point. 

 

 

 

 

Yes, please try to "squeeze" some light out of the darkness!

Link to comment
On 12/29/2018 at 1:08 AM, greenleo said:

Why heat cannot transfer easily?  One should apply the thermal paste and the thermal pad.  They should be effective.

Leo: The anodizing on the heat transfer block on the case would act as an insulating layer. Copper has better thermal conductivity than aluminum, and bare aluminum has better conductivity than anodized aluminum. As Dev has pointed out, they did not anodized that surface in another case.

Link to comment
2 minutes ago, sig8 said:

Leo: The anodizing on the heat transfer block on the case would act as an insulating layer. Copper has better thermal conductivity than aluminum, and bare aluminum has better conductivity than anodized aluminum. As Dev has pointed out, they did not anodized that surface in another case.

Has anyone had a problem with the heat transfer capabilities of this case?

Pareto Audio aka nuckleheadaudio

Link to comment

If this is the case, just use a dremel w. a wire attachment and eliminate the anodized layer no?

Ryzen 7 2700 PC Server, NUC7CJYH w. 4G Apacer RAM as Renderer/LPS 1.2 - IsoRegen/LPS-1/.2 - Singxer SU-1/LPS1.2 - Holo Spring Level 3 DAC - LTA MicroZOTL MZ2 - Modwright KWA 150 Signature Amp - Tidal Audio Piano's.  

.

Link to comment

This is talking about heat transfer by radiation, we have conduction here. Two very different things.

 

It is about good, better, best. If every degree temperature difference matters in SQ, then it matters. I just pointed out something I saw and did not think was the best thing to do. We fuss about everything, don't we.

Link to comment

I have been using the heat sink on x7d as is (with anodized layer on it) and as reported earlier the temps have been around 32-33C running as a streamer. This may not be the real test on how effective the heat transfer is until you push the CPU to do some work - so maybe running it as a server with some up-sampling logic over time would tell us something. Akasa has been designing fanless case for quiet sometime and I hope they might have done it with some reasoning...

Link to comment
48 minutes ago, Dev said:

I have been using the heat sink on x7d as is (with anodized layer on it) and as reported earlier the temps have been around 32-33C running as a streamer.

I've taken the fan out of the standard case, it was initially running at 42-44c as an endpoint, but after a nights work it settled down at 49c.

So the akasa case is very effective according to your measurements, even with fan in action temps were not much better and there is a definitive hit to sound quality with fan. I suppose the case also isolates from vibration aswell.

As an interesting side note switching the NUC7i7dnhe to server duties, in Roon with DSP enabled, the temps are actually lower, (back to 44c), than that as a a renderer. I know this is not intensive server duty, as the case is probably designed to take into account high power gaming use, turbo mode, etc.

Another surprise was my sclk-ex server as endpoint only, sounds so good I've left it at that for a while. This is direct from the motherboards USB output. Adding back the SOTM PCIE USB card, decreases the soundstage and flattens dynamics.

Anyone with an X10SBA motherboard or even an Innuos zenith might want to try it as an audiolinux endpoint, before moving on, you may be quite surprised.

Link to comment
3 hours ago, sig8 said:

This is talking about heat transfer by radiation, we have conduction here. Two very different things.

 

It is about good, better, best. If every degree temperature difference matters in SQ, then it matters. I just pointed out something I saw and did not think was the best thing to do. We fuss about everything, don't we.

My point is that I haven't heard anyone with a heat problem using the Akasa case. Because if this, I am not sure why we are talking about it. That's all.

 

The Plato X7D is a great case, well made, fits nicely in an audio rack, has an attractive design, and keeps things really cool.

 

I am testing hqplayer dsd512 upsampling with a NUC7i7dnbe in this case today to learn about any limitations. If there are any, I'll report it here.

Pareto Audio aka nuckleheadaudio

Link to comment
4 hours ago, sig8 said:

This is talking about heat transfer by radiation, we have conduction here. Two very different things.

 

It is about good, better, best. If every degree temperature difference matters in SQ, then it matters. I just pointed out something I saw and did not think was the best thing to do. We fuss about everything, don't we.

Sig,

 

I haven't read through the paper quoted by Larry.  However, the first paragraph that compares convection and radiation was spot on.

 

The heatsink use conduction to transfer the heat from the CPU to itself.  However, the heat sink dissipates its own heat through convection and radiation.  The air that surrounds the heatsink is heated up by convection.

Link to comment
2 hours ago, LTG2010 said:

I've taken the fan out of the standard case, it was initially running at 42-44c as an endpoint, but after a nights work it settled down at 49c.

So the akasa case is very effective according to your measurements, even with fan in action temps were not much better and there is a definitive hit to sound quality with fan. I suppose the case also isolates from vibration aswell.

As an interesting side note switching the NUC7i7dnhe to server duties, in Roon with DSP enabled, the temps are actually lower, (back to 44c), than that as a a renderer. I know this is not intensive server duty, as the case is probably designed to take into account high power gaming use, turbo mode, etc.

Another surprise was my sclk-ex server as endpoint only, sounds so good I've left it at that for a while. This is direct from the motherboards USB output. Adding back the SOTM PCIE USB card, decreases the soundstage and flattens dynamics.

Anyone with an X10SBA motherboard or even an Innuos zenith might want to try it as an audiolinux endpoint, before moving on, you may be quite surprised.

Hi ,

I am very interested by your conclusions. 

I am in a dual pc set up with x10sba mobo , the endpoint x10sba is sclk-ex clock driven and I have the SOTM pcie  usb followed by a tx usb ultra. 

 

You have written that the SOTM pcie usb flatten the sound , this is new to me. 

Could you confirm that on your endpoint you probably have totally deactivated the pcie and the sata  in the bios ?

Which player are you using with audiolinux ?

how is powered your mobo endpoint and how was powered you SOTM pcie usb card ?

PCserver Supermicro X11SAA under Daphile  ,Jcat pcie net card ,Etherregen,e-red dock endpoint,powered by LPS 1.2 , SPS 500 , Sean Jacobs level 3 psu,  DAC Audiomat Maestro 3, Nagra Classic Amp , Hattor passive preamplifier , Martin Logan montis

Link to comment
17 hours ago, ray-dude said:

Thank you Rajiv! I was assuming the Perl script was invoking some binary process that actually connected to the end point.  Back in the day, Perl was a write once, rewrite many scripting language for me, so I twitch a bit whenever I have to figure out someone else’s Perl code ;)  I may have some leftover eggnog tomorrow and see if there is a gem in there that actually manages the interface with the end point. 

 

 

 

 

I was able to spend some time this morning walking through the LMS source tree.  The transport is a lot simpler than I thought it would be (Roon-think had polluted my assumptions).  Looks to be a very simple HTTP streaming transport, backed by more sophisticated perl-based state machine for managing what is getting streamed (seeking in files, pause, play, etc).

 

The only items I could see that may need higher priority were some of the transcoding binaries (faad, flac, etc) in /opt/logitechmediaserver-git/Bin/i386-linux   However, for server-based sources (vs streaming sources from Tidal or Qobuz), things are getting streamed so quickly to the large buffer squeezelite end point (-b and -a flags), I'm not sure that fiddling with transcoding priorities would do much to move the needle (it just takes a second or two to move things to the end point)

 

In fact, as a neat parlor trick, if you kill LMS on the server (or Roon server), the end point happily keeps on playing, with no change in SQ that I could detect.  Makes me wonder again if any server side optimizations have an impact once you get past the initial 1-2 seconds it needs to fill the gratuitously large endpoint buffer.

 

EDIT: same trick works if you disconnect the end point from ethernet after the buffer has been loaded up...the end point just happily keeps playing (a brute force way to avoid the skipping you get with Roon server ;)

 

@austinpop when you were doing your servers and storage evaluations, were you using the large buffer(s) (-b and -a) squeezelite configuration on your end point?  If so, were you able to hear a difference in SQ?

 

 

 

ATT Fiber -> EdgeRouter X SFP -> Taiko Audio Extreme -> Vinnie Rossi L2i-SE w/ Level 2 DAC -> Voxativ 9.87 speakers w/ 4D drivers

Link to comment
3 hours ago, LTG2010 said:

Another surprise was my sclk-ex server as endpoint only, sounds so good I've left it at that for a while. This is direct from the motherboards USB output. Adding back the SOTM PCIE USB card, decreases the soundstage and flattens dynamics.

Anyone with an X10SBA motherboard or even an Innuos zenith might want to try it as an audiolinux endpoint, before moving on, you may be quite surprised.

 

By any chance did you compare NUC7i7dnhe to the X10SBA both as a streamer and running AL ?

Link to comment
1 hour ago, jean-michel6 said:

Hi ,

I am very interested by your conclusions. 

I am in a dual pc set up with x10sba mobo , the endpoint x10sba is sclk-ex clock driven and I have the SOTM pcie  usb followed by a tx usb ultra. 

 

You have written that the SOTM pcie usb flatten the sound , this is new to me. 

Could you confirm that on your endpoint you probably have totally deactivated the pcie and the sata  in the bios ?

Which player are you using with audiolinux ?

how is powered your mobo endpoint and how was powered you SOTM pcie usb card ?

Hi, no real conclusions yet just was a bit surprised at the results.

I had a single X10SBA setup, sclk-ex clocked motherboard/cpu, lan, SOTM pcie USB and tx-usb hubin ( similar to your txusb ultra)

slc sata OS server 2016 and 6tb 2.5inch sata hard disc.

All powered by a nine rail Sean jacobs supply.

Then I switched to audiolinux with Roon or hqplayer on the single machine. In this situation the best sound I got was via the pcie/ USB card and reclocking board, the direct motherboard USB was coarse less refined in comparison. (note in comparison, the sound was in no way coarse or unrefined, I could live with it)

With all the NUC fuss, I tried the NUC endpoint with audiolinux, and audiolinux on my sclk-ex server with a bridge on the LAN, (so now the PCIE -USB and reclocking board are redundant. In this situation the sound improved further the 2 box audiolinux solution works, the NUC provided a more open dynamic sound although with less warmth. (in comparison) but it was better.

Switching over the NUC as server and the sclk-ex machine as endpoint the sound through the motherboards USB output has the original warmth and combines the NUC's dynamics with greater frequency extension at both ends, the sound has greater bass kick and extension. I suspect that clocking the motherboard USB output would improves things further. The sound with the NUC as endpoint is a bit tighter and focused, both equally good in slightly different ways.

The ouput from the SOTM PCIE USB in this situation is less dynamic (again in comparison, its not undynamic) a bit more polite, the sound stage a bit smaller, less bass punch i'd say a bit more suited to classical small scale, less suited for rock etc.

I suspect the type/ multi rail power supply plays a big part, and maybe there is a bit too much filtration on the PCIE card if you already have a good power supply.

As a side note bridging works equally as well on the endpoint in the reverse role.

 

Link to comment
13 minutes ago, Dev said:

By any chance did you compare NUC7i7dnhe to the X10SBA both as a streamer and running AL

Yes as streamer and server both with audiolinux in reverse roles with equally good results. The good thing about the NUC is it require s a single rail supply the X10 gets better with more rails.

Link to comment
2 hours ago, ray-dude said:

 

@austinpop when you were doing your servers and storage evaluations, were you using the large buffer(s) (-b and -a) squeezelite configuration on your end point?  If so, were you able to hear a difference in SQ?

 

I just posted my impressions on server differences over on the new thread Larry created. But to be clear, I was using Roon Bridge in those comparisons. I could not rapidly switch between 2 different instances of Roon Server and have it work with a Squeezelite endpoint.

 

If what you suggest is true, then if I redid the experiment by running LMS on both my servers, and switching back and forth by attaching the squeezebox endpoint to one or the other, I should perceive no difference between the servers?

 

I will try this later tonight if possible.

Link to comment

 

I was able to do some more experiments playing with gratuitously large end-point buffers, with some interesting findings.

 

As a reminder, I’m running AL headless as a RAM boot server on a 16GB NUC7i7DNKE, and my end point on a headless AL RAM boot 8GB NUC7CJYH.  End point is connected by USB to a Chord stack.

 

For the NUC server, I’m running both Roon Server and LMS, testing a combination of local music files (in ram), SMB mounted files from my Mac Mini server (vanilla ethernet/switches/server) and TIDAL streaming

 

For the end point, I’ve been experimenting with large buffers in squeezelite (configuration below)

 

/usr/bin/squeezelite -o front:CARD=SCALER,DEV=0 -b 4097152:97152 -d all=info -a 50000000:4 -c pcm -x -p 93

 

With this config, music is loaded from the server to the end point in a couple seconds.

 

 

The hypothesis I’ve been chasing is that a large in memory buffer (-b parameter) between the end point and the server will insulate the end point from any upstream fun, and a large in memory buffer between the endpoint software and the DAC (-a parameter) will insulate SQ (as much as possible) from other things going on on the end point.

 

What I’ve been playing with today is trying to understand how the buffer is loaded up by the server in various configurations.  To keep things consistent and avoid misinterpreting things, I do the following:

 

* Kill and restart squeezelite on the end point (to clear the buffers, etc)

* Start up playback on the server, queuing up multiple tracks of the same type (TIDAL, local, file server, bitrate, etc)

* Wait ~10 seconds, then physically disconnect the end point from ethernet

* All content was 44/16 lossless, so  I am long way from filling any buffers

 

TL/DR, with the squeezelite endpoint, Roon Server and LMS both buffer up current and next track, whether local files or streaming TIDAL content.

 

 

 

 

Roon Server, TIDAL content

 

Roon seems to buffer up the current track and the next track.  With longer classical pieces, I’ve had the end point happily keep playing for 20+ minutes when disconnected from ethernet (I have not tested the limit of disconnected playback)

 

 

Roon Server, local content (on NUC)

 

Same as above

 

 

Roon Server, content from file server (Mac Mini)

 

Same as above

 

 

LMS, TIDAL content

 

I haven’t gotten this to work yet, so not tested

 

 

LMS, local content (on NUC)

 

LMS also seems to queue up the current track and next track into the end point buffer.

 

 

LMS, content from file server (Mac Mini)

 

Same as above

 

 

 

 

Quick Thoughts

 

I did not hear any SQ difference when disconnecting the end point from ethernet.  I was physically getting up to do so (vs having someone else do so while listening) so this isn’t conclusive, but I also did not hear any difference in SQ when I killed the server process (Roon Server and LMS) on the server NUC (caveat: I have vanilla power and network in my setup)

 

I found it very interesting and encouraging that Roon is doing a stream-ahead preload of the buffers with TIDAL (buffering will give the same advantage with TIDAL as it does with local files)  There may be a practical path to effectively decouple the end point from the upstream part of your chain (except for the couple seconds it takes to buffer up content from the server)

 

In a buffer heavy end point configuration, it may be most beneficial to make the NUC7i7DNKE the end point (improves end point SQ) and make the NUC7CJYH the server (since it does very little when not filling up the buffer)

 

There is more experimentation to do in more normal operations (when does buffer get refilled, what happens when skipping songs or seeking within a song, etc)

 

With access to both the squeezelite and LMS source code, there may be options to further optimize/batch/minimize network interactions between server and end point (the SQ lift by having network traffic front loaded is material....seems like idle ethernet == good for the end point)

 

 

 

 

ATT Fiber -> EdgeRouter X SFP -> Taiko Audio Extreme -> Vinnie Rossi L2i-SE w/ Level 2 DAC -> Voxativ 9.87 speakers w/ 4D drivers

Link to comment
12 minutes ago, austinpop said:

 

I just posted my impressions on server differences over on the new thread Larry created. But to be clear, I was using Roon Bridge in those comparisons. I could not rapidly switch between 2 different instances of Roon Server and have it work with a Squeezelite endpoint.

 

If what you suggest is true, then if I redid the experiment by running LMS on both my servers, and switching back and forth by attaching the squeezebox endpoint to one or the other, I should perceive no difference between the servers?

 

I will try this later tonight if possible.

 

Yes, that would test the hypothesis.

 

In watching the squeezelite logs, it looks like it tries to reconnect to the original server for 30 seconds before going back into discovery mode.  To switch quickly, you may need to kill the end point, stop Roon Server or LMS on server #1, bring up Server #2, and restart squeezelite and have it reconnect to your new server

 

It would be fantastic if large end point buffers give some decoupling from the server configurations (I'm reading your post now...lots to digest there)

ATT Fiber -> EdgeRouter X SFP -> Taiko Audio Extreme -> Vinnie Rossi L2i-SE w/ Level 2 DAC -> Voxativ 9.87 speakers w/ 4D drivers

Link to comment

Rajiv, my critical listening stamina is (way) at an end for the day, but I ended up with LMS on both my server NUC (all music files local and in RAM) and LMS on my MacBook Pro (WiFi, accessing files from my Mac Mini file server)  These are basically my best/worst case configs, without having to worry about Roon authorization switching.

 

To make swapping back and forth easier on the end point, I'm specifying the server IP in the command line for squeezelite:

 

/usr/bin/squeezelite -s 192.168.4.126 -o front:CARD=SCALER,DEV=0 -b 4097152:97152 -d all=debug -a 50000000:4 -c pcm -x -p 93

 

Lets me swap back and forth in the start up time for squeezelite (<10 seconds).

 

There is enough network chatter going back and forth between server and endpoint (status stuff) that I'm also experimenting with kill LMS on the NUC and LMS on the MacBook Pro to see if I can detect any delta in SQ.

 

My ears are cooked, so I'm going to revisit things tomorrow with a fresh set of ears.  Looking forward to hearing about what you're hearing!

 

 

ATT Fiber -> EdgeRouter X SFP -> Taiko Audio Extreme -> Vinnie Rossi L2i-SE w/ Level 2 DAC -> Voxativ 9.87 speakers w/ 4D drivers

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