Jump to content
IGNORED

AudioLinux and NUC Troubleshooting and Tuning


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

36 minutes ago, BigAlMc said:

 

Two topics and not sure if they are related.

 

Working on my new i7DNBE based Roon endpoint in the Plato X7 fanless case. Running 4GB RAM, no wifi or bluetooth as the board doesnt support them. Using AL headless in Extreme mode with Ram root enabled.

 

A. Everytime I restarted the NUC endpoint I need to reselect and enable it in Roon. Any ideas why it's not automatically recognising it?

 

B. I can't seem to get the power down low enough for either the LPS1.2 or my SPS-500 to work with it. The LPS1.2 flashes red as soon as I connect it. The SPS-500 (on 19V and I thought it handled like 3amps) doesn't provide enough juice for the NUC on button to do anything.

 

I've put the power settings down to 10w and burst of 12w. I've disabled all the USB slots apart from the two being used for the USB flash and connecting to the DAC. I've even switched off 3 or the cores so that only 1 core is running and switched off hyperthreading and performance boost.

 

The LPS1.2 I can understand but I thought the SPS-500 was a decent plan B as it has more power but my i7DNBE thinks otherwise. 

 

Unsure what else to try disabling in order to get it working on a cleaner PSU.

 

Any thoughts?

 

Also, as per the picture below. Should I be disabling all these HDMI endpoints that are showing up on the NUC?

 

Cheers,

Alan

 

image.thumb.png.a6191251f8ff2b4abcc7cf818ff1ead5.png

 

 

 

 

 

 

 

Regarding your point A; configure it once in Roon in non RAM boot mode and then switch to RAM boot. This way the settings will be saved on the end-point. Perhaps the save to RAM option in alconf will work as well but I have nog tried this myself yet.

 

Re. your point B; I don’t have the i7 NUC but did you disable ‘sound’ in the NUC BIOS and any other devices you don’t use? This should then prevent the HDMI devices from showing up as audio outputs I’d say.

 

I’m not surprised the LPS1.2 can’t power the i7 NUC. Others have reported it was hit or miss with the celeron and/or Pentium ones as well. The sPS-500 though is rated to deliver a max of 3.3A at 19V you’d say that this should be enough but being a SMPS supply these are not really suited to deliver short peaks over that amperage. LPS’es are better in that regard so perhaps it peaks over that 3.3A. You could try it at 12V once.

Link to post
Share on other sites
48 minutes ago, MrUnderhill said:

Hi Dave,

 

Shame you live in Virginia and not London! Interesting findings. I have a couple of RPi3s lying around, I may well try one in place of my NUC7PJYH; although I must say it is doing sterling work for me.

 

ATB,

 

M

I'm using the 32 bit version with the overclock settings enabled in the configuration file...still hoping that someone comes forward with a way to overclock with 64 bit version.

 

May consider something like a fanless PC that can use a JCAT Femto/LPS1.2 for next endpoint, don't think AL magically fixes USB HW quality limitations. I do believe ISO Regen is a compromise, should be unneeded if USB is done right in machine and adds another whisper chain component for distortion.

Regards,

Dave

 

Audio system

Link to post
Share on other sites

FWIW: For those with a M.2 NVMe M key slot (eg NUC7i7DNHE, NUC8BEH/BEK), this riser card allows the use of either an audiophile USB or network card.  Looking into the future, the latest rumours are that the 2019 NUCS (second half of year) will have two M.2 (M key) slots instead of one.

 

https://www.aliexpress.com/item/M-2-NGFF-NVMe-M-Key2280-To-PCIe-3-0-4x-Riser-Card-Cable-PCI-Express/32833359557.html

 

 

Link to post
Share on other sites
1 hour ago, davide256 said:

have both SPS500 and LPS 1.2. The SPS500 is a beast for quality current but it can't compete with LPS 1.2 device resolution when powering sensitive source electronics.

