AudioLinux and NUC Troubleshooting and Tuning

[austinpop]

40 minutes ago, afrancois said:

As most AL users strive to have AL in RAM it would be nice to have AL started using Netboot. Thus booting over ethernet.

It will be somewhat harder to configure, but this way you will not have to manually remove the USB thumb drive (or in my case the USB SSD drive)

I've done this a long time ago, to load an entire OS from the network. The bootloader and the drives were on my NAS. I did configure a LUN and some iSCSI drives if memory serves me.

 

Agreed, that would be an elegant solution. I’d love to know how to configure this...

[austinpop]

Random Tips and Tricks

 

Here are some random tips and tricks for AL headless. Since these are for system changes, don't run this in ramroot mode. ssh into the system, and run as root. Finally, make sure the USB stick is inserted. Been burned by this before!

• First, disable ramroot
  • ramroot remove
     

• Fix the time zone:

  • timedatectl set-timezone America/Chicago (pick yours - look in directory /usr/share/zoneinfo)
     

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

  • Edit the file: /etc/systemd/timesyncd.conf

    • Change previous [Time} stanza to:
      [Time]
      NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
      FallbackNTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org

  • Run timedatectl set-ntp true

  • It may take a few minutes for the sync to occur, after which your system date and time will be accurate.
     

• Set hostname

  • hostnamectl set-hostname <NAME> 
     

• List detailed system HW info

  • (pop out of root to run yaourt)

  • yaourt -S inxi

  • Once installed, run: inxi -Fc0
     

