Audiolinux Server configurations, Software, Hardware, and Listening Impressions

14 minutes ago, jbparrish said:

 

 Hi Larry, 

 

this seems to be a significant complement for the IFI black. I recall you owned one for sometime before your current DAC. It sounds like a really nice alternative for a lower priced DAC that plays well in this environment and can be powered by the also less expensive LPS 1.2. Is that about right?

 

Thanks for all the intense research into this so very interesting subject.

 

John

John, I think you are referring to my ownership of the original microIDSD DAC prior to owning the Black Label. The Silver IFI DAC replaced two ESS based DACs, an Auralic Vega and a Mytek Brooklyn. Upsampling with Hqplayer to DSD512 with the microIDSD beat both of these much more expensive DACs. Now, I am not upsampling at all and the BL sounds great. The RME DAC has a terrific feature set, but I just couldn't get it to the same level. It was a relief to reinstall the IFI and hear that the musicality was still there.

With a Lush cable and three lps1.2s powering the NUC, ISO Regen and Vbus to the DAC it is not an inexpensive solution, but it sure delivers.

2 hours ago, lmitche said:

John, I think you are referring to my ownership of the original microIDSD DAC prior to owning the Black Label. The Silver IFI DAC replaced two ESS based DACs, an Auralic Vega and a Mytek Brooklyn. Upsampling with Hqplayer to DSD512 with the microIDSD beat both of these much more expensive DACs. Now, I am not upsampling at all and the BL sounds great. The RME DAC has a terrific feature set, but I just couldn't get it to the same level. It was a relief to reinstall the IFI and hear that the musicality was still there.

 

With a Lush cable and three lps1.2s powering the NUC, ISO Regen and Vbus to the DAC it is not an inexpensive solution, but it sure delivers.

Thanks Larry, you’re right I didn’t quite understand the history of all this correctly,  so thanks for clarifying that. But I find it very intriguing to hear that the iFi micro DSD black performs so well. You’re also correct in saying that all told it’s not inexpensive, but it is also by no means a cost-no-object system and yet it sounds like one, or I at least enough like one to fool me.  I will be curious to hear what you have to say about adding HQ player back into the mix,  assuming you get around to doing that!

Best regards 

Thank you Larry @lmitche for starting this thread, I believe I can move over here instead of posting on the HQP and NAA and Novel SQ threads, this can be the specific thread alternative for hardware tinkering.

I have seen your posts here and there before and I wanted to ask you something (which I believe the answer is YES but just confirming)

Before using AL were you using custom Ubuntu install with @Miska s boot image? if so then you consider AL to be better suited for Server+NAA combination than of the shelf Linux running custom kernel, packages etc. because of the nature of AL itself? I'm curious to know the answer?

If you don't mind I will try to contribute to this thread myself, I have a similar configuration like many of you and I have been gradually improving my system to the point it sounds nothing like it did before when I started, which brings me to another question, since you all already stated and confirmed that the server plays an important role in SQ (I know we cannot quantify that percentage of influence right now) wouldn't be advisable to run servers with low TDP at the expense of using simpler upsampling filters (HQP and ROON)? that would be another question what represents more in terms of SQ? a simpler filter with a low TDP server or a better more resource intensive filter on a high performance workstation? assuming the power supplied to such server is coming from a good SQ LPS in both cases.

I know you are undergoing drastic system changes and testing new hardware so it is hard to evaluate, I just moved from a house with GREAT high ceiling big spaces sound to a smaller place with low ceiling, even different tiled floors etc. and my system is completely different sounding so I lost my reference. I even replaced the tubes on my pre amp which changed all sound as well so I am trying to stabilize everything (I have new speakers coming in next week so I feel like running chicken without a head

Hi Luisma,

No, I have never run Ubuntu here.

My machine/OS history was an embedded processor J1900/AL back in 2013/14, then a i7-6700k system running Windows/Roon/Hqplayer,  and this past August the replacement of Windows with AL headless on the server and the addition of the NUC/AL headless endpoint.

Now, depending on the day, I may be running a Celeron, Pentium or I7 endpoint and/or a NUC i7 or i7-6700k server. I expect to replace the i7-6700k and z270 with a modern coffee lake and related motherboard in the next few weeks.

Having run Hqplayer for many years, I am surprised that Roon running in native mode sounds so good. In that period the Roon people were clearly enhancing their product and it delivers.

So, at least at the moment, I'm running a low tdp NUC endpoint and a high tdp server configured in low tdp mode, all bit perfect in Roon. 

I don't know where things will take me next. I hope this answers your questions.

Please do contribute to this thread. It going to be pretty boring if I'm the only poster.

Larry

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

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)

14 hours ago, lmitche said:

No, I have never run Ubuntu here

