Jump to content
IGNORED

Audiolinux Server configurations, Software, Hardware, and Listening Impressions


lmitche

Recommended Posts

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?

Link to comment
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):

  • Start and Enable RoonServer on A, then Start and Enable Squeezelite on Endpoint
  • Verify the Endpoint is visible
  • Run test
  • Stop and disable all running Audio Services on A, then on Endpoint
  • Start and Enable RoonServer on B, then Start and Enable Squeezelite on Endpoint
  • Verify the Endpoint is visible
  • Run test
Repeat until done.
Link to comment
On 1/7/2019 at 8:21 PM, 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

 

Hi Bob,

 

First of all, if you want to know the size of your Roon DB, just look at he size of the Database folder on your current Roon Core. The location of this folder is dictated by OS - see https://kb.roonlabs.com/Database_Location

 

Assuming the database is a reasonable size of under 4GB, say, the simplest option is to use the default Audiolinux Roon locations, which will put the database in the root partition (specifically in /var/roon), which will get loaded into RAM in ramroot mode. This is fine, and should fit easily on a 16GB machine. Make sure you do what @ray-dude suggested, and expand your root partition. On the other hand, keep in mind that any changes you make to your library will vanish on next boot, unless you:

  1. either diligently remember to do ramsave every time you change anything, or
  2. put the database on a persistent storage.

For 2, one option would be to put a 32GB Intel Optane NVMe SSD into the M2 slot. This does require a bit of script editing, as you have to edit fstab to mount the SSD automatically on boot, and tell the "start Roon Server" script to use a different location (on the Optane SSD) as the Roon database location. This isn't for Linux novices.

 

Hope this helps.

Link to comment
7 hours ago, Miska said:

 

Why would you have entire Optane just for the database and not running the OS from there?

 

Yes, that is the second part of the recommendation, but I didn't mention it as it does take a little bit of effort to set up, and a lot of people like the USB boot option for its simplicity.

 

Why Optane, and not just a regular NVMe SSD? Well, this whole AL/RAM/NUC experiment was driven by  many people observing that diskless units sounded better, when divested of SATA and NVMe storage devices (HDD and SSD). Larry, Roy, myself and others thought that Optane might be a good option to experiment with because:

  1. Optane has extremely low latency, and to the extent that the SQ benefits we hear with AL in RAM is due to latency, this would be beneficial
  2. Optane is electrically lower power than a standard NVMe SSD. 32GB of Optane consumes 2.5w when active and only 0.8w at idle.

Based on these, it was worth trying out. To my ears, the Optane drive adds no noise penalty to the server, while adding a very functionally useful persistence capability: both as a boot alternative to USB stick, and for Roon DB, LMS cache, etc.

Link to comment
6 minutes ago, bobfa said:

So do you put two Optane m.2 drives in the system Roon Server system?  

 

No need, Bob. One 32GB Optane m.2 SSD is plenty to store your AL OS, and your Roon DB.

 

It does take some steps to boot from Optane. You have to create / and /boot partitions and dd over the contents from the USB disk.

 

Maybe @hifi25nl would publish a procedure to do so?

Link to comment
31 minutes ago, lmitche said:

Rajiv,

 

Nice report and lots to think about here.  Off hand, it would be interesting to have you set the NIC on the NUCI7DNXX to 10 mbps and compare that to the TLS-DS1 box both running Roonbridge.

 

Yeah, that might be worth a try... but not sure when/if I'll get to it. I've been playing around with AL so much the past month that I've promised myself to buckle down and finish a couple of reviews that are pending.

 

One thing I did notice before I set it aside is that even in the SL case, the size of the "firehose" was different between my Dell server running AL/RAM, and my Dell laptop running W10. Whereas the desktop firehose was 200+ Mbps, the W10 laptop seemed to top out at about 50 Mbps between Roon server and the i7 endpoint.

 

So yes, perhaps this explains why I still hear a difference between the 2 servers on SL. But this is of course just a theory that the network throughput between Roon Server and SL endpoint IS the cause of the SQ difference.

 

I really can't devote time to this experiment for a few weeks. If anyone else wants to experiment, I would be very interested.

 

31 minutes ago, lmitche said:

I recently terminated my own Cat 6a Ethernet cables. OMG, they sounded great. Later I realized I'd screwed up, and crossed wires meant the cable was running at 10 mbps.

 

