AudioLinux and NUC Troubleshooting and Tuning

[austinpop]

1 hour ago, bobfa said:

Roon audio device issue with two AL machines in the same network. @hifi25nl any ideas?  Anyone else? @austinpop 

 

I have one AL NUC machine running Roon Core. 

I have a Sonic Transporter running  Roon Core 

I have a second AL NUC  running RoonBridge

 

• When the Sonic Transporter is the Roon Core the NUC running roonbridge shows the DAC hooked to the USB port in Roon Audio Settings
• When the NUC AL machine is the Roon Core the same NUC endpoint does not show the DAC hooked up to the USB port in Roon  Audio Settings.
• ALSO when the two NUCs are running the devices "Connected to CORE" do not show up at all.  If I shut down the NUC running roonbridge the "connected to Core" devices appear.

 

This is weird to me.  Of note that both of the AL machines are built from the same download of AL and have been updated online.  (I should be properly licensed to run two)

 

NOTE: I built a new USB stick today for the roonbridge machine just to test. 

 

 

 

This sounds like the "unique_id" problem mentioned some time ago.

 

On the 2 AL machines:

• stop Roon Server or Bridge as the case may be. You can use the menu option to STOP and disable all running audio services
• (as root) rm -f /var/roon/RAATServer/Settings/unique_id
• Now start Roon Server or Bridge as the case may be. 

The visibility issue should be gone.

 

The other way to check that all 3 machines are visible on the network is to connect to either Core. Go to Settings, then About on the top right. You should see the Cores and Bridge listed.

[bobfa]

1 hour ago, austinpop said:

On the 2 AL machines:

• stop Roon Server or Bridge as the case may be. You can use the menu option to STOP and disable all running audio services
• (as root) rm -f /var/roon/RAATServer/Settings
• Now start Roon Server or Bridge as the case may be. 

I deleted the file unique_id in that settings folder on the bridge and everything is working.  I did not change it on the server yet. 

 

If someone else has this problem remember to fix it on real media if you are running in RAM

 

[jkelly]

I just got my two NUCS up and running - thank you for all your posts and tutorials.

 

I am able to get DSD 256 with a -2S on my i7NUC DNKE with hyperthreading and speedstep turned off.

I was wondering if I can attain DSD 512 with them on?  If it is possible, would turning these features on

defeat the advantage of 512K.

 

Thanks for your insite - I'll give it a try this weekend.

[jkelly]

Well it didn't boot - so I guess I have an answer.

 

[User471]

Anyone having any joy with the 'isolated cpu cores' setting?

 

On my endpoint, nproc gives me '4' so 4 cores right?

 

If I enable isolation using option 1) ('all but first') and reboot etc when I look in monitoring it says only 1 core isolated?

 

I expected 3 for audio, 1 for the rest

 

Any thoughts?

[hifi25nl]

The script use only physical cores not virtual ones. 

[User471]

9 minutes ago, hifi25nl said:

The script use only physical cores not virtual ones. 

 

oh I see !

 

in that case with 2 physical cores, is there still value to isolating 1 ?

[hifi25nl]

Yes is possible. In some systems could be better. Try to listen to differences... 

[misterspense]

On 1/5/2019 at 4:36 PM, clipper said:

Are you choosing the correct output device when you start squeezelite?

 

Do a squeezelite -l command to see the available output devices.

 

If I don't specify front (see below), I get 48 for everything.  I start squeezelite by typing squeezelite -o front &. 

 

 

 

Thank you for sharing this. On my system the Squeezlite is also stuck on 48kHz. When I go to the Status menu, Audio card status, and type 0, the Playback device is always on 48kHz, even if Interface 1 has rates 44100 through 192000.

I can stop all running services, and then type 'squeezelite -o front &' in the terminal to start squeezelite using "front". Then it outputs the correct samplerate, corresponding with the input signal (LMS or Roon).

But it does not keep it's setting. This setting is not there anymore in the file at /etc/squeezelite.conf, as in earlier versions of AL.

My question is: can I edit AL 0.8 somewhere, that it keeps 'front' as setting for squeezelite?

[hifi25nl]

What is the content of /etc/squeezelite.conf?

You must edit it manually with the right parameters.

You must use in this case squeezelite (not R2) and start squeezelite not R2 version

 

...And in ram mode you must save system

[misterspense]

23 minutes ago, hifi25nl said:

What is the content of /etc/squeezelite.conf?

You must edit it manually with the right parameters.

You must use in this case squeezelite (not R2) and start squeezelite not R2 version

 

...And in ram mode you must save system

 

Contents of the file are:

 

# default squeezelite configuration

LOG_FILE="-f /var/log/squeezelite.log"

 

 

In an earlier version of AL there was a line referring to the sound card. It was something like 'default:CARD=Eitr' that needed to be changed to 'front:CARD=Eitr,DEV=0'.

