Audiolinux Server configurations, Software, Hardware, and Listening Impressions

[ray-dude]

36 minutes ago, LTG2010 said:

I only have 8gb ram, on each machine so running squeezelite with the last buffer sizes you quoted, not ray- dude's settings. Ive been switching my machines over from server to endpoint duty and the difference is easily identifiable. I'll try to find some more ram and increase the buffers further.

edit: I suppose if your theory is correct then it could be the difference in endpoints I'm hearing not the server, so I'll need to look into this further, but definitely switching server power supply is audible.

 

FWIW, I am running squeezelite as the end point on my 8GB NUC7CJYH (headless AL 0.8x) with no memory issues.  In my (stale) ear fiddling last night, the -b flag was dominating the server isolation (as expected...that is input buffers and buffer to streaming for squeezelite)

 

In previous experimentation, I was fiddling with the -a buffer as the buffer between squeezelite streaming and the DAC (also gave significant SQ lift, but a different part of the buffer chain)

 

For this experiment, using large end point buffers to isolate the end point from anything upstream, the -b parameter is doing the heavy lifting.  Both the asymmetric one I'm using and the symmetric 2GB:2GB that Rajiv originally recommended both are plenty to buffer up the current and next tracks.

 

I'm doing (fresh) listening tests today.  There is on going status/maintenance traffic between the end point and the server during playback (from following along the logs), so the end point may not be completely isolated with the large buffers.  I thought I was hearing subtle differences last night, but they were fleeting so I didn't trust my ears.  I'm going to be repeating the tests today.  

 

If the incidental traffic is impacting SQ, we have access to the source code for both LMS and squeezelite, so there is optimization that can be done (once we determine what factors are impacting SQ and need to be optimized).  My working hypothesis right now is that network interrupts degrade the interaction between the end point and the DAC (at least over USB).  The buffers concentrate the network traffic for music transfer into a very short block of time (~1 second).  I'm not savvy on what is happening at all the various network layers when you bridge, but my speculation is that bridging isolates the end point from interrupts from background ethernet traffic.  All this is very speculative, but it is the hypothesis I've been testing with these buffer experiments (I am planning on layering on bridging next).

 

Regardless of root cause, the real benchmark test is to shut down the LMS server during playback (or better still for peace of mind, disconnect the ethernet on the end point) and see if you get any change in SQ.  

 

If the answer is no, then the end point is de facto immune to all the upstream components in your chain, and Bob's your uncle.  

 

If there is a change, then some interaction between the server/network/endpoint is responsible for it, so time to track it down so it can be managed.

 

I hate to think in a subtractive way, but for better or worse, your end point disconnected from everything except your DAC is your baseline reference of what everything forward of your end point is able to do.  Although you can improve SQ using the end point/cables/dac/transducers/etc, my starting hypothesis for these tests is that the best the server and network and everything behind it can do is to not take anything away from that baseline reference.

 

 

[ray-dude]

1 hour ago, austinpop said:

 

 

The situation is messier with Roon Core as server. There is no easy way to detach squeezelite from Core A and attach it to Core B.

 

For those doing this experiment, I recommend bypassing autodiscovery on the squeezelite end point, and directly binding it to the server you're testing.  Works very cleanly for both LMS and Roon Core on the server.  

 

On the end point (Z), stop squeezelite.  From the command line, execute:

 

/usr/bin/squeezelite -s 192.168.4.103 -o front:CARD=SCALER,DEV=0 -b 4097152:97152 -d all=debug -a 50000000:4 -p 93

 

where the -s parameter is the IP address of your server A or server B (and using whatever parameters your familiar with on squeezelite and required for your DAC)

 

When you're ready to switch, control C to kill it, and start squeezelite up again with the IP address of the other server.  Takes ~10 seconds for me to switch between A and B, whether running LMS or Roon Core.  (alas, unauthorizing and authorizing a single Roon license makes doing the experiment with both servers running Roon a bit more awkward)

 

For those that weren't following the other thread, when connected to the squeezelite end point, both LMS and Roon Server quickly (couple seconds) load up the squeezelite buffer with the current track and the next track.  You can kill the server or disconnect the end point from ethernet and it will happily keep playing the songs that have been loaded in the buffer (with 4GB in the buffer, there is a lot of running room).

 

This morning, I've been popping back and forth between LMS on my NUC7i7DNKE with music local in RAM, and LMS on my MacBook Pro running OSX with LMS over WiFi.  Both sound fantastic, but I'm detecting a very slight difference between the sources (slight edge to the NUC).  The befuddling thing is that killing the server processes or disconnecting the end point from ethernet is not changing the SQ (at least not that I can detect).

 

Befuddling (to say the least).  When I get back from shuttling my daughter around, I'm going to audit the LMS settings to see if there may be a configuration difference (transcoding, etc), and repeat the experiment with Roon Core running on both the NUC and my laptop.

 

For those doing the experiment with AL running on both servers, I'm very keen to hear your findings (that would eliminate version and configuration differences as a variable)

