Audiolinux Server configurations, Software, Hardware, and Listening Impressions

[davide256]

39 minutes ago, hifi25nl said:

As root:

pacman -S wpa_supplicant

thanks. That addressed the two errors. However at reboot and check, all was gone... no surprise since this was done in RAM mode

and I forgot to RAMsave. May I suggest adding both to the instructions?

 

1)  run pacman -S wpa_supplicant

2) before reboot, if in RAM mode, execute RAM save from AL menu

 

will rinse and repeat, remembering to RAM save, hopefully in the home stretch now

[Poldi]

On 3/27/2019 at 1:07 PM, Poldi said:

Thanks for all the valuable input so far! If I find the time, I will do a revision of my listening test this weekend and post any new findings here.

 

@LTG2010 Sensitivity to the server could be an explanation for my findings. Unfortunately I can't borrow a different server. I have a RPi here as an alternative but I doubt it would sound better with it. But I ordered some DC-tips to make the DC cables of my HDPLEX 200W LPSU compatible with my old Toshiba laptop acting as a server. This way I could at least improve the power supply. That I would also have the advantage of being able to try Euphony on this machine (as my NUC is UEFI only), this time with a better power supply.

And I already did all the BIOS tweaks that were advised in this forum (turned off wifi, SATA, turbo boost,...). But I will try using normal mode instead of extreme2 mode and see how it sounds. Ramroot was also already enabled and system was loaded to RAM.

 

@Dutch Thanks for providing your experiences. It's very useful for me! Before reading about the Audiolinux NUC I intended to upgrade my sms-200 to the Ultra version which already has the TX-USBUltra integrated. So it never ocured to me so far to buy it (also because it's not really that much cheaper than the sms-200 ultra). But now I see the advantage that I could use it with other devices than the sms-200. Regarding its price it is nontheless not something I will buy in the short run. (I am doing this hobby with quite modest resources at hand)

So unfortunately that's not really possible to try for me right now despite the fact that it seems to help a lot according to your experience.

 

But a Cisco 2960 switch (one of the newer white ones) is on its way to me, so I will be able to evaluate the impact of this switch on my system and on my NUC specifically. I just read about the Cisco switches some days ago in the NAIM forum and in this forum. I am really excited whether it will actually improve the sound that much.

 

@Confused No my sms-200 did have 0.46 installed during the listening test. But thanks a lot for pointing out that V0.4.57 and its new 100BASE-T  function brings significant improvements regarding sound quality. I really like the fact that SOtM continues to improve on their product even after having sold it. On the other hand in the past some of these updates have introduced new bugs but which have been addressed in subsequent updates. I am going to try it out the next few days. That of course might make it even harder for the NUC to beat the sms-200 on my system.

 

BTW I have an sBooster 12V BOTW ECO MKI power supply which I normally use with the sms-200. But the NUC refused to boot even (I used the biggest DC tip, sBooster supplies with the LPSU). Does someone know the reason for this? Is the DC tip wrong?

 

 

 

I finally found the time to do a little testing:

Cisco Switch:

The Cisco 2960 Switch is definitely staying! It brings out more details and a deeper soundstage. Much more "air" between the instruments. The difference is obvious, so I'd recommend it fore everybody on a tight budget as an alternative to audiophile switches.

Meicord Opal ethernet cable:

I also ordered a Meicord Opal ethernet cable after the comments about the Supra cable being "bright". The Meicord needs some burn it as it sounded horrible at first. But when I tried the next day it was much better than the Supra and now I understood the comments of the Supra being bright. It's not that the Supra is analytical. It just focuses a little more on the higher frequency spectrum. It presents the music in a pleasant way but in comparison to the Meicord as if with a soft focus. The Meicord is much more detailed and faster and has a wider and deeper soundstage.

Both cables profited from the Switch, but the Meicord much more. I haven't heard this amount of detail and this deep a soundstage in my system.

 

Ethernet vs Wifi:

I tried both: Server - Wifi, Endpoint - Wifi vs. Server - Ethernet, Endpoint - Ethernet. I found Ethernet to provide a little fuller more natural sound.

 

 

Audiolinux/Volumio on the NUC:

Although the Cisco Switch brought a clear improvement to the sound in my system it didn't change the results from my last comparison. My sms-200 (now on 0.49 and with 100-Base-T enabled, which also improved the sound) still sounded more analogue/natural. The NUC offered a rather typical digitial CD-Player sound. Some might prefer this but I want digital to sound analogue. I will try Euphony if it brings better results for me. If not, I will not follow the NUC approach any longer and just keep my sms-200.

[vortecjr]

3 hours ago, nbpf said:

No, the point of a RT kernel is to establish a predictable upper bound on latency. It is just a different way of scheduling processes which has nothing to do with buffer delays.

Agree to disagree because buffers and flow control can both affect interrupt times which you are trying to control with advanced scheduling. Anyway, I'm not saying it's bad or good just saying the two are odds with each other. 

