AudioLinux and NUC Troubleshooting and Tuning

[davide256]

If you try AL/RPI3 as I did, you may run into limitations. I could only get the 32 bit version to work for Roonbridge with greater than CD quality by using the overclocking config

remarked out in config.txt. The 32 bit AL image sounds great but you can hear "graininess" on cymbals and massed strings, an area where the better hardware of a microRendu

sounds cleaner.  In email with Piero he advised that 64 bit did not have overclocking support, and that for AL faster processor improves sound so I intend

to pass on getting the 64 bit client working, moving on next to a Celeron or Pentium NUC for endpoint.

[davide256]

If you are using an older non UEFI PC with AL you will need to run LXQT version 2.19. In this case you can use Rufus to image a USB connected SSD drive

then connect the drive normally as internal SATA.

[davide256]

On 11/29/2018 at 6:30 PM, greenleo said:

Hi L&L and other CAers,

 

A new version of AL lxqt is coming.  This version will greatly simplify the basic operations of the AL in GUI mode.  I'm testing it and also trying thing that CAers here or CAers in the "mother" thread may find interesting.  Will report if new things come up and produce a walk through with images if possible.

 

Regards.

It would be nice if LXQT had a reboot option that switched  headless <> GUI. Far easier to make/save changes in GUI mode than to do it all through command line

in headless, than switch back to headless/no GUI.

[davide256]

1 hour ago, greenleo said:

Headless and lxqt are different things.  Larry mentioned in the "mother" thread that it's very difficult to make an lxqt a headless.  I asked him there and that's his reply.

 

Anyway, headless is used as an endpoint and the lxqt used as an control PC.  In this case, there is no reason to switch back and and fro.

All headless means is that there are no drivers for input/output peripherals... you access the OS remotely over IP connection. WIth LXQT you do have

the added overhead of more drivers loaded  but you can just physically unplug the input devices and you can disable the GUI from loading. 

I'm running LXQT as Roon endpoint on Raspberry Pi and I have the same option with PC.

The main disadvantage of LXQT is it requires more RAM... my RAM disk consumes 8gb of RAM for OS and Roon database. You have to jettison the peripherals

driver database (headless)to get AL to run on only 8GB of RAM

[davide256]

7 hours ago, TubeMan said:

you can boot a LXQT in Cli mode "command Line Mode"

 

CHANGING BOOT DEFAULT

* In audiolinux lxqt you have 2 more options:
audiolinuxclBFQ (headless command line boot)
audiolinuxclEXTREME.conf (headless command line boot, extreme mode)

For changing boot default you can edit as root the file
/boot/loader/loader.conf
and change the line
default audiolinuxBFQ
to
default archlinux (standard archlinux kernel, if installed)
default audiolinux-fallback (realtime kernel bfq, if you have problems at boot because of missing drivers)
default audiolinux  (standard rt kernel, if installed)
default audiolinuxEXTREME (realtime kernel bfq with some parameters that prevent cpu sleep. In

Thanks will try this. For some reason the option screen to change this right before load to RAM doesn't display right on my hardware so I'm never sure

if the option selected was launched

[davide256]

10 minutes ago, lmitche said:

Yes, that's right. Also run 4gb of ram, disable every circuit you can and it may boot on the lps1.2. It's inconsistent at best here, so I'm not recommending this.

mmm. Received  NUC7PJYH  last nite, straight forward to configure it for USB boot, disable unused peripherals, and get AL headless up and running in RAM as Roonbridge.

But not finding it to be an improvement from overclocked Pi3b+/AL/LPS 1.2 so far; sounds like an improved version of microRendu for detail but tone colors and dynamics

don't "pop" like they do with RPI3. Ran it off 19/12V for HDplex, but could not get it to complete  boot on 12V/ LPS 1.2. Appreciate suggestions above, would really like to

see if  better PS solves.

 

Also 2 simple questions

1) does it matter which USB port is used for boot?

2) does it matter which port is used for asynch USB connection?

.

[davide256]

46 minutes ago, LTG2010 said:

I'd use the rear ports for output (not sure if the front ports are connected via cables).

I would disconnect the fan, If no luck check if there's a low power setting in bios.

Was able to get it to boot and play with LPS 1.2 using BIOS power settings... set sustained power limit to 10 watts and burst to 12 watts.  Believe this uses Intel Speed Step to

throttle CPU's, suspect it would sound better if this wasn't needed/used. But it does sound better  now that I can use LPS 1.2, dynamics are improved, still evaluating bass.

[davide256]

14 minutes ago, greenleo said:

Inconsistent in terms of can/cannot boot up or SQ good/bad?

@lmitche

Did you try the power limit option? Seems to be working so far with limiting power to 12 w for burst

[davide256]

After playing with it every which way I could for PS/BIOS config/ AL config, I'm not finding that the NUC7PJYH  can be my final destination for a Roon endpoint.

 

While its detailed and clean with AL, even better so than microRendu, its not matching up to overclocked RPI3B+/AL for midrange bloom and for reach/impact with low bass.

As a tuba player, I'm sensitive to muddy bass, the RPI3B+ doesn't suffer at all here, just has issues with cymbals and other complex high frequencies. The NUC7PJYH

in contrast makes me grit my teeth when low bass percussion is happening.

 

What really hit me hard was playing a random track, Elvis Presley's "Suspicious minds", the  NUC/AL  made it sound lifeless/AM radio fodder, whereas the RPI/AL  brought it to life, showed nuance and expression.

 

[davide256]

6 hours ago, clipper said:

Before you give up on it, try it with Intel SpeedStep off.

 

I was much more impressed once it was running with SpeedStep off. 