They have been left that way, but now I'm running wireless so don't use them.

 

More to come.

 

Intriguing! Keep us posted.

Link to comment
3 minutes ago, BigAlMc said:

 

Interesting stuff Rajiv and looking forward to those reviews.

 

Meantime any commentary on the difference in SQ of using Roon Bridge vs Squeezelite with large buffers on the same Roon server?

 

Put simply is it worthwhile for me to open my Endpoint, add another 4gb of RAM (which I have anyway) and try the large buffer size in the Squeezelite endpoint?

 

Thanks,

Alan

 

Very worthwhile! I’ve described the improvement on the novel thread.

 

i assume you’ve tried the new “experimental” feature on your SE? This is the same thing.

Link to comment
7 minutes ago, BigAlMc said:

Thanks Rajiv,

 

Yup, I tried that on the SE.

 

Knew it used an SL endpoint but didn't realise it was also large buffers. Didn't think the SE had a lot of RAM.

 

I played around last weekend, made progress but ultimately unsuccessfully, at trying Ray-Dudes instructions.

 

Guess I'll reach for the screwdriver and some Putty later this morning 🙂

 

Cheers,

Alan

 

Nuno’s the one who I credit for the idea of running with large buffers. We just replicated their results in the NUC endpoint.

 

Yes, the SE has 8GB RAM.

Link to comment
1 hour ago, BigAlMc said:

 

Fell at the first hurdle. The Endpoint won't boot on the LPS-1.2 with both 4GB ram sticks in it.

 

Considering buying an 8GB stick on the assumption that one 8GB stick uses less power than 2 x 4GB sticks. Its 1.2v per stick, right?

 

Cheers,

Alan

 

6 minutes ago, seatrope said:

I had no luck booting with 1x 8GB stick, Alan. You might have luck with the appropriate 8GB stick selected for low current but it’s borderline even with 4GB on a LPS1.2 for me.

 

Guys, I just checked the DS-1. it does indeed have 2 x 4GB SODIMMs.

  • Quick aside: I installed the dmidecode utility (pacman -S dmidecode) to get detailed info about the HW on the box. Try it - for those inclined to.

I am able to run with an LPS-1.2. I can think of 2 reasons:

  • have you done all the low power tunings in the BIOS? As well as turning off all the unused things? 
  • What is downstream of the endpoint? The current draw of the USB device can be the biggest factor in whether the LPS-1.2 can handle the load.
  • Alan, are you using your tX-USBultra? That is what I have. This should effectively shield you from whatever the current draw is from the downstream DAC.
  • For the moment, my downstream DAC is the Ayre QX-5 Twenty, which is not bus powered, so its current draw is very low.
Link to comment
31 minutes ago, BigAlMc said:

Hi Rajiv,

 

Nope, not using the tx-usbultra at the moment so I guess that's an option. But brings other questions into play as I'd need to power it with the spare LPS-1 I kept 'just in case' 🙂if i want to keep the LPS-1.2 on the NUC.

 

Putting a lesser able PSU closest to the DAC seems counter intuitive. Its also a backwards step in terms of the old spaghetti conundrum. Not ruling it out but needs some thought.

 

If your tX-U and LPS-1 are gathering dust, then why not just try it? It'll at least tell you if 8GB will work. That will confirm the theory that whatever is downstream of your NUC was drawing more current than a tX-U does.

 

Then first listen without changing to SL (i.e. with Roon Bridge). Did it degrade the sound? Then fire up SL, and see what you think. No one has the answers. You just have to try it and decide for yourself. :)

Link to comment
13 minutes ago, LTG2010 said:

The database is at: /var/roon/RoonServer/Database

Just copy it over to the new disk that would be the easiest method, or even copy over /var/roon/RoonServer

 

Excellent advice. Just copy over everything under /var/roon and you'll have retrieved all your Roon data. Then trash the old stick and get on with life. Life's too short to nurse an ailing USB stick, trust me.

 

😛

Link to comment
2 hours ago, bobfa said:

@hifi25nl Any ideas?

 


😕I am back working on bridging.  I have the 7i7 NUC in the Akasa case and I have the NUC network interface and a Microsoft USB network interface.  When setup without bridging the two interfaces seem ok:

 