• Reducing the size of the RAM root partition
  You might want to do this for a couple of reasons - to reduce boot time, and to increase free memory - for example, to run squeezelite with larger -b buffer. As you do each step, monitor the used space on the / filesystem with command df.

  • Uninstall unwanted packages

    • List all installed packages: pacman -Qe

    • For each package you want to uninstall, e.g. in my case, I don't use HQPlayer.

      • pacman -R hqplayer-network-audio-daemon hqplayer-embedded

      • Warning: don't go nuts here. Most of the packages are there so you can build any new packages you may want to install. I would just focus on the audio packages like Roon and HQPlayer.

  • Delete pacman temp files

    • clean

  • Clean up journal

    • Check current journal size: journalctl --disk-usage

    • Pick a max size you’re comfortable with, say 32M

    • Trim journal down to that size: journalctl --vacuum-size=32M

    • Set threshold for future growth:

      • Edit /etc/systemd/journald.conf

      • Uncomment (remove #) and change line to SystemMaxUse=32M

  • Delete core dumps

    • rm -rf /var/lib/systemd/coredump/core*

    • rm -rf /run/systemd/coredump/core*
       

• Once you're done making changes:

  • ramroot -F enable
     

• Monitor free memory at run time

  • Monitor memory in use with free and/or top

  • After RoonBridge has been running for a long time, when you run free, you'll notice that the size of the FS cache - see the buff/cache column in the output of free - has grown quite large. If you want to reclaim this space and make it free again, say to run squeezelite with large -b values, run:

    • echo 3 > /proc/sys/vm/drop_caches

[austinpop]

1 hour ago, rickca said:

Wireless is another thing altogether.

 

Yes, all bets are off with wireless. You have to renounce your worldly possessions and become a supplicant.

[austinpop]

1 minute ago, mozes said:

I don't need wireless, I always use a bridge that is clocked by an sCLK-EX board

 

Yeah just kidding around. I personally go the extra step and configure it with a static IP so I have a fixed IP I can ssh to whenever I need. But for initial experimentation, it's already setup to grab a DHCP address.

 

The Guide page actually has a lot of useful info: http://www.audio-linux.com/#GUIDE. I just use "find" in Chrome to search within the page.

[austinpop]

Bringing over another shuttle load of questions from the mother ship:

 

5 hours ago, yellowblue said:

I am interested in the user experience with the NUC dual setup and AL. If I want to shut down the NUCs or reboot them. How long does it take to actually get them playing music?

 

As previously answered, once you have Extreme, RamRoot, and RoonBridge enabled, just give it a few minutes. It will auto select AudiolinuxExtreme on the boot prompt, auto load to RAM, and auto start RoonBridge. I just wait until Roon shows me the device is ready.

 

5 hours ago, yellowblue said:

With a Zenith SE everyting is very comfortable. What will be the difference?

 

The key difference is that the SE boots from SSD, and has a web UI. I'm sure the latter will come with time. The advantage of the USB boot is you can remove the stick after boot, so no noisy device.

 

5 hours ago, yellowblue said:

Using extreme mode - is there a possibility to have som kind of energy saving mode while not using the NUCs?

 

I don't know if there is a way to pop in and out of Extreme mode on the fly. That is a good question for @hifi25nl. My guess is it needs a reboot.

 

My plan is to just power down both the endpoint and the server between listening sessions, as the Extreme mode does run hotter.

 

5 hours ago, yellowblue said:

Thamk you for your answer, Alan! No need to activate extreme mode seperately every time? Do I need a monitor to start/reboot AL?

 

Once enabled, it's automagic. Just give it time to complete.

 

4 hours ago, mourip said:

Two questions...

 

Does anyone have a good way to clone a USB drive? Can Rufus do that? I think that my current USB drive is a USB2 and it takes a long time to boot all the way to ramroot. My ports are USB3 so I was thinking of buying a new drive to see if it would speed boot-up.

 

I've not done it, but I can't imagine how it wouldn't. At the very least, save the drive as an image, and then burn onto the new drive.

 

4 hours ago, mourip said:

Second. I have not used USB in my system for a couple of years. I have been using Dante ethernet to AES. Any suggestions for a good "bang for the buck" USB cable?

 

I've been very happy with the Lush^2 cable. 

 

2 hours ago, yellowblue said:

Many questions just today because I am just about to order a NUC: Someone who know if a NUC7i7DNH (15W) on AL extreme mode will work with a LPS 1.2?

 

Not on mine. I think @lmitche found a TDP 10W mode, which is not on my BIOS, so you may have to do it through another OS first. Plus he had to turn off a LOT of stuff. 

 

5 minutes ago, greenleo said:

 

For the users who changed the chassis of the NUC7CJYH, how did you get out the main board?  Is it by brute force?  Any tricks?

 

Check out the YouTube videos. I didn't end up having to exfiltrate the board out of a NUC enclosure myself, but had this video in my list if needed: 

 

 

[austinpop]

3 minutes ago, ray-dude said:

@austinpop Thank you for the additional impressions. May I ask where you ended up with your end point SqueezeLite parameter settings?  (your /etc/squeezelite.conf )

 

I've just stood up my NUC7CJYH as a Roon Bridge end point, and want to experiment with the Roon Server/SqueezeLite end point configuration that you developed (alas, I confess that the myriad of SqueezeLite parameters are all still pig latin to me)

 

Yes, this is the reality of NUC-world. It's a bit wild west. 

 

As regards squeezelite, the main parameter for SQ is the -b one for preallocated buffers. I was lucky that my first experiment with AL was on a Zenith SE that already used squeezelite as its internal player. I was able to duplicate the settings in the existing conf file.

 

Other than that it's trial and error and forums! I can try and help out, but no guarantees. First, get me a few key things:

• install squeezelite (not R2) from the AL guide
• amount of RAM on your NUC?
• Run squeezelite -l and tell me your output
• Do you care about DSD? Does your DAC require DoP?

We'll go from there.

[austinpop]

6 minutes ago, ray-dude said:

 

Thank you Rajeev

 

I just got my NUC7CJYH w/ 8GB up and running headless in RAM root (thank you and everyone here).  Runs great as a Roon Bridge, connected via USB to my Chord Blu2 (then Chord DAVE DAC).  Upstream I have a vanilla Mac Mini (OSX) running my Roon Core, not yet optimized.  With this setup, I need the end point to just pass things bit perfect to the BluDAVE and let it do its (considerable) magic.

 

The tunability of the Squeezelite end point (vs Roon Bridge) seems like a great opportunity to dig in and figure out what is driving the SQ boosts we're all hearing.

 

 

 

 

My /etc/conf.d/squeezelite settings are:

 

parameters="-o front:CARD=Blu2,DEV=0 -b 2097152:2097152"

 

(piggybacking on your findings that maximizing buffers makes things better, although I'm wondering if weighting more towards the input or output would move the SQ needle...TBD)

 

However, I was also looking at the real time priority, parameters for connecting to the DAC, and even codec settings as potential SQ levers (TBD how the stew of latency and compute and OS priorities all come together when you expand the test matrix)

 

I hoping to dive in this weekend and start doing some investigations.  If you (or others) have run into dead ends or opportunity areas with Squeezelite as the end point, it be great to build on that!

 

 

 

 

Excellent. If those setting are working, then you're good to go, and we would love to hear about your findings.

 

[austinpop]

2 hours ago, greenleo said:

@austinpop

 

Hi Rajiv, For your current NUC, which is NUC7i7DNBE, is the size of the dc plug also 2.5, like the NUC7CYJH?

 

Yup, 2.5mm. I am using a 2.1-to-2.5mm barrel adapter for now.

[austinpop]

BTW, this one's a bit arcane, but Piero tells me it will be delivered in a "monitor menu" that he'll hopefully deliver in 0.6.

 

Say you booted your NUC a few days ago - but can't remember if it was in Extreme mode? How can you tell at runtime?

 

Per Piero:

you can type
cat /proc/cmdline
If you have booted in Extreme mode you will see these parameters:
intel_idle.max_cstate=0 processor.max_cstate=1 idle=poll

[austinpop]

What is the proper way to update my system to 0.6 while preserving all customizations? I did this - downloaded the 3 files below:

-rwxr-xr-x 1 audiolinux users 70295236 Dec  6 17:32 linux-rt-bfq-4.19.1.3-2-x86_64.pkg.tar.xz

-rwxr-xr-x 1 audiolinux users 16020220 Dec  6 17:33 linux-rt-bfq-docs-4.19.1.3-2-x86_64.pkg.tar.xz

-rwxr-xr-x 1 audiolinux users 18297092 Dec  6 17:33 linux-rt-bfq-headers-4.19.1.3-2-x86_64.pkg.tar.xz

 

I then ran 

 

pacman -U linux-rt-bfq-4.19.1.3-2-x86_64.pkg.tar.xz linux-rt-bfq-headers-4.19.1.3-2-x86_64.pkg.tar.xz linux-rt-bfq-docs-4.19.1.3-2-x86_64.pkg.tar.xz 

 

I rebooted, but when I login, I still see 0.5 on the login screen. And, if I type alconf I still get the old menu. 

 

Finally, what is the command for the new monitor menu?

 

All of this is on headless.

[austinpop]

10 minutes ago, lmitche said:

Download a new image and reapply your settings. There is no persistence for the alconf settings although some will be correctly set by default. You may need to re-add any custom scripts as well. I built a checklist. No big deal if you know what you are doing. It gets easier with every release.

 

7 minutes ago, LTG2010 said:

That's just to update the Kernel (engine) not the whole OS. I'm still on 0.3

 

OK thanks guys. Piero confirmed the same.

 

BTW - I don't have Intel Speedstep in my NUC7i7DNBE BIOS at all. I am guessing it's only applicable to Pentium, not Core i7?

[austinpop]

11 hours ago, BigAlMc said:

Apologies if I've missed this either here or on the mothership as Rajiv put it ?

 

I have the parts arriving today and tomz to attempt building an AL NUC server over the weekend. Occurred to me when walking into work this morning that there are a couple items I don't have a clue about. [Ok there are many, many items I don't have a clue about ?, but these are specific items].

 

I know how to install and format an SSD in a windows environment where it would detect the new drive and prompt you to take actions from there.

 

Q1. What is the story on AL? Will it recognise the drive and prompt me? Or (gulp!) do I need to use Linux commands to install and format it? And if the latter can anyone point to simple instructions for this?

 

Q2. If I have my music files available on either a Windows laptop or an external USB harddrive, how do I copy them onto the SSD in the AL NUC server. I'm assuming this is definitely Linux commands. Again any guide for this sort of thing would be great.

 

Thanks in advance!

 

Alan

 

 

Did you get an answer? I know how to muddle my way through it using gparted on the command line. I'm guessing there is an easier way to do it with the LXQT version that someone can elaborate.

[austinpop]

27 minutes ago, rickca said:

The i7-8650U has Speed Shift technology which is a more sophisticated implementation of SpeedStep.

 

But no control in the BIOS?

[austinpop]

FYI - Piero @hifi25nl is looking into making a true OS updater starting with 0.7! 

 

I too have a doc with my customizations, but I'm lazy to reapply.

[austinpop]

36 minutes ago, Dutch said:

@hifi25nl,

 

Some questions after reading: http://www.audio-linux.com/html/realtime.html

 

I’m running just Roon Bridge on my AL headless (0.6) NUC (it’s the endpoint) and I’m seeing these related processes :

 

root       544     1  0 17:41 ?        00:00:00 /bin/sh /opt/RoonBridge/start.sh

root       549   544  0 17:41 ?        00:00:01 RoonBridge --debug --gc=sgen --server RoonBridge.exe

root       590   549  0 17:41 ?        00:00:10 RoonBridgeHelper --debug --gc=sgen --server RoonBridgeHelper.exe

root       595   549  0 17:41 ?        00:00:00 /opt/RoonBridge/Bridge/processreaper 590

root       601   549  0 17:41 ?        00:00:39 RAATServer --debug --gc=sgen --server RAATServer.exe

 

In the rtapp.conf file (below) I see RoonBridge is listed but not RoonBridgeHelper or RAATServer. Since these have used more CPU time, would it be beneficial if I/we added those processes to the applications list?

 

Also I see —debug in the process list? Is that necessary or better said would it be ‘leaner and meaner’ to not use those switches?

 

Thanks in advance. If you’d like me to email you instead please tell me. It’s just that I though this might be beneficial to other users as well.

—

audiolinux@audiolinux ~]$ more /etc/rtapp/rtapp.conf