Yup, been there. Setting temp to allowed max before fan cuts in was also helpful. But no checkered flag for the NUC in the end

 

[davide256]

25 minutes ago, lmitche said:

Hi David,

 

We can help but need a bunch of details first. As you know there are a lot of knobs to set. Do you want to keep exploring options or are you done with the NUC?

 

I see you use a DDC for USB to spdif conversion. Do you know if the schitt eitr uses a XMOS USB chipset?

 

It would also be good to know how you are powering your NUC.

 

Thanks,

 

Larry

Willing to play around, still experimenting. Loaded 3.0 version of LXQT last nite, seeing what a NUC can do as a direct connect Roon server with USB3 attached SDXC storage,

easy to flip back to headless configuration

 

1) power supplies; HDPlex  19V or LPS 1.2 12V

2) Eitr is Schiits DDC, same Gen 5 board as used in Yggdrasil, not XMOS based

3) current config is SATA/sound/microphone disabled, fan speed set to 55C before cut in, Intel speed step disabled, sustained/burst power at 10/15, secure boot disabled.

  I haven't played with HDMI or video memory, didn't want to risk monitor issues with BIOS access

4) BIOS version when received 31, updated to 46

5) Running latest AL headless version

 

Disabling hardware/setting fan kick in speed higher so far has solved boot issues with LPS 1.2

[davide256]

1 hour ago, lmitche said:

Extreme mode?

Will try next, fingers crossed that doesn't drive it over LPS 1.2 current limit ?

[davide256]

1 hour ago, MrUnderhill said:

....and ramroot & remove the boot USB.

 

M

started from there..

[davide256]

54 minutes ago, rettib2001 said:

I have up until now been using an nuc7i7bnh as a combined server and endpoint.

 

Today I tried it as an endpoint using my macbook pro as a server (knowing that it isn't highly regarded as an AL server but hey, in lieu of anything better suited to the task I tried it any way). 

 

Well... The sound quality was much better than the nuci7bnh on its own. Crazy. 

 

Conclusion I need a second nuc. 

 

I'm edging towards a nuc7pjyh with a fanless case powered by a Paul Hynes SR4 (which I should receive before the end of the year) but I'd just like to know whether or not my i7 nuc, which has a tdp rating of 28, could be powered by the SR4 (2a/20a transient) 

 

In 'endpoint' mode the cpu usage is only about 3/4% and aside from one stick of 8gb ram there nothing else connected to it. 

 

If it can it opens up the option of a much more powerful server. 

May I suggest you try running your Mac as endpoint with the NUC as server? Then share which way you liked better.

[davide256]

Trying to run Roonserver headless on the NUC7PJYH, using USB attached SDXC storage.... mounting USB drives is driving me crazy. This is what I see using blkid for the drives

(480/128 gb storage)

Can anyone guide me on how to format the lines properly for mounting?

/dev/sdb1: UUID="6C96-68C4" TYPE="exfat" PTTYPE="dos" PARTUUID="7f653070-01"
/dev/sdc1: UUID="3233-6437" TYPE="exfat"

 

 

[davide256]

10 hours ago, lmitche said:

What's playing here:

 

 initrd=\intel-ucode.img initrd=\initramfs-linux-rt-bfq.img root=PARTUUID=166ad16d-098d-4453-ab07-7c5255b4d451 rw quiet intel_idle.max_cstate=0 processor.max_cstate=1 idle=poll intel_pstate=enable efi=runtime

 

SQ is outstanding across the spectrum. Bass is tight, in a punch in the gut way.

seeing at my end

initrd=\intel-ucode.img initrd=\initramfs-linux-rt-bfq.img root=PARTUUID=166ad16d-098d-4453-ab07-7c5255b4d451 rw quiet intel_pstate=enable efi=runtime

 

so there are  configuration differences. Looks like some kind of processor parameter?

 

[davide256]

9 hours ago, greenleo said:

USB should be automounted in lxqt.

Correct... I'm trying to use headless which doesn't do that

[davide256]

3 hours ago, BigAlMc said:

 

There have been a lot of posts about using the LPS1.2 but I'm personally struggling to get the power draw low enough for my LPS1.2 to be happy with the NUC. Will try again this morning but I also have an SPS-500 which should be capable of higher power output than the LPS1.2.

 

The Paul Hynes SR4 is also highly regarded but I think there is still a wait of a couple months. Relatively much faster than the SR7 but not ideal for impatient audiophiles.

 

PS I'm going to try the SPS-500 because I have one to hand but given the consensus was that the LPS-1 was better than the SPS-500, and given how much better the LPS1.2 was to the LPS-1 I'm not sure I'd advocate buying the higher priced SPS-500 if persevering and getting the LPS1.2 to work is an option.

 

Cheers,

Alan

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

[davide256]

I've reached the end of my playing around with NUC7PJYH as endpoint . The  way to resolve the issues with it was to use ISO Regen/LPS 1.2 at which point no more glare

or mid range suck out. Using ISO Regen/LPS 1.2 with  RPI3 remained better than NUC7PJYH.

[davide256]

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.

[davide256]

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.

[davide256]

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.

[davide256]

10 minutes ago, rickca said:

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

Older 100 watt  model

 

https://www.hdplex.com/blog/tag/hdplex-100w-linear-power-supply/

[davide256]

Just now, greenleo said:

I suppose the LPS-1.2 was the better PS in the context, right?

yes

[davide256]

14 hours ago, austinpop said:

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.

.......

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.

 

 

Think of this possibly as an exercise in thermodynamics?  Where the goal is to reduce heat noise/ electrical activity during processing of audio data?

I continue to wonder how an audio renderer  would sound supercooled...

 

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