NOTE that this is with both network cables connected to the router.

 

audiolinux@FairRoon ~]$ networkctl

IDX LINK             TYPE               OPERATIONAL SETUP     

  1 lo               loopback           carrier     unmanaged

  2 enp0s31f6        ether              routable    configured

  3 enp0s20f0u4      ether              routable    configured

 

 

But when I run the bridge script in the AudioLinux menu the bridge never comes up all the way.

 

SOOO 

 

I build a new USB stick with 0.9. updated the menu to 091 and tried again.  I get the following after I run the menu item to bridge the networks

 

 

 

networkctl

IDX LINK             TYPE               OPERATIONAL SETUP     

  1 lo               loopback           carrier     unmanaged

  2 enp0s31f6        ether              routable    configured

  3 enp0s20f0u4      ether              routable    configured

  4 bridge0          bridge             no-carrier  configuring

 

 

Now If I move the second network cable to only connect to my endpoint things look like this

 

networkctl

IDX LINK             TYPE               OPERATIONAL SETUP     

  1 lo               loopback           carrier     unmanaged

  2 enp0s31f6        ether              routable    configured

  3 enp0s20f0u4      ether              degraded    configuring

  4 bridge0          bridge             no-carrier  configuring

 

When I reboot I get this:

 

networkctl

IDX LINK             TYPE               OPERATIONAL SETUP     

  1 lo               loopback           carrier     unmanaged

  2 bridge0          bridge             no-carrier  configuring

  3 enp0s31f6        ether              routable    configured

 

The second adapter disappears.

 

I am stuck. I am going to reboot one more time and then try the older Apple USB to ethernet adapter.

 

 

 

Bob

 

Bob,

 

Not sure why the 0.91 script didn't work. There was a bug in the 0.9 version (missing file) that Piero fixed.

 

Anyway, this is not that hard. You can just do it manually. You want to have the following files in /etc/systemd/network:

bridge0.netdev  bridge0.network  enp0s31f6.network  enp0s20f0u4.network

 

Contents of the files are:

 

bridge0.netdev

[NetDev]
Name=bridge0
Kind=bridge

 

bridge0.network

[Match]
Name=bridge0

[Network]
DHCP=yes
 

enp0s31f6.network

[Match]
Name=enp0s31f6

[Network]
Bridge=bridge0

 

enp0s20f0u4.network

[Match]
Name=enp0s20f0u4

[Network]
Bridge=bridge0

 

As root, edit/create the above files as root, then run:

systemctl restart systemd-networkd

 

Link to comment

On my machine, after successful bridging, this is the output of networkctl:

 

IDX LINK             TYPE               OPERATIONAL SETUP
  1 lo               loopback           carrier     unmanaged
  2 bridge0          bridge             routable    configured
  3 eno1             ether              degraded    configured
  4 enp0s20f0u2      ether              degraded    configured

Link to comment
57 minutes ago, lmitche said:

Hi Paul,

 

I have no problem with Piero creating optional capabilities to enhance SQ as long as these capabilities don't interfere with existing SQ. Audiolinux has many "tweak-able" settings that I never use. That's cool, as long as they don't get in the way.

 

FYI, I don't plan to test the CPU task pinning functions offered in the new release. If someone else finds it makes a big impact, I may change my mind. In the meantime I'll ignore it unless it impacts SQ with my preferred configuration.

 

Piero has delivered six to eight releases since August and from my perspective has done a great job testing each release. I can't think of a single release where his testing has been a show stopper in any way.

 

As a software company professional, I can say that maintaining multiple releases in the field gets exponentially complicated and is a major burden over time. I'd hate to place that burden on Piero.

 

I’m with you there, Larry. I’m not motivated to try this new feature, but am certainly interested to hear others’ experiences with it.

 

I’m not sure what SQ considerations motivated @hifi25nl to deliver this capability, since it did not originate in this forum. Maybe if we knew more, it would increase our interest.

 

I am very happy with AL as it is now. If anything, I would advise the focus shift to usability and maintainability, but that’s just my opinion.

Link to comment
  • 2 weeks later...
18 hours ago, lmitche said:

A bit over a year ago most of us were firmly in the “one box” camp. Positive reviews of the Innuos Zenith MKII SE seemed to confirm the “one box” approach and raised my curiosity to learn how this was done. Later, looking at a pictures of the internals, the answer became obvious.  Innuos was using two separate regulators to power the CPU (EPS) and the motherboard (24 pin ATX) of one motherboard. Using a 19 volt Hdplex 250 watt DC to DC power supply for the 24 pin ATX, and by jumping the pins on my EVGA 1600 watt Titanium ATX SMPS to enable the 12volt CPU (EPS) output, a similar dual power scheme was achieved here. This yielded an impressive increase in SQ.

 

This past August the NUCs arrived. The early thinking was that this new two box solution meant that along with network isolation between the server and endpoint side, “bits would be bits”, and therefore server (dirty) side tweaks no longer mattered. The network isolation would shield the clean from dirty. With this idea in mind, a wifi network isolation scheme was configured here. Later the dual power scheme described above was dismantled with the big EVGA power supply used once again for both motherboard ATX and CPU power.

 

In December of last year the big 200 watt Hdplex arrived. This is the first linear power supply here with the capacity to power a CPU at close to a 100 watts. The separate 12 volt 10 amp rail, and 19 volt 10 amp rail enables many possible dual rail/supply power schemes. Remember the server and endpoint are connected via wifi.

 

Here is what I tested with observations.

 

  • EVGA 1600 Watt ATX to 12 volt CPU(EPS), Hdplex 19 Volt rail to Hdplex 250 watt DC to DC for 24 pin ATX power

Notes: So much for the dirty/clean side idea, this sounds much better then EVGA alone. Image density has increased in the mid-range.

 

  • Hdplex 19 Volt rail to Hdplex 250 watt DC to DC for 24 pin ATX power and CPU(EPS) 12 volt

Notes: Nice high end density, but the low mid image density and bass seem diminished.

 

  •  Hdplex 19 Volt rail to Hdplex 250 watt DC to DC for 24 pin ATX power, Hdplex 12 Volt rail to CPU(EPS)

Notes: this is the one, improved image density almost 3d, big depth increase and improved ambience, just spine tingling!

 

It is likely that another Hdplex will find it’s way here in the next few months. I am anxious to test again with two separate LPSUs.  In the meantime, the last configuration is the most musical presentation heard here.

 

It should be said that in the final configuration, the 12 volt Hdplex output is used for powering the CPU.  This eliminated the possibility of powering my 12 volt network extender with the Hdplex so another 12 volt power supply was used for this purpose. Hence, two things were changed at once. It is possible that the second configuration was compromised with the wifi extender power connection.

 

Thanks to @Rickca for inspiring this effort.

 

Thanks for the findings, Larry.

 

Please bear with me, as I'm not too adept at system building, and the whole ATX specification. So if I understood correctly:

  1. the 24-pin ATX connector carries essentially 3.3V, 5V, and 12V -- all derived from the 19V rail using the regulators in the HDPlex DC-DC ATX converter
  2. the 8-pin EPS connector to the CPU is from the independent 12V rail?

In that case, I wonder if the HDPlex 400W LPS, for a couple hundred more than the 200+DC-ATX, might deliver even higher SQ? The reason I phrase this as a question is that I asked Larry @ HDPlex whether the ATX outputs on the back of the HDPlex 400 were from independent rails. His answer was:

"400W ATX LPSU has four independent rails from transformers to support 19V 12V 5V and 3.3V. XLR shares those four rail with ATX output."

 

So I would interpret that as being that:

  1. the 3.3V, 5V, and 12V in the 24-pin connector are from different rails - hopefully a good thing
  2. however, the 12V in the EPS connector and the 12V in the 24-pin connector share the same 12V rail. A bad thing? Who knows!

So the question in my mind is if the HDPlex 200 with the split 12V rail config you used better, equal, or worse than using the big brother 400W Linear ATX PSU.

 

Please correct me if I'm way off base here.

Link to comment
2 minutes ago, rickca said:

t's not clear whether the better SQ Larry is reporting with his preferred configuration is due to using an independent 12V rail from the 200W LPS for the EPS12V or due to differences between the 12V supplied by the 200W LPS vs the 250W  DC-DC.

 

Thanks Rick - that's a very reasonable point. We won't know until someone tries both.

 

Since this has been declared OT by the OP, I'll hold further comment.

Link to comment
  • 2 weeks later...
  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...