APPLICATIONS="jackd mpd hqplayer hqplayerd RoonAppliance RoonBridge mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity"

 

MAX_PRIORITY="93"

 

MODE="autodec"

—

 

Good questions. I actually went ahead and added RAATServer (and squeezelite) to the list. Can't say it had an audible effect!

 

The --debug question is a very good one. I hadn't even noticed that.

[austinpop]

2 minutes ago, gsquared said:

@Dev if I recall, you have the NUC8i7BEH, which is the model I have. 

 

I am running mine as a Roon server headless with AL + the Roon db in ram. I have a monitor hooked up while I get it fully configured, but I'm finding that it almost always throttles (cup clock throttled) - and it's just sitting idle. I have it running in Standard mode as well. Does yours typically throttle? I wonder if it's because I have my Roon db loaded into RAM as well.

 

@lmitche @austinpop any ideas how to solve this issue? I'm thinking about getting Optane memory to store the Roon files on to see if that solves the problem.

 

 

 

When you say "throttled" what do you mean? What metric are you referring to, and how are you measuring?

 

If on the off chance you are referring to 100% CPU utilization, then perhaps it's just the initial scanning of the library and the building of the Roon DB.

[austinpop]

Ahh - looks like a heat issue. Not had that myself. Hopefully others can elaborate.

 