Thanks for the reply, I am currently running Ubuntu so don't really know (unless I try it) if AL represents an improvement, somehow I got the feeling it should not but you never know unless you try  

14 hours ago, lmitche said:

I am surprised that Roon running in native mode sounds so good

Well let me start saying I don't consider myself one of Jussi's "groupies" but his product is definitely outstanding and my ears will prefer it over Roon's for some margin.

14 hours ago, lmitche said:

So, at least at the moment, I'm running a low tdp NUC endpoint and a high tdp server configured in low tdp mode, all bit perfect in Roon. 

Well said, and seems the high TDP server configured with low TDP settings might create some differences, I'm planning on keep running HQPE but with not so intensive filters and with low TDP settings like you are doing, I agree Roon filters are even less intensive in CPU usage than HQPE. Also filters will affect more the CPU if upsampling DSD256 than upsampling PCM 384 by a lot and I prefer DSD upsampling myself.

Thank you again

Will try to post a schematic of my system now and my system in 1 / 2 weeks from now with the new speakers etc. it will help to keep everything track for the forum and my own purposes.

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.

24 minutes ago, austinpop said:

 

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.

Rajiv,

Thanks for the note. 

Running Roon in RAM is interesting.  I was thinking of a chron job to "ramsave" a couple of times a day.!  I will run this step by step with the music on my NAS and see where it goes vs my Sonic Transporter. I have to finish building the new USB stick when I am fresh in the AM.  

Then maybe AL on the Sonic Transporter although it only has 8GB of RAM and the BIOS is not as management friendly as the NUCs are.   

I have to round out the server side with a TLS switch (someday UpTone Audio) and updated power supply (HDPLEX 200) which are both on order.   I hope that this is helpful to the community.  I do not want to go over ground that is settled.

Bob

Audiolinux has already a ramsave periodic option.

You can start/enable it (as root) with the commands

systemctl start ramsave.timer

systemctl enable ramsave.timer

The default is every 30 min. You can change it editing the /etc/systemd/system/ramsave.timer

5 hours ago, austinpop said:

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.

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

On 1/6/2019 at 6:24 PM, luisma said:

Before using AL were you using custom Ubuntu install with @Miska s boot image? if so then you consider AL to be better suited for Server+NAA combination than of the shelf Linux running custom kernel, packages etc. because of the nature of AL itself? I'm curious to know the answer?

My bootable images are not related to Ubuntu in any shape or form. And they are not off the shelf Linux either, but completely custom built. AudioLinux is based on ArchLinux (?) AFAIK, so it is closer to off the shelf Linux than my bootable images?

In addition to my "HQPlayer OS" images, I provide HQPlayer Embedded packages for Ubuntu, Debian and Fedora distributions.

On 1/6/2019 at 6:24 PM, luisma said:

since you all already stated and confirmed that the server plays an important role in SQ (I know we cannot quantify that percentage of influence right now) wouldn't be advisable to run servers with low TDP at the expense of using simpler upsampling filters (HQP and ROON)? that would be another question what represents more in terms of SQ? a simpler filter with a low TDP server or a better more resource intensive filter on a high performance workstation?

Depends how much you are trading on the filters. By using -2s filters you are not practically losing anything. While bigger changes have drastic and measurable differences in the DAC output. With a good DAC, server has very small or no impact on DAC output.

I rather use high power server to run all the DSP and then low power NAA for connecting to the DAC when the DAC connection is sensitive.

On 1/6/2019 at 12:08 AM, lmitche said:

1) An audition of an RME ADI2 DAC has been underway powered by various LPSUs. This DAC was tested powered by the Hdplex 200 watt lt3045 output at 15 volts, a Sigma 11 at 12 volts, and the UpTone JS-2 at 12 volts. The RME needs too much current to be powered by the LPS1.2. An I7 NUC/AL server endpoint pair running Roonserver/Roonbridge or Roonserver/Hqplayer embedded/NAA were used to test both bitperfect and dsd256 upsampled USB playback. The DACs single ended and balanced outputs were tested.

 

Operationally this DAC is really clean with no surprise pops or clicks in any mode or output. The JS-2 yielded the most musical results. Nevertheless the RME DAC never reached the dynamics and open sound of IFI microIDSD BL powered by an lps1.2. The DAC was returned to the vendor.

It works very well with the stock PSU too, that's how I use it.

Remember to switch on the DSD Direct mode in the DAC settings and send it DSD256 always! Then you can switch between 50 and 150 kHz DSD filters. Note that you cannot use the headphone connectors in DSD Direct mode.

You can also send there 768/32 PCM with fairly OK results. Also improves performance notably compared to the built-in 8x (352.8/384k) digital filter, just like with iFi micro iDSD too.

iFi micro iDSD has just annoying firmware bug, that when powered up/plugged in, you first need to shortly play either something from 44.1k to 384k PCM, or alternatively DSD, before switching to 705.6/768k output. Otherwise it behaves incorrectly with lot of distortion...