[vortecjr]

On 4/3/2019 at 8:41 AM, nbpf said:

 

What is the meaning of  

pcm.!default {
        type plug
        slave.pcm hw
}

 

It means your are redefining ALSA's default device with a slave device hw via the pcm interface.

[vortecjr]

6 hours ago, hifi25nl said:

It should, as this is in the alsa documentation! Some users have already reported sound differences

 

 

Can you post a link to where this is documented? I have read that the the exclamation sign causes the previous definition of pcm.default to be overridden, but not that it bypasses ALSA mixer.

[hifi25nl]

For mixer it would be instead

 

pcm.!default {
        type plug
        slave.pcm "dmixer"
}
 

See https://www.alsa-project.org/wiki/Asoundrc

[hifi25nl]

Most of times I am using a user /home/audiolinux/.asoundrc configuration file with this inside:

 

pcm.!default {
    type hw
    card 0
}

ctl.!default {
    type hw           
    card 0
}

 

 

 

[Dev]

1 minute ago, hifi25nl said:

Most of times I am using a user /home/audiolinux/.asoundrc configuration file with this inside:

 

pcm.!default {
    type hw
    card 0
}

ctl.!default {
    type hw           
    card 0
}

 

 

 

 

Piero, can you explain this a bit on what it does ? Does it affect Roon (or Roonbridge) ?

[vortecjr]

12 minutes ago, hifi25nl said:

Most of times I am using a user /home/audiolinux/.asoundrc configuration file with this inside:

 

pcm.!default {
    type hw
    card 0
}

ctl.!default {
    type hw           
    card 0
}

It does not say that this bypasses ALSA mixer. It appears to just be a way of redefining hw 0  and card 0 as default.

[hifi25nl]

The only application that should be involved is Roon. Should be because the code is closed source. HQPlayer for example always connect directly to alsa. 

[lmitche]

12 minutes ago, vortecjr said:

It does not say that this bypasses ALSA mixer. It appears to just be a way of redefining hw 0  and card 0 as default.

It definitely impacts sq, so there must be more than a default change. 

[vortecjr]

15 minutes ago, Dev said:

 

Piero, can you explain this a bit on what it does ? Does it affect Roon (or Roonbridge) ?

Dev It can only affect sound quality if it applies some kind of DSP. Generally, you are not mixing system sounds with a dedicated endpoint so no issue there. Most devices have some combination of the following pertinant ALSA mixer controls - master volume, l/r volume, mute, etc. There is no set standard for this and some devices have none of these accessible in ALSA mixer. So if the device is un-mute and set to 100% volume there is no sound quality degradation. Except for loosing software volume control, the ability to mute and un-mute the device I see no issue bypassing ALSA mixer. However, I'm not certain that code bypasses ALSA mixer.   

[LTG2010]

1 minute ago, vortecjr said:

However, I'm not certain that code bypasses ALSA mixer.   

Alsa mixer doesn't appear in audiolinux settings when you open it, with the first 2 files (slave.pcm hw / slave.pcm "dmixer"

[vortecjr]

3 minutes ago, lmitche said:

It definitely impacts sq, so there must be more than a default change. 

ALSA is a mysterious beast and there are not many people who really understand it, I don't understand it 100%, but there is nothing definite about it. I'll ask around and see what I can dig up... 

[Miska]

Are you guys talking about ALSA's software audio mixer, or are you talking about ALSA mixer controls which allow controlling hardware parameters (for example if a DAC has controllable volume)? I hope you have not mixed up these two things...

 

P.S. HQPlayer Embedded supports combo-volume that combines hardware and software volume controls together.

 

[vortecjr]

2 minutes ago, LTG2010 said:

Alsa mixer doesn't appear in audiolinux settings when you open it, with the first 2 files (slave.pcm hw / slave.pcm "dmixer"

I'm familiar with dmix, but not dmixer. 

[vortecjr]

3 minutes ago, Miska said:

Are you guys talking about ALSA's software audio mixer, or are you talking about ALSA mixer controls which allow controlling hardware parameters (for example if a DAC has controllable volume)? I hope you have not mixed up these two things...

 

P.S. HQPlayer Embedded supports combo-volume that combines hardware and software volume controls together.

 

LOL...you saved me an email. That is a good point. I was referring to ALSA mixer controls which allow controlling hardware parameters.

[nbpf]

9 hours ago, vortecjr said:

It means your are redefining ALSA's default device with a slave device hw via the pcm interface.

Thanks!

[BigAlMc]

15 hours ago, hifi25nl said:

2) Euphony blacklist some modules in /etc/modprobe.d/blacklist.conf

blacklist snd_hda_intel
blacklist snd-hda-intel
blacklist iwlmvm
blacklist iwldvm
blacklist iwlwifi
blacklist bnep
blacklist btusb
blacklist bluetooth
blacklist joydev
blacklist mousedev
blacklist iTCO_vendor_support
blacklist iTCO_wdt
blacklist ip_tables
blacklist mei_me
blacklist intel_rapl
blacklist intel_powerclamp

 

