Audiolinux Server configurations, Software, Hardware, and Listening Impressions

Prior to the NUC/Audiolinux exercise in the second half of 2018, many of us used a one box solution.  Now that we can hear the benefits that a NUC based endpoint brings to the table, what is the best server configuration to optimize our SQ?

Edit:

As Rajiv rightly points out below, the initial response to the SQ benefits of the NUC endpoint was that the server tweaks no longer mattered. With time, we have learned that server tweaks are as important as ever. The reality is that the NUC endpoint just moved the baseline in one big step, and despite using various isolation techniques between the dirty and clean sides, additional SQ gains can be made on the server side as well.

Great thread!

I am running AL extreme on three m/c - NUC7i7DNHE as streamer, home built 4th gen i7 fanless PC as server and mini-itx based switch housing JCAT net femto in bridged mode. I tried a NUC8i7BEH for up-sampling but it couldn't keep up with dsd256. My plan is to upgrade my server to something newer. Also LMS/Squeezelite in server/endpoint mode has given a great boost to SQ as well.  

1 hour ago, lmitche said:

First off, my music is stored on a 3.5 inch hard disk enclosure containing a 4tb WD hard disk. I have powered it with a Sigma LPS and 3 amp MPaudio lt3045 dc to dc regulator set to 12volts.  Today I pulled the Sigma 11 and replaced it with one of the Hdplex LT3045 rails. So now with dual regulation a new level of SQ was achieved with yet another increase in dynamics and realism.

I'd like to understand this dual regulation.  You are using an adjustable HDPLEX LT3045 rail followed by the 12V MPAudio MS-HPULN, is that correct?  At what voltage do you have the HDPLEX rail set?  I'm not sure I get how this dual regulation works.

Good idea to use the other HDPLEX LT3045 rail for networking gear.  How were you powering your wireless extender before?

2 hours ago, rickca said:

I'd like to understand this dual regulation.  You are using an adjustable HDPLEX LT3045 rail followed by the 12V MPAudio MS-HPULN, is that correct?  At what voltage do you have the HDPLEX rail set?  I'm not sure I get how this dual regulation works.

 

Good idea to use the other HDPLEX LT3045 rail for networking gear.  How were you powering your wireless extender before?

By dual, I mean two serial connected regulators. In this case the Hdplex has one, set at 15 volts, followed by the MPaudio set at 12 volts. Make sense?

The wireless extender was powered by a Sigma 11 previously.

1 minute ago, lmitche said:

In this case the Hdplex has one, set at 15 volts, followed by the MPaudio set at 12 volts.

OK good that's what I expected.  So dropping it 3V between the HDPLEX and the HPULN doesn't generate too much heat?

10 hours ago, rickca said:

OK good that's what I expected.  So dropping it 3V between the HDPLEX and the HPULN doesn't generate too much heat?

After a cold startup with Roonserver scan the heatsinks are barely warm to the touch.

Can AL for Raspberry Pi (3 B+) meanwhile run in RAM? Thanks, nbpf 

Bringing over from the troubleshooting thread...

11 hours ago, ray-dude said:

Rajiv, my critical listening stamina is (way) at an end for the day, but I ended up with LMS on both my server NUC (all music files local and in RAM) and LMS on my MacBook Pro (WiFi, accessing files from my Mac Mini file server)  These are basically my best/worst case configs, without having to worry about Roon authorization switching.

 

To make swapping back and forth easier on the end point, I'm specifying the server IP in the command line for squeezelite:

 

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

 

Lets me swap back and forth in the start up time for squeezelite (<10 seconds).

 

There is enough network chatter going back and forth between server and endpoint (status stuff) that I'm also experimenting with kill LMS on the NUC and LMS on the MacBook Pro to see if I can detect any delta in SQ.

 

My ears are cooked, so I'm going to revisit things tomorrow with a fresh set of ears.  Looking forward to hearing about what you're hearing!

 

 