Larry, " I expect to replace the i7-6700k and z270 with a modern coffee lake and related motherboard in the next few weeks."  Really?  So interesting!  TBH, I'm surprised still to hear again that an i7 NUC sounds better than our super tweaked out pc's.  

Amazing progress in so little time

6 hours ago, Miska said:

 

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

Because we think that it might sound different.  Reasonably easy to test.  A 32GB optane M.2 NVME card is $62 on Amazon.  I am going to first run in RAM and then try the Optane.  Then I will try it as a single box solution. 

I have two NUCs and a Sonic Transporter. Right now my systems design is Roon Server bridged to a 7i7 NUC running Roon Bridge and AL in RAM.  

The other combinations will be pretty easy to setup over time. 

I am getting Roon Core up on my second NUC running AL in RAM and then I can test a couple of combinations.  Still need switch in the system.

5 hours ago, Miska said:

My bootable images are not related to Ubuntu in any shape or form. And they are not off the shelf Linux either, but completely custom built. AudioLinux is based on ArchLinux (?) AFAIK, so it is closer to off the shelf Linux than my bootable images?

Apologies, I mistakenly thought the  images were based on Ubuntu by exchanged emails and forums posting with you when I started using HQPE, that's why I decided to go with Ubuntu and your custom kernel. By off the shelf I was referring to Linux packages and kernels not Linux entire distributions.

So the bootable image contains HQPE I assume, or is it Linux HQP? maybe I would be better of running the bootable image which is already optimized

5 hours ago, Miska said:

Depends how much you are trading on the filters. By using -2s filters you are not practically losing anything. While bigger changes have drastic and measurable differences in the DAC output. With a good DAC, server has very small or no impact on DAC output.

 

I rather use high power server to run all the DSP and then low power NAA for connecting to the DAC when the DAC connection is sensitive.

That answers my question about the server then, when you say "good DAC" I guess it means the AC power supplied and circuit quality and design inside the DAC, not so much the actual DAC upsampling capablities.

23 minutes ago, bobfa said:

 I am going to first run in RAM and then try the Optane.  Then I will try it as a single box solution. 

 

You could also boot into ram from the optane drive and store the roon database there, eliminated the need for plugging in and taking out usb drives. (unless thats what you mean by single box solution )

55 minutes ago, bobfa said:

Because we think that it might sound different.  Reasonably easy to test.  A 32GB optane M.2 NVME card is $62 on Amazon.  I am going to first run in RAM and then try the Optane.  Then I will try it as a single box solution. 

 

I have two NUCs and a Sonic Transporter. Right now my systems design is Roon Server bridged to a 7i7 NUC running Roon Bridge and AL in RAM.  

The other combinations will be pretty easy to setup over time. 

 

I am getting Roon Core up on my second NUC running AL in RAM and then I can test a couple of combinations.  Still need switch in the system.

I would like hear why it would make difference? Running software runs from RAM in any case (loaded to RAM before executing it). For example if you send data to HQPE from Roon, UPnP or digital inputs, HQPlayer doesn't access filesystem unless you have log file (which usually goes to RAM disk) enabled, or you use it's web interface with browser. Even this activity is cached in RAM by the OS, so it doesn't really access the media much.

With Roon, the most accessed file system items are the database and music files. The application itself sticks in the RAM once started. Both database and content are cached/buffered by the OS for reads. Writes are periodically flushed to the storage. OS automatically uses all otherwise unused RAM as buffer/cache. However, if you run the software from RAM disk, you increase memory usage by storing lot of unused data in RAM, which in turn reduces amount of RAM available for caching and thus increases activity on the actual storage layer...

So if you run OS itself from RAM disk, but have content and Roon database on Optane SSD, you have the things that wouldn't be accessed anyway loaded in RAM at all times and the things that are the most accessed on Optane SSD storage device. So probably entirely opposite to what you are looking for?

IMO, if you want to optimize price and reduce storage access, put the OS itself on regular M.2 SSD and then have another M.2 Optane SSD for the Roon database and other actively used stuff. And don't run the OS from RAM disk. This way you also have maximum amount of free RAM for caching/buffering purposes for Roon and thus least amount of storage activity.

For example when I'm playing content from local storage, the content ends up being cache in RAM pretty soon by the OS and storage activity stops. Since I have 16 or 32 GB of RAM and the OS and software itself consume very little.

For example on my Ubuntu Studio workstation (with graphical desktop), while writing this, I have following statistics:

porkkala:~> free -m
              total        used        free      shared  buff/cache   available
Mem:          32075        2642       11904         143       17528       28867
Swap:             0           0           0