Are you in a fanless case? 

[austinpop]

Awesome work!

 

I did some analysis last night as well, and will post my findings once I get to a keyboard later this afternoon.

 

Stay tuned.

[austinpop]

So I have been scratching my head about this SQ boost running squeezelite with large input stream (from LMS) and output stream (to USB device, i.e. DAC) buffers. After all, think about these points:

1. In ramroot mode, the OS (i.e. the / filesystem) is loaded into a RAM disk (/dev/zram0)
2. The squeezelite executable (the exe for you Windows types) is now living on the RAM disk at location /usr/bin/squeezelite, i.e. also on zram0
3. When you "run" it, you create a new process, with its own virtual address space, and the loader starts loading pages from the file... which is already in memory!
4. Once you start streaming the music, it looks like squeezelite has an input_stream buffer (receive from LMS/Roon) and an output_stream buffer (send to USB device, i.e. DAC/DDC)
5. These buffers are also in memory. All that -b does is preallocate a large buffer from the get go.

So what is different about the default case (no -b) with the large buffer case? Why does the latter sound better? In both cases, all I/O is from memory already, or from the network. So I did some monitoring.

 

I ran a 24/96 track, that is 11.5 mins long. File size is 188MB. With FLAC compression, it's effective bit rate as shown by MP3tag is:

 

  2274 kbps

 

 

 

I streamed this file in 3 configs, with the server running Roon Core:

1. RoonBridge
2. squeezelite default
3. squeezelite -b 1572864:1572864

Between each run, I cleared the filesystem cache by running: echo 3 > /proc/sys/vm/drop_caches

 

I used the command iftop -i eno1 to look at network traffic. The 3 columns show the average over the last 2, 10, and 40 secs respectively. I'm showing the numbers for the bottom of the screen, which are the aggregates for the entire machine on the eno1 (ethernet) interface. The first row is outbound, the second is inbound. 

 

RoonBridge

 

 