I did some comparisons last night, and I think you are on to something. However, I want to do some more listening (with fresh ears) before describing any findings. That won't be until tomorrow. If you do any listening comparisons in the meanwhile, please post your impressions on this thread.

Folks - would anyone else like to try this listening test? The hypothesis is that if you are running squeezelite with large buffers on the endpoint, then the difference in SQ between server configs essentially disappears, i.e. the contribution of the server to overall SQ is small to 0.

You can do this experiment either by running LMS on the server - reliable, consistent - or Roon Server - buggy, glitchy. Either way, the question is - if you compare 2 servers that you previously thought sounded different (with Roon Server/Roon Bridge for example), does this difference still manifest itself in the squeezelite case?

1 hour ago, austinpop said:

You can do this experiment either by running LMS on the server - reliable, consistent - or Roon Server - buggy, glitchy. Either way, the question is - if you compare 2 servers that you previously thought sounded different (with Roon Server/Roon Bridge for example), does this difference still manifest itself in the squeezelite case?

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.

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.

56 minutes ago, ray-dude said:

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.

 

There is a theory that memory is capable of storing the characteristics of the music signal, therefore once buffered it will play back what's stored, therefore if you disconnect the source there should be no big impact, unless you change something on the output side.

The problem is when we make a change to the source, in this case the server, reconnect and start up again can we remember clearly enough what the sound was like prior to that change? I don't think I'm skilled enough to do that unless the change and output are simultaneous.

For example I'm easily able to ascertain the subtle difference between, switching USB outputs from my PCIE card, Motherboard USB, re - clocking board, etc, which are pretty instantaneous. But when changing server to endpoint which requires re - organizing and a reboot, I'm struggling a bit to remember - my buffers are not so good

34 minutes ago, LTG2010 said:

There is a theory that memory is capable of storing the characteristics of the music signal, therefore once buffered it will play back what's stored, therefore if you disconnect the source there should be no big impact, unless you change something on the output side.

The problem is when we make a change to the source, in this case the server, reconnect and start up again can we remember clearly enough what the sound was like prior to that change? I don't think I'm skilled enough to do that unless the change and output are simultaneous.

For example I'm easily able to ascertain the subtle difference between, switching USB outputs from my PCIE card, Motherboard USB, re - clocking board, etc, which are pretty instantaneous. But when changing server to endpoint which requires re - organizing and a reboot, I'm struggling a bit to remember - my buffers are not so good

The experiment I am proposing, which I did last night, and plan to do again tomorrow, does not require a reboot, and can be accomplished within seconds on A and B. This does not require your (human) memory buffer to wait multiple minutes between comparisons!

The experiment is to compare 2 servers A and B driving an identical endpoint, E. In my case:

• A = my Dell XPS 8700 i7-4770 box
• B = NUC7i7DNBE
• E = TLS DS-1

with all of these running AL in RAM.

For me, the baseline comparison was Roon Core on A and B, and RoonBridge on E. Switching cores is easy: go into settings, and click on the Core to bring up a list of Cores on the network, then select the other Core, and listen. Switch back and forth.

Here, I can clearly tell that A driving E sounds different than B driver E. Make sense so far?

So the new experiment is to run squeezelite (with large buffers - either my settings ,or Ray's settings) on E. You don't need more RAM. My settings ( -b 2097152:2097152 -a 52428800:4::) require 4GB of memory consumption, and fits comfortably on my 8GB endpoint.

You can drive E running squeezelite with either LMS or Roon Core on A and B. If you do LMS, then it is again very easy. Use the web UI to control LMS (not iPeng or another mobile app).  Squeezelite by default always attaches to one LMS instance. Say it's connected to LMS A. Play your test track on LMS A and listen. Now go to the web UI of LMS B. On the top right, pull down to select the squeezelite instance. It will prompt to ask if you want to connect LMS B to it. Say yes. Now play back your test track on B. Listen. Rinse and repeat.

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. Probably the best way to do this would be (type menu, then select Configuration):

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)

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.

45 minutes ago, ray-dude said:

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)

Ok I tried to move to where you guys are going.