porkkala:~> vmstat -s
     32845704 K total memory
      2706532 K used memory
      4283428 K active memory
     15178456 K inactive memory
     12186100 K free memory
     15894388 K buffer memory
      2058684 K swap cache
            0 K total swap
            0 K used swap
            0 K free swap

P.S. I never have any swap active/existing on any of my Linux computers. It is totally unnecessary thing these days.

6 hours ago, Miska said:

 

It works very well with the stock PSU too, that's how I use it.

 

Remember to switch on the DSD Direct mode in the DAC settings and send it DSD256 always! Then you can switch between 50 and 150 kHz DSD filters. Note that you cannot use the headphone connectors in DSD Direct mode.

 

You can also send there 768/32 PCM with fairly OK results. Also improves performance notably compared to the built-in 8x (352.8/384k) digital filter, just like with iFi micro iDSD too.

 

iFi micro iDSD has just annoying firmware bug, that when powered up/plugged in, you first need to shortly play either something from 44.1k to 384k PCM, or alternatively DSD, before switching to 705.6/768k output. Otherwise it behaves incorrectly with lot of distortion...

 

My mistake, I did indeed listen to the stock smps, and you are right,  not bad.

I did indeed try direct dsd256 with good results.

I'm thinking the ifi performance over the RME is due to the the lps1.2 and its fast response to current demand. Unfortunately the RME would not run with the lps1.2.

Yes, that firmware bug on the ifi is annoying and is the reason I'm shopping for a new dac.

45 minutes ago, LTG2010 said:

You could also boot into ram from the optane drive and store the roon database there, eliminated the need for plugging in and taking out usb drives.

Yes, if the Optane is anyway active, there's no reason to not use it...

3 minutes ago, lmitche said:

I'm thinking the ifi performance over the RME is due to the the lps1.2 and its fast response to current demand. Unfortunately the RME would not run with the lps1.2.

For long time I've wanted to try a Teddy Pardo PSU on many things, but never got far enough to order one... This one looks interesting:

https://www.teddypardo.com/powersupplies/teddy12-4.html

30 minutes ago, Miska said:

 

Yes, if the Optane is anyway active, there's no reason to not use it...

 

My servers all ram boot the AL OS from a 32gb Optane stick. This is especially fast with Optanes crazy sequential read speeds.

At startup the Roon scripts are pointed to an Optane based Roonserver software and database in a separate optane partition. This way any database or software update is stored in non volatile memory. Everything else runs in ram. Music is either fed from a nas or external usb disk.

For the traffic generated by roon, optane is ideal as it is the fastest nonvolatile memory available for short bursty traffic.

We could debate why a ram disk based OS sounds better then a demand paged OS all day long. For most of us it just does, and we don't know why.

With AL it is trivial to test this one way or another just by turning ramboot on or off at boot when the yes or no question  is asked so people can have at it.

I still prefer zero nonvolatile storage in the endpoint, so the Usb stick boot and remove method or iscsi boot from server is preferred. Unfortunately Iscsi over wifi is unavailable, so the latter only works with wired connections. Iscsi will be revisited once the ether regen arrives.

56 minutes ago, luisma said:

Apologies, I mistakenly thought the  images were based on Ubuntu by exchanged emails and forums posting with you when I started using HQPE, that's why I decided to go with Ubuntu and your custom kernel. By off the shelf I was referring to Linux packages and kernels not Linux entire distributions.

OK, the bootable image is not related to Ubuntu or normal distro packages. It is Linux thing custom built from source code.

I run two servers with Ubuntu Server 18.04 (low-TDP Core i5 machines built by me), one with Debian 9 (Core i5 NUC) and one with Fedora Minimal 29 (Logic Supply CL100). All headless servers without any graphical stuff installed or monitor connected. All these run HQPlayer Embedded.

In addition I have various things like the UpSquared running my HQPlayer OS image. And I also test the HQPlayer OS image on NUC 7i7BNH, but don't normally use it there (loud fans).

Choice of the OS mainly depends on what exactly one wants to do. If you for example want to install Roon things on the same machine, then HQPlayer OS is not the right choice, because it doesn't have many things needed by Roon, and it is quite hard to add those afterwards.

1 hour ago, luisma said:

So the bootable image contains HQPE I assume, or is it Linux HQP?

It is HQPE, it doesn't have any graphics things or such, intended for headless systems. It does have some command line utilities to allow small adjustments and checking system details if one wants to. But it doesn't have full-blown command line capabilities even. It doesn't have any package management things either. It is supposed to be more like "device firmware", not a regular OS. You "flash" it to a device and go, that's it.

NAA images share the same core OS, but they have even less software components, because NAA needs almost nothing.

Thank you, I understand now, I have Roon and HQPE running along on the same server 18.04 NUCi7 and Roon Bridge / NAA on Celeron with 18.04.

I am going to try the bootable image as well to see if there are any differences (at least noticeable) on SQ