As you can see, Roon is consistently streaming the file from the Core on the server to RoonBridge on this endpoint at a little over 4Mbps. Actually, it is most likely the RAATServer instances on each side that are transferring data. I wouldn't worry about precision - I don't know what the overhead of the iftop tool is, but you can see it's greater than the effective bitrate of the audio, so at this rate, Roon always ensures that the buffer feeding the USB interface is never empty. Which from a flow control and efficiency perspective, makes perfect sense. At this rate, the transfer should still complete well before the song, but I didn't run long enough to check.

 

Default buffers (no -b flag)

 

 

Ditto for the default squuezelite case. Yeah the rate is a little lower, but effectively we're just streaming fast enough to avoid underrunning the output buffer. Again, seems logical.

 

Large buffers (-b 1572864:1572864)

 

Here's were it gets interesting. For the first few seconds, it's firehose mode on the network! Look at the 2 sec average (1st column) because this mode doesn't (or dudn't if you're Texan) last very long. Essentially we're sending the whole file over.

 

After that, it's crickets (quiet) on the network. Again - focus on the 2 and 10s averages, as I didn't wait long enough for the 40s average to clear.

 

Conclusions?

 

Well, there's still no explanation. Why does "large buffers" sound better? In all these cases, everything (OS, executables, runtime input and output buffers) is in memory. So what gives?

 

Well, one answer - from the user/listener perspective is: who cares!? If it sounds good, use it and enjoy!

 

From the designer's perspective, it's a head scratcher. Could it be that the things listed below result in lower "noise?"

• preloading the file in the first few seconds of playback quiesces the IRQ rate and IRQ processing during the rest of the track?
• by preloading in a big gulp from the network, squeezelite is making system calls (socket send(), recv(), select() etc) at a much lower rate?
• Even without large buffers, this workload runs at an astonishingly low CPU util. Here's one example in the RoonBridge case:
  
  and this is in the large buffer case:
  

Ultimately I didn't find anything I can point to, that would suggest better SQ. Clearly, something about the system operation in the large buffer case sounds better.

 

[austinpop]

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!

[austinpop]

Someone asked me to share my NUC7i7DNBE BIOS settings via PM, but I'm posting here, just in case I got overzealous, and need to turn something back on. OR - anything I missed.

 

Again, this is specific to the above model, although I'm sure very similar to other NUC7i7DN models.

 

My NUC7i7DNBE BIOS settings

• Power > Primary Power Settings > Low Power Enabled

• Security > Security Features >

  • Intel Trusted Execution Technology: off

  • Intel Virtualization : currently on, probably need to turn off

  • Intel VT-d : currently on, probably need to turn off

• Performance > Processor

  • Hyperthreading: off

  • Turbo boost: off

  • Realtime performance tuning: off

  • Silicon debug: off

• Devices

  • SATA: off

  • PCI M.2: off

  • HDMI Audio: off

  • TPM 2.0 Presence: off

  • Serial port: off

• Boot

  • Secure boot: off

Please share any differences or suggestions.

 

[austinpop]

1 hour ago, misterspense said:

Are you guys using the R2 version of Squeezelite, or the 1.9 version? Is there also a sound quality difference between them, or are they more related to the settings used, and the standard settings R2 and 1.9 come with?

 

I'm using the community "Ralph Irving" version. I had trouble getting R2 working, although it may have been resolvable with more effort. I also got confused with a seeming dependency on C-3PO, although that may have been a misunderstanding.

 

Piero now has links to both.

[austinpop]

2 hours ago, BigAlMc said:

Thanks @afrancois

 

I've spent the morning pottering and am admitting defeat. The i7DNBE is not willing to boot with either the LPS1.2 or the SPS-500.

 

I've switched off everything possible and disconnected everything possible and no dice. It just doesn't seem to like either.

 

Am thinking I'm gonna need to buy a new PSU (Sean Jacobs, HD Plex etc) but that's really annoying when I have a collection of PSU's at hand!

 

Cheers,

Alan

 

Thats weird. I used an sPS-500 set at 19v to first boot my NUC7i7DNBE before I made any BIOS changes.

 

When I get a chance, I’ll confirm it still works. 

 

What actually happens when you turn the NUC on? I’m assuming your sPS is truly on - you know that drill with the long press of the power button?

[austinpop]

1 hour ago, davide256 said:

 

BTW, does Roon have any way you found to increase player/renderer track buffer used?

 

Not that I could find. But I haven’t looked very hard. Maybe RAATServer has a man page?

[austinpop]

11 minutes ago, BigAlMc said:

 

Defo need to try another DC barrel connector to rule that out.

 

I suspect that too. A faulty adapter is definitely not a barrel of laughs.