But now that line is not there, so I'm not sure what to enter there.

[hifi25nl]

The default is

# default squeezelite configuration
LOG_FILE="-f /var/log/squeezelite.log"
OPTIONS="-o front:CARD=Audio,DEV=0"

Where you should substitute  front:CARD=Audio,DEV=0 with your card option

[hifi25nl]

New menu version 090!

 

Now there is the new option

         14 "Copy/Backup current installation to another drive"
With this option you can easily transfer your installation from USB stick to internal drive or make a new USB stick for endpoint/server without loosing your configuration

 

The new installation will have different UUIDs and different computer name (audiolinux2), also Roon unique identity is changed. This way there will not be problems when running 2 audiolinux installations on the same Network.

 

Be careful when you select destination drive. The destination will be wiped off!

 

 

[bobfa]

More to play with I am off to build a Master USB stick with this version.

 

 

[zizione]

Is there a SQ difference working from USB or SSD when ramroot is used ? I guess not, but to get confirmation...

 

Thanks

D.

 

[Advieira]

On 12/8/2018 at 11:06 AM, BigAlMc said:

 

 

Working on my new i7DNBE based Roon endpoint in the Plato X7 fanless case.

 

 

 

 

 

 

7i7DNBE works in Plato X7? Or only in Plato X7D?

[rickca]

38 minutes ago, Advieira said:

 

7i7DNBE works in Plato X7? Or only in Plato X7D?

Plato X7 is compatible with NUC7i5BNH / NUC7i5BNK / NUC7i3BNH / NUC7i3BNK.

 

Plato X7D is compatible with 

NUC7i7DNBE / NUC7i7DNKE / NUC7i7DNHE
NUC7i5DNBE / NUC7i5DNKE / NUC7i5DNHE
NUC7i3DNBE / NUC7i3DNKE / NUC7i3DNHE

[bobfa]

Looking for a quick way to swap between Wireless (internal) and Wired on a NUC running Roon endpoint.  I have both installed and I would like to be able to power the radio on and off without a reboot. 

[ray-dude]

I believe the only way to disable the radio is through BIOS, but in my experimentation, I am doing A/B by killing the WPA supplicant:

 

systemctl stop wpa_supplicant@wlo2

systemctl disable wpa_supplicant@wlo2

 

(replace wlo2 with the name of your wireless interface)

 

For context on how I have mine set up, I'll post my wireless set up recipe in the next post

[ray-dude]

 

 