Keeping it simple using NUC7i7DNHE with 12V linear power supply, 8GB RAM, Squeezelite with austinpop's settings, endpoint in both cases.

Using an Acer predator laptop windows 10, with standard SMPS running Roonserver and then switching over to my sclk-ex server with multi rail linear power supply again running audiolinux /Roonserver.

There was a short pause to get the switch over, unauthorized one machine, stop and restarted squeezelite to get it recognized.

Started with Laptop, sound was really good better than expected, so the buffers are having an impact, cutting to the chase:

The sclk-ex server sounded bigger, warmer, more natural, larger soundstage, greater dynamics and bass punch - this was easily discernible even for my own poor buffer's.

I guess there is something about buffers capturing the essence of the sound in this case. I hope this helps and look forward to reading Rajiv's experiments which will be much better prepared and detailed.

3 hours ago, LTG2010 said:

The sclk-ex server sounded bigger, warmer, more natural, larger soundstage, greater dynamics and bass punch

Similar impact here with additional server side enhancements.

OK, so I had a long listening session with the new Hdplex 200 watt LPS and a I7 NUC server today. This report is based on testing done with Roonbridge and Roonserver.

One Hdplex LT3045 output was used at 15 volts to the HPULN and disk enclosure. The wifi extender on an entirely different LPS, left me free to power the NUC with either the Hdplex LT3045 at 15 volts or easily switch to the Hdplex 19 volt output.

Both sound great, but the 19 volt output was richer in a big way. An extended sound stage and image density was the result.

So I pulled the second LPS and powered the wifi extender directly from the second Hdplex lt3045 leaving the Hdplex powering everything. 5 rails creates a lot of flexibility.

SQ is terrific.

Would a more expensive LPS sound better ? Maybe, but this was a damn good, highly musical result. 

Later, I changed the NUC server power setting in the bios to low power just the I7 endpoint. This change delivered the best presentation I have ever heard of "Midnight Sugar" from the Three Blind Mice. Breathtaking.

So there you go! Any questions?

Larry

20 minutes ago, lmitche said:

Would a more expensive LPS sound better ? Maybe, but this was a damn good, highly musical result. 

 

Later, I changed the NUC server power setting in the bios to low power just the I7 endpoint. This change delivered the best presentation I have ever heard of "Midnight Sugar" from the Three Blind Mice. Breathtaking.

 

So there you go! Any questions?

 

Thanks for the details report. Am I correct in assuming you were using LPS 1.2 earlier with the NUC streamer and now changed to Hdplex 19v out ? Which one sounded better in your system ?

24 minutes ago, Dev said:

 

Thanks for the details report. Am I correct in assuming you were using LPS 1.2 earlier with the NUC streamer and now changed to Hdplex 19v out ? Which one sounded better in your system ?

Hi Dev,

My NUC endpoint has been powered by the LPS1.2 long before the Hdplex arrived. The LPS1.2 is the best sounding power supply I have used on the endpoint.

The report above was about powering the server and related peripheral devices. The 4 multi-rail outputs of the Hdplex 200 watt lps are perfect for this.

Thanks,

Larry

1 minute ago, lmitche said:

Hi Dev,

 

My NUC endpoint has been powered by the LPS1.2 long before the Hdplex arrived. The LPS1.2 is the best sounding power supply I have used on the endpoint.

 

The report above was about powering the server and related peripheral devices. The 5 multi-rail outputs of the Hdplex 200 watt lps are perfect for this.

 

Thanks,

 

Larry 

Ahhh...I see. Thanks for the clarification. I probably got confused when you said you changed the NUC power setting to low power and I thought you were talking about the endpoint.

Clarification - the Hdplex 200 watt lps referenced above has 4 output rails not 5.

1 hour ago, lmitche said:

Both sound great, but the 19 volt output was richer in a big way. An extended sound stage and image density was the result.

Very interesting.  I will have to compare the HDPLEX outputs myself.  I'm currently using the 19V for my router with very satisfying results.