[ray-dude]

Quick update:

 

Order has been restored to my audio universe.  My MacBook Pro did not have lame installed, so there were transcoding differences on the LMS side.  With LAME installed, SQ sounds identical between LMS on the NUC server (with local files in RAM) and LMS on my MacBook Pro running OSX over WiFi.

 

When running Roon Core on the NUC and Roon Core my laptop connecting to large buffer squeezelite on the NUC end point, SQ also is the same for me (at least to the limit I can resolve with my ears and end point)

 

To close out the configuration testing, with the NUC running LMS, I can't distinguish between files that are copied locally (in RAM) vs files from an SMB share from my MacMini (magnetic HD, vanilla network and Mac Mini running OSX).

 

My NUCs are both on the stock SMPS's (I'm waiting for my SR7), and my network switches are vanilla, so I'm eager to hear if those of your with more refined power and network setups are able to distinguish any differences between servers when running the large buffer end point configuration.

 

My next step is to make my NUC7i7DNKE the large buffer squeezelite end point, and make my NUC7CJYH the LMS server, accessing SMB share for content.  I will also bridge the server to the end point to see what that does.

 

[ray-dude]

1 hour ago, bobfa said:

Help with configuration of AL on a NUC to run Roon Server.

 

I have an i7NUC in the intel supplied case.  I have 16GB of RAM and a spare M.2 SSD. I have a NAS that I will keep the music on as there is about 4TB of it to manage!  I have an HDPLEX 200 Linear supply on the way to run both the NAS and the Server.  

 

I want to compare this to my Sonic Transporter i7 DSP running the stock OS and then build AL for the ST to compare against.

 

I know that Roon wants the boot and database on a fast drive. E.G. SSD. I do not know how big the database and caches get. I have 60K tracks in my main music store.

 

Where do you folks think I should start?  

 

Bob

 

 

 

 

 

I have about 2TB and 30k tracks in my Roon DB, and it runs very comfortably in ram booted to memory on my 16GB 7i7NUC.  The only caveat is to make sure that you expand the AL partition on your USB to cover the entire USB stick, otherwise the Roon DB will make your system too big to save to the USB (there is a menu item for that now)

 

[ray-dude]

Alas, Roon optimizes for multi-room, multi-stream playback. That would be challenging with in memory caching, but doable. I hope they cave in this, but they’ve been adamant that it is incompatible with what they consider a core feature in their system. 

 

If you use Squeezelite as your LMS end point, Roon Core does respect caching the current and next track to the end point. With Squeezelite and a large input buffer, I did a fun experiment where I queued up 2 long tracks, hit play on Roon, disconnected my end point from Ethernet, and it happily played music from RAM for 20+ minutes. 

[ray-dude]

21 hours ago, davide256 said:

 

hmm, could you do this locally with AL, have Roonserver send to LMS as endpoint on same box? Eliminate local media access during track playback of an album?

 

I gave this a try this morning and it worked.  The caveat is to stop Roon server, start squeezelite, then start Roon Server (so Roon doesn't claim the USB device).  

 

I did not do any SQ comparison between Roon direct vs Roon to Squeezelite in a one box solution (I have a separate AL end point)

[ray-dude]

On 4/4/2019 at 8:16 AM, 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

 

Just getting back to AL tweaking, catching up on all the goodies from the last several weeks (thanks to all!)

 

For those that have been experimenting with blacklist modules, is there a consensus on which make the most sense for AL on end points and server?  I'm not seeing most of these with lsmod, but I'm seeing a lot of others that may be candidates to disable (NUC7i7DNKE for both end point and server, running Roon)

 

 

[ray-dude]

16 minutes ago, lmitche said:

I see some kvm stuff in lsmod that may be a good candidate for removal.

 

I was also eyeing a bunch of the non-PCM stuff on the snd_usb_audio dependency tree

 

I'm leary of trimming i915 and the rest of the video tree (make the system truly headless) since I sometimes have to hook up a monitor to debug these beasts.  One take I'm thinking of is a script to rmmod a bunch of these things that I manually run after boot.

 

[ray-dude]

On the audio linux site, I see that a new kernel (5.2) is available.  Any impressions from those that have upgraded?  Has anyone found release notes about what we should expect for Audio Linux from this kernel?

 

 

[ray-dude]

Interesting.  Chord DAC's are particularly sensitive to RF in the 2-2.5GHz range.  Larry, have you dug up anything equivalent for USB 2.0?  IIRC, that is a fixed clock protocol (vs spread spectrum) but it has been a LONG time since I've looked at USB at the data transport layer

[ray-dude]

 

I'm looking for the hqplayer readme file on my Audio Linux box and not finding anything in /usr/share/hqplayer/readme.txt

 

Does anyone know where audiolinuz expands this in the distro?  All the config files are where one would expect them to be, but I'm not finding the readme for some reason

 

Thanks!

[ray-dude]

Boom!  Thank you very much!!