The ArchLinux site (linked from the audiolinux site) has lots of good info on how to setup wireless networking, but it took a long time to wade through.  I distilled down my findings into a simple recipe that I use, that may be useful to others that want to play with WLANs on their NUC (I've used this on both my NUC7i7DNKE and NUC7CJYH)

 

 

 

* Make sure WiFi on in bios

 

* Install WPA supplicant

 

pacman -S wpa_supplicant

 

 

* Find out name of wireless interface:

 

ip link

 

(mine is wlo2)

 

 

* Quick setup of WPA supplicant config file

 

wpa_passphrase MYSSID MYpassphrase > /etc/wpa_supplicant/wpa_supplicant-wlo2.conf

 

(use your interface name where I used wlo2, and your WiFi SSID and passphrase in plain text

 

 

* Test wpa_supplicant

 

wpa_supplicant -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant-wlo2.conf

 

(again, use your interface name where I used wlo2)

 

If it connects cleanly, control C to kill.  If not, you have some digging to do to figure out why: 

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

 

 

* Setup to start at boot, start it up, and check that it is running

 

systemctl daemon-reload

systemctl enable wpa_supplicant@wlo2

systemctl start wpa_supplicant@wlo2

systemctl status wpa_supplicant@wlo2

 

(use your wireless interface name after the @ sign)

 

 

* Create /etc/systemd/network/wl.network for your wireless interface

 

[Match]

Name=wlo2

 

[Network]

DHCP=yes

 

[DHCP]

RouteMetric=20

 

 

* If you're going to run wired ethernet at same time modify /etc/systemd/network/en.network

 

[Match]

Name=en*

 

[Network]

DHCP=yes

 

[DHCP]

RouteMetric=10

 

 

 

* Restart networkd and check:

 

systemctl restart systemd-networkd

networkctl status

 

 

* Get IP address(es) and check

 

ip a

 

You should have a different one on each network interface you set up (wired, wireless, etc)

 

ping the IP address(es) from another computer on your network

 

 

[User471]

For those of you using NUCs, from a hardware perspective why do you think they are capable of outperforming bespoke kit like SoTM and Sonore?

 

It seems counterintuitive to me that a general purpose board like the NUC, once power supply issues are addressed, is there or thereabouts in SQ terms with kit very specifically designed to do one job well

 

I don't have an NUC personally, but I don't doubt for one moment those who claim wonderful things from them. I'm just intrigued as to why it might be so

[mourip]

1 hour ago, User471 said:

For those of you using NUCs, from a hardware perspective why do you think they are capable of outperforming bespoke kit like SoTM and Sonore?

 

It seems counterintuitive to me that a general purpose board like the NUC, once power supply issues are addressed, is there or thereabouts in SQ terms with kit very specifically designed to do one job well

 

I don't have an NUC personally, but I don't doubt for one moment those who claim wonderful things from them. I'm just intrigued as to why it might be so

 

I doubt that anyone here can answer that question but you will get a lot of very well informed and spirited guesses 🙂

 

Certainly Audiolinux has a lot to do with it plus a community with a tireless dedication to tweaking the heck out of the NUC bios settings, LPS supplies, fanless cases and Audiolinux itself. Audiolinux is lucky to have such a dedicated group of beta testers.

 

If I were doing development for either SoTM or Sonore I might be tearing up my products to figure this out ...however in all fairness they are probably not too worried as they offer turnkey solutions for those that have neither the knowledge or time to pursue this hands-on experience but want excellent sound quality. Additionally there is still debate or which products are the best so the gap must not be all that wide.

 

We may be in some way on the advanced edge of audiophile perfection but our legions are pretty small...if not determined.

[bobfa]

9 hours ago, ray-dude said:

 

 

The ArchLinux site (linked from the audiolinux site) has lots of good info on how to setup wireless networking, but it took a long time to wade through.  I distilled down my findings into a simple recipe that I use, that may be useful to others that want to play with WLANs on their NUC (I've used this on both my NUC7i7DNKE and NUC7CJYH)

 

 

 

* Make sure WiFi on in bios

 

* Install WPA supplicant

 

pacman -S wpa_supplicant

 

 

* Find out name of wireless interface:

 

ip link

 

(mine is wlo2)

 

 

* Quick setup of WPA supplicant config file

 

wpa_passphrase MYSSID MYpassphrase > /etc/wpa_supplicant/wpa_supplicant-wlo2.conf

 

(use your interface name where I used wlo2, and your WiFi SSID and passphrase in plain text

 

 

* Test wpa_supplicant

 

wpa_supplicant -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant-wlo2.conf

 

(again, use your interface name where I used wlo2)

 

If it connects cleanly, control C to kill.  If not, you have some digging to do to figure out why: 

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

 

 

* Setup to start at boot, start it up, and check that it is running

 

systemctl daemon-reload

systemctl enable wpa_supplicant@wlo2

systemctl start wpa_supplicant@wlo2

systemctl status wpa_supplicant@wlo2

 

(use your wireless interface name after the @ sign)

 

 

* Create /etc/systemd/network/wl.network for your wireless interface

 

[Match]

Name=wlo2

 

[Network]

DHCP=yes

 

[DHCP]

RouteMetric=20

 

 

* If you're going to run wired ethernet at same time modify /etc/systemd/network/en.network

 

[Match]

Name=en*

 

[Network]

DHCP=yes

 

[DHCP]

RouteMetric=10

 

 

 

* Restart networkd and check:

 

systemctl restart systemd-networkd

networkctl status

 

 

* Get IP address(es) and check

 

ip a

 

You should have a different one on each network interface you set up (wired, wireless, etc)

 

ping the IP address(es) from another computer on your network

 

 

Thanks for the formula it helps. I will have to adjust  and put in the route metric. I had used what Piero put up the other day on his website.  I am going to try an experiment where I have both network interfaces active and switch playback in Roon.  This will leave the wireless radio on.  I will then disable the  m.2 slot in the BIOS and see what happens to the sound from Ethernet.    Note I will post about adding the wireless card to the hardware shortly.

 

 

 

 

[ray-dude]

Doh!  I hadn't been to the AL site in a couple weeks.  Sorry Piero, I didn't know you had already posted an updated WLAN guide!  Thank you for putting that up (much easier to follow than jumping around the Arch Linux documentation)

[davide256]

5 hours ago, User471 said:

For those of you using NUCs, from a hardware perspective why do you think they are capable of outperforming bespoke kit like SoTM and Sonore?

 

It seems counterintuitive to me that a general purpose board like the NUC, once power supply issues are addressed, is there or thereabouts in SQ terms with kit very specifically designed to do one job well

 

I don't have an NUC personally, but I don't doubt for one moment those who claim wonderful things from them. I'm just intrigued as to why it might be so

 

Boggles me too but I see these unique factors

 

1) AL itself running in RAM along with the endpoint player software

2) the ability to eliminate all attached media drives at the endpoint , even the USB boot drive after load to RAM... this floored me

    when removing the USB drive after boot sounded better

 

 and apparently as off the shelf product, Intel NUC has better performing hardware integration than other NUC like products, with or without added hi-tech USB hardware.