Hi Piero,

 

If AL users want to experiment with these settings are these best for Server, Endpoint or both?

 

And do we need to reboot AL for these to take effect?

 

Ditto for the ALSA disable setting that @LTG2010 shared. I implemented this only on my endpoint as I assumed it was a player setting and doesn't impact the server. Is that correct?

 

Many Thanks,

Alan

[hifi25nl]

Yes, alsa configuration file will apply only on the PC directly connected to DAC

And you must reboot

[BigAlMc]

Thanks Piero!

 

Cheers,

Alan

[hifi25nl]

Menu 109 with new Expert Menu:

 

 1 "Minimize your system"

This is a custom AudioLinux script for disabling automatically some services and some kernel modules. Please use with care. You can list all loaded modules with the command

lsmod 

and all enabled systemd services with 

systemctl list-unit-files --state=enabled

 2 "Realtime expert configuration"

After pressing Yes you can edit the realtime special configuration script
This is really for experts. Please select No if you are not sure what this is

 3 "Disable realtime expert configuration"

 4 "Alsa system wide configuration file"

After pressing Yes you can edit the Alsa system wide configuration file
You can save with F2. Pressing F10 you will exit from editor and the file will be copied to /etc/asound.conf

Default is

pcm.!default {
        type plug
        slave.pcm hw
}

 

As for CPU governors, Audiolinux does not really need to add balanced, conservative, powersave, etc. since there is the custom option already in the menu where you can define minimum and maximum CPU frequency manually (Turbo ON or OFF)
 

[davide256]

On 4/4/2019 at 2:32 PM, davide256 said:

thanks. That addressed the two errors. However at reboot and check, all was gone... no surprise since this was done in RAM mode

and I forgot to RAMsave. May I suggest adding both to the instructions?

 

1)  run pacman -S wpa_supplicant

2) before reboot, if in RAM mode, execute RAM save from AL menu

 

will rinse and repeat, remembering to RAM save, hopefully in the home stretch now

@hifi25nl

 

 able to complete the instructions once I made sure to RAMsave after changes but was unable to connect.

 

I did find one error in the the instructions

using the "scan" command returned "XFINITY" as ssid.

After following the instructions through without success, I realized this  was a neighbors ssid .

 

Then edited the wpa_supplicant-wlo2.conf file to my ssid for 5g, ramsaved, rebooted, still no success

networkctl shows for wlo2 no carrier  configuring

 

two questions

1) how can I verify which SSID's the NUC does see

2) assuming it can see mine, what do I do at this point to get NUC wifi working?

[vortecjr]

On 4/4/2019 at 6:32 PM, vortecjr said:

ALSA is a mysterious beast and there are not many people who really understand it, I don't understand it 100%, but there is nothing definite about it. I'll ask around and see what I can dig up... 

I reached out to Roon to discuss this off line and they agree with me that the proposed asound.conf changes will not improve sound quality.

 

These are the cliff notes:

1. They don't see a mechanism of effect for this config changing sound quality of Roon Ready playback at all.

2. These configs are remapping "default" to "hw:X"--so it only affects apps that use "default". RAAT doesn't use "default"--it has always used "hw:X" directly. 

3. These mappings impact behavior at the time when an ALSA device is opened. So it's not even like they are "turning off" the system mixer in a global sense or something like that. If no-one tries to access the "default" device, then these have no effect at all.

 

I also researched as much of the ALSA documentation I could find and there is only one things that stands out for preserving sounds quality. When you assign the device "hw:X" it will not perform any conversions. Most conversions are needed for format matching. When you assign the device "plughw:X" it will perform any conversions needed for playback automatically. All this is a mute point though because these protocols are using hw:X.

[lmitche]

49 minutes ago, vortecjr said:

I reached out to Roon to discuss this off line and they agree with me that the proposed asound.conf changes will not improve sound quality.

 

These are the cliff notes:

1. They don't see a mechanism of effect for this config changing sound quality of Roon Ready playback at all.

2. These configs are remapping "default" to "hw:X"--so it only affects apps that use "default". RAAT doesn't use "default"--it has always used "hw:X" directly. 

3. These mappings impact behavior at the time when an ALSA device is opened. So it's not even like they are "turning off" the system mixer in a global sense or something like that. If no-one tries to access the "default" device, then these have no effect at all.

 

I also researched as much of the ALSA documentation I could find and there is only one things that stands out for preserving sounds quality. When you assign the device "hw:X" it will not perform any conversions. Most conversions are needed for format matching. When you assign the device "plughw:X" it will perform any conversions needed for playback automatically. All this is a mute point though because these protocols are using hw:X.

Thanks Jesus R,

 

This is interesting and curious. I have a little experiment in mind that may shed more light on this. Please be patient as it will be a few days before I can find the time to do this.

 

Larry