I have the sPS500 and lps1 both sound bright (I can't speak for the LPS 1.2) when compared to my Sean Jacobs 12v rail where I hear a much more natural, warm, spacious presentation.(in my particular set up) Your speakers remind me a bit of my audeze headphones, very sensitive to Hf distortion. Using a ISO Regen may fix that another option to explore is a different power supply.

Link to post
Share on other sites
50 minutes ago, LTG2010 said:

I have the sPS500 and lps1 both sound bright (I can't speak for the LPS 1.2) when compared to my Sean Jacobs 12v rail where I hear a much more natural, warm, spacious presentation.(in my particular set up) Your speakers remind me a bit of my audeze headphones, very sensitive to Hf distortion. Using a ISO Regen may fix that another option to explore is a different power supply.

Good power supplies behave much like the glass used for a telescope lens... the better the glass, the higher the performance that can be gotten out of the end product. Brightness  is an excitation behavior of the electronics used... its unique to the gears strength ,weaknesses and  interaction with power supply design. The  measure I use for PS quality is resolution, tone color intensity, black space for background, I treat anything else as equipment unique interaction.

 

Did not observe much difference between HDPlex 19v vs LPS1.2 12V powering NUC7PJYH connected to DDC, but when using an ISO Regen between NUC and DDC with 5v USB replace enabled, the difference between PS used for ISO Regen is  glaring.

Regards,

Dave

 

Audio system

Link to post
Share on other sites
1 minute ago, davide256 said:

Did not observe much difference between HDPlex 19v vs LPS1.2 12V powering NUC7PJYH connected to DDC, but when using an ISO Regen between NUC and DDC with 5v USB replace enabled, the difference between PS used for ISO Regen is  glaring.

Which HDPLEX power supply do you have?  Is it the new 200W that just started shipping or an older model?

NUC7PJYH/AL --> 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 Version 2004/HDPLEX 300W/HDPLEX 400W DC-ATX --> EVGA Nu Audio Card --> Focal CMS50's 

Link to post
Share on other sites
1 hour ago, John769 said:

FWIW: For those with a M.2 NVMe M key slot (eg NUC7i7DNHE, NUC8BEH/BEK), this riser card allows the use of either an audiophile USB or network card.  Looking into the future, the latest rumours are that the 2019 NUCS (second half of year) will have two M.2 (M key) slots instead of one.

 

https://www.aliexpress.com/item/M-2-NGFF-NVMe-M-Key2280-To-PCIe-3-0-4x-Riser-Card-Cable-PCI-Express/32833359557.html

 

Whether or not a USB card makes much difference with the NUC's USB implementation remains to be seen however..

 

You can get an m.2 slot in a NUC7I3BNH. But I'm guessing that the need is for a board without case to allow  access to an add on USB card. Any thoughts for what that package would be (case,USB card, riser above, board)? I find the JCAT attractive because I could power the USB port with existing LPS 1.2 and because there

is an attempt at quality engineering.

Regards,

Dave

 

Audio system

Link to post
Share on other sites
1 hour ago, davide256 said:

Good power supplies behave much like the glass used for a telescope lens... the better the glass, the higher the performance that can be gotten out of the end product.

They also have a sonic signature, ultracapacitors don't sound the same as a toroid or  an smps, you will find in any review that an lps 1.2 has a brighter signature than the JS2 from the same manufacturer. They will also lose some of that clarity if they are struggling to provide the current required. The older HDPlex is not as transparent. A mundorf capacitor in a DC3 will impart a different sonic signature to a Nichicon or Elna in the sPS. With your speakers/ system  ( particularly your comments regarding the brightness of the NUC ) a Paul Hynes SR4, Sean Jacobs DC3 or uptone JS2 'may' be a better sonic match. To clarify I'm not stating that any of the power supplies mentioned are 'bright' it's about system synergy, the NUCPJYH is not at all bright here.

Link to post
Share on other sites
14 minutes ago, LTG2010 said:

clarify I'm not stating that any of the power supplies mentioned are 'bright' it's about system synergy, the NUCPJYH is not at all bright here.

Same here, no brightness at all. I am using LPS 1.2. I tend to agree, it could be system synergy. 

Link to post
Share on other sites
3 hours ago, Dutch said:

 

Regarding your point A; configure it once in Roon in non RAM boot mode and then switch to RAM boot. This way the settings will be saved on the end-point. Perhaps the save to RAM option in alconf will work as well but I have nog tried this myself yet.

 

Re. your point B; I don’t have the i7 NUC but did you disable ‘sound’ in the NUC BIOS and any other devices you don’t use? This should then prevent the HDMI devices from showing up as audio outputs I’d say.

 

I’m not surprised the LPS1.2 can’t power the i7 NUC. Others have reported it was hit or miss with the celeron and/or Pentium ones as well. The sPS-500 though is rated to deliver a max of 3.3A at 19V you’d say that this should be enough but being a SMPS supply these are not really suited to deliver short peaks over that amperage. LPS’es are better in that regard so perhaps it peaks over that 3.3A. You could try it at 12V once.

 

Thanks @Dutch,

 

Greatly appreciated!

 

Cheers,

Alan

Synergistic Research Powercell UEF SE > Sonore OpticalModule (LPS-1.2 & DXP-1A5DSC) > EtherRegen (SR4T & DXP-1A5DSC) > PinkFaun modded Buffalo BS-GS2016P (Farad Super3 & LPS-1.2) > (Sablon 2020 LAN) Innuos Zenith SE server > (Sablon 2020 USB) Innuos Phoenix > (Sablon 2020 USB) PS Audio Directstream DAC > PS Audio M1200 monoblocks > Salk Sound Supercharged Songtowers 

Link to post
Share on other sites
48 minutes ago, lmitche said:

Hi Alan.

 

Are you using a single 4gb stick of memory? Also, lower the peak watts as much as possible. Turn off everything you can. Start in normal not extreme mode.

 

Connect only the DAC and USB stick at power up. You may have to power up twice. Sometimes the NUC will not work with the lps1.2 at first try, but then works fine in the second and subsequent attempts.

 

Likewise, thanks Larry!

 

Regards,

Alan

Synergistic Research Powercell UEF SE > Sonore OpticalModule (LPS-1.2 & DXP-1A5DSC) > EtherRegen (SR4T & DXP-1A5DSC) > PinkFaun modded Buffalo BS-GS2016P (Farad Super3 & LPS-1.2) > (Sablon 2020 LAN) Innuos Zenith SE server > (Sablon 2020 USB) Innuos Phoenix > (Sablon 2020 USB) PS Audio Directstream DAC > PS Audio M1200 monoblocks > Salk Sound Supercharged Songtowers 

Link to post
Share on other sites

Deleted

NUC7PJYH/AL --> 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 Version 2004/HDPLEX 300W/HDPLEX 400W DC-ATX --> EVGA Nu Audio Card --> Focal CMS50's 

Link to post
Share on other sites
17 minutes ago, ray-dude said:

 

Looking forward to your report Rajiv!  

 

I was able to spend some time with the squeezelite ALSA parameters before fatigue set in.  From the help page:

 

 

It is frustratingly difficult to find out what these various parameters mean.  From @bibo01 we've learned that the developer of squeezelite r2 uses "-a 499:3::0".  The default is "-a 40:4".  Others have posted experiences with "-a 499:3"

 

From my hair pulling (aka reading) sessions, I suspect the second parameter is very DAC dependent, but that is a pure guess.  In my experimentation with my BluDAVE stack, I found 4 to be the best, but it was very limited experimentation.

 

I spent most of my morning trying different ALSA circular buffer time values.  Note that when the buffer time value is 500 or greater, it is interpreted as bytes, and when it is below 500, it is interpreted as milliseconds.  This controls the size of the circular ALSA buffer that sits between squeezelite and your DAC (ALSA is the OS-level sound drivers in linux).  The period value reflects how the various channels are interleaved in the buffer, and the format value reflects how many bytes to reserve for each value.  I got lost in the ALSA docs and source code any deeper than that, so please forgive me if I have any of this wrong.

 

My strategy was to peg the period at 4, and leave the format and mmap values as default (in my case "any" and 1)

 

For those that want to play at home. at the command line, I was running squeezelite manually to make it easier to toggle various parameters:

 

/usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=debug -a <various>:4 -c pcm -x

 

Execute the command, give a listen, control-c to kill it, modify the parameters, rinse and repeat

 

Breaking this down, -o points squeezelite at my DAC, the -b reflects stream and output buffer memory that gets reserved on start up (see my previous post above), -d sets out the log output level so I can follow the test in the terminal window (which is very informative!), -c restricts squeezebox to only use the PCM codec, and -x says "don't as the server to downsample anything".  

 

-x and -c should be no ops, since Roon Core is streaming PCM to the NUC, but I thought it wouldn't do any harm to disable features in squeezelite and keep things simple.

 

For these experiments. -a parameter is the one of interest to me, as it manages the output circular buffer between squeezelite and the OS and the DAC.

 

Using primarily Redbook content (my Blu2 does all my upsampling) that I am very familiar with, I tried <various> ALSA circular buffer sizes from 1000 bytes up to 1,000,000,000.  Since I'm just trying to figure out what all these parameters do (and if they matter), I used a limited number of audition tracks.  Fine tuning will come later.

 

The bottom line is I heard a notable uptick in SQ as I increased the circular buffer size, but things got progressively more flakey with Roon Core and latency went way up as the buffer size got to the top end.

 

I found my sweet spot to be between ~50-100MB (very sweet spot actually...delightful!):

 

/usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=debug -a 100000000:4 -c pcm -x

 

To triangulate and spot check, a ~4:00 Redbook (44/16) ALAC file is ~27MB, ballooning to ~43MB when decoded to PCM.  My hypothesis is that if you can fit the entire PCM content in the ALSA circular buffer, you're as buffered as you're going to get.  Set the USB for your DAC to the highest IRQ RT priority and have squeezelite a close second in real time priority, and I'm not sure you can do any better (outside of continued OS tuning to get more and more real time)

 

So how do high res files (24 bit and higher sampling rate, etc.) and DSD files impact this?  Is this setting over optimized for Redbook content?  My ears and brain are too tired to check today ;) 

 

My next step is to experiment with high res content (does 24 vs 16 bit changes the sweet spot?), DSD content (does it work ok?), and longer content (do I need a bigger circular buffer?).

 

The big next step is to see if an extra large ALSA circular buffer enables reallocating precious memory from the squeezelite buffer (the -b parameter above....currently heavily weighted on the streaming (ethernet) side) to the ALSA buffer between squeezelite and the DAC.  

 

In other words, if you're willing to live with the latency, does having a maximum ALSA circular buffer (large enough to fully buffer all your PCM content) make the upstream buffering (or running Roon core on the same NUC) less relevant to SQ?  I'm hoping the answer is yes!

 

 

 

 

 

Awesome. Fascinating findings! Now I will have to find time - a commodity in short supply - to play with the asymmetric -b, and then the -a setting.

 

Not sure when that'll be, but thanks so much for your efforts!

Link to post
Share on other sites

Fascinating to look at the network traffic while things are running!  Really shines a light on what Roon core is doing (the most opaque part of our chains right now).  When I recover a bit, I'll repeat my ALSA circular buffer experiments while watching network traffic.  

 

I am very hopeful that maximizing the buffer at the OS level (ALSA) and as far away as possible from Roon Core will give us the biggest lift, and the most direct immunity from any transient behaviors from the player, etc. (my spider sense is that the -b buffers are giving us an important but indirect benefit, but the proof will be in the pudding!)

ATT Fiber -> EdgeRouter X SFP -> Sonore opticalModule -> Taiko Audio Extreme -> Chord DAVE -> Voxativ 9.87 speakers w/ 4D drivers

Link to post
Share on other sites

I still recall what this Texan was all about

 

https://books.google.com/books/about/Direct_From_Dell.html?id=XCMjisWZFYcC

Quote

You'll meet the young Dell who, at the tender age of eight, had already begun looking "to eliminate unnecessary steps" and who, as a numbers-loving adolescent, was inspired by a newfound fascination with computers to save his money to buy a coveted Apple II--only to promptly take it apart.

 

Let's remember that we're indeed utilizing "plain vanilla" Ethernet at this point, therefore we don't really have the "luxury" to eliminate the unnecessary steps

 

https://searchstorage.techtarget.com/definition/Remote-Direct-Memory-Access

Quote

Remote Direct Memory Access (RDMA) is a technology that allows computers in a network to exchange data in main memory without involving the processor, cache or operating system of either computer. Like locally based Direct Memory Access (DMA), RDMA improves throughput and performance because it frees up resources. RDMA also facilitates a faster data transfer rate and low-latency networking. It can be implemented for networking and storage applications.

 

https://wiki.archlinux.org/index.php/InfiniBand

Quote

IB's latency is incredibly small: SDR (5us); DDR (2.5us); QDR (1.3us); FDR (0.7us); EDR (0.5us); and HDR (< 0.5us). For comparison 10Gb Ethernet is more like 7.22us, ten times more than FDR's latency.

 

BTW, maybe it's about finding the sweet spot?

 

https://help.ableton.com/hc/en-us/articles/209072289-How-to-reduce-latency

Quote

The smaller the buffer size, the lower the latency. Bear in mind that very small buffer sizes may cause dropouts or glitches due to the increased CPU load. Find the sweet spot where the buffer is as small as possible without impairing the audio quality.

 

Question for @hifi25nl, do you have any experiences with enabling RDMA on both server side and client side?

Link to post
Share on other sites
54 minutes ago, ray-dude said:

The period value reflects how the various channels are interleaved in the buffer,

That's not right. The period size determines how often the application is woken up to replenish the buffer. There must be at least 2 periods. 4 is usually a good choice.

Link to post
Share on other sites

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