Audiolinux Server configurations, Software, Hardware, and Listening Impressions

[bobfa]

 

-rw-r--r-- 1 root root   34 Jan 20 22:06 bridge0.netdev

-rw-r--r-- 1 root root   41 Jan 20 22:06 bridge0.network

-rw-r--r-- 1 root root   38 Jan 20 22:06 eno1.network

-rw-r--r-- 1 root root   45 Jan 20 22:06 enp0s20f0u3.network

 

[lmitche]

29 minutes ago, austinpop said:

What files are in /etc/systemd/network?

 

22 minutes ago, bobfa said:

 

-rw-r--r-- 1 root root   34 Jan 20 22:06 bridge0.netdev

-rw-r--r-- 1 root root   41 Jan 20 22:06 bridge0.network

-rw-r--r-- 1 root root   38 Jan 20 22:06 eno1.network

-rw-r--r-- 1 root root   45 Jan 20 22:06 enp0s20f0u3.network

 

BORING - either get a room or exchange email addresses. Debug your network bridge somewhere else!

 

Outcomes only please.

[bobfa]

Sorry.....

[austinpop]

15 minutes ago, lmitche said:

 

BORING - either get a room or exchange email addresses. Debug your network bridge somewhere else!

 

Outcomes only please.

 

Yeah, sorry!

[mourip]

On 1/14/2019 at 7:34 AM, hifi25nl said:

The script will disable hyper-threading after reboot with a kernel parameter. 

Yes it could work on 2 physical cores. 

 

It has been a long work, I have tested many ways to implement this. At last i have preferred a custom method more compatible with linux systemd  services and audiolinux menu system.

 

I am waiting for the results of user experimentation. I must find the time to listen myself...  

 

 

 

I have been thinking about your reply ever since you wrote it. 

 

I would first like to say that I have switched out both of my Roon endpoints to run AL in ramroot with no internal disks. I was able to pull out 4 SSDs by doing this. I also have now obtained SQ that is on a level with my Dante based system, which is in my mind an excellent achievement. For me AL SQ is not only excellent on an absolute level but is is also huge bang-for-the buck.

 

Now to my point. It is obvious that your involvement with AS(CA) has really enlivened your efforts. It has hopefully also accelerated your business. You are extremely responsive to suggestions and requests, not to mention helping with issues that arise from those of us unfamiliar with Linux itself.

 

I have one issue with your reply above. When asked if the changes you made to allow cpu cores to be dedicated for audio processes would improve sound quality for reply was: 

 

                      "I am waiting for the results of user experimentation. I must find the time to listen myself... "

I find this a bit troubling. Usually audio application creators come up with a potential idea, test it, and then offer it to users as proven. In this case you seem to have come up with a theory that might improve sound quality and then offered it as "live" for users to test for you. For me the issue here is that most users will assume that if you put an idea into production it will have proven and tested merit. They may then spend time working with it and sorting out bugs when there has been no evidence that it will ever give benefit.

 

I think that it is safe to say that everyone here is primarily interested in improvements in sound quality. Many here may also enjoy the chase since AS has a lot of very inquisitive audiophiles and computer gurus. To be clear, I enjoy the chase and see this as new learning however it is also already clear to me that we are beta testers for Audiolinux. I accept that, however some users may be led down a trail of frustration and quit before ever finding out how good your product is.

 

I would like to suggest that you always have two versions of your software. One should be clearly labeled "beta" and the other will be your well vetted final product. Let subscribed users have both versions and ask for feedback. Currently all of your live products are really in beta. You are asking users to let YOU know if new ideas work or not and if they result in an improvement in SQ. 

 

I hope that you will see these comments as helpful. Keep up the excellent work.

 

Paul

[davide256]

1 hour ago, mourip said:

 

I have been thinking about your reply ever since you wrote it. 

 

I would first like to say that I have switched out both of my Roon endpoints to run AL in ramroot with no internal disks. I was able to pull out 4 SSDs by doing this. I also have now obtained SQ that is on a level with my Dante based system, which is in my mind an excellent achievement. For me AL SQ is not only excellent on an absolute level but is is also huge bang-for-the buck.

 

Now to my point. It is obvious that your involvement with AS(CA) has really enlivened your efforts. It has hopefully also accelerated your business. You are extremely responsive to suggestions and requests, not to mention helping with issues that arise from those of us unfamiliar with Linux itself.

 

I have one issue with your reply above. When asked if the changes you made to allow cpu cores to be dedicated for audio processes would improve sound quality for reply was: 

 

                      "I am waiting for the results of user experimentation. I must find the time to listen myself... "

I find this a bit troubling. Usually audio application creators come up with a potential idea, test it, and then offer it to users as proven. In this case you seem to have come up with a theory that might improve sound quality and then offered it as "live" for users to test for you. For me the issue here is that most users will assume that if you put an idea into production it will have proven and tested merit. They may then spend time working with it and sorting out bugs when there has been no evidence that it will ever give benefit.

 

I think that it is safe to say that everyone here is primarily interested in improvements in sound quality. Many here may also enjoy the chase since AS has a lot of very inquisitive audiophiles and computer gurus. To be clear, I enjoy the chase and see this as new learning however it is also already clear to me that we are beta testers for Audiolinux. I accept that, however some users may be led down a trail of frustration and quit before ever finding out how good your product is.

 

I would like to suggest that you always have two versions of your software. One should be clearly labeled "beta" and the other will be your well vetted final product. Let subscribed users have both versions and ask for feedback. Currently all of your live products are really in beta. You are asking users to let YOU know if new ideas work or not and if they result in an improvement in SQ. 

 

I hope that you will see these comments as helpful. Keep up the excellent work.

 

Paul

@hifi25nl     As someone who had to deal with customer pain from "the law of unintended consequences" in software updates, I highly recommend that you also not move anything from beta status to production status without a reasonable standard bake in interval.  Issues can take time to rise to the top and sort out

from user problems vs software defect. Even bug fixes can cause more issues than they solve.

[lmitche]

1 hour ago, mourip said:

 

I have been thinking about your reply ever since you wrote it. 

 

I would first like to say that I have switched out both of my Roon endpoints to run AL in ramroot with no internal disks. I was able to pull out 4 SSDs by doing this. I also have now obtained SQ that is on a level with my Dante based system, which is in my mind an excellent achievement. For me AL SQ is not only excellent on an absolute level but is is also huge bang-for-the buck.

 

Now to my point. It is obvious that your involvement with AS(CA) has really enlivened your efforts. It has hopefully also accelerated your business. You are extremely responsive to suggestions and requests, not to mention helping with issues that arise from those of us unfamiliar with Linux itself.

 

I have one issue with your reply above. When asked if the changes you made to allow cpu cores to be dedicated for audio processes would improve sound quality for reply was: 

 

                      "I am waiting for the results of user experimentation. I must find the time to listen myself... "

I find this a bit troubling. Usually audio application creators come up with a potential idea, test it, and then offer it to users as proven. In this case you seem to have come up with a theory that might improve sound quality and then offered it as "live" for users to test for you. For me the issue here is that most users will assume that if you put an idea into production it will have proven and tested merit. They may then spend time working with it and sorting out bugs when there has been no evidence that it will ever give benefit.

 

I think that it is safe to say that everyone here is primarily interested in improvements in sound quality. Many here may also enjoy the chase since AS has a lot of very inquisitive audiophiles and computer gurus. To be clear, I enjoy the chase and see this as new learning however it is also already clear to me that we are beta testers for Audiolinux. I accept that, however some users may be led down a trail of frustration and quit before ever finding out how good your product is.

 

I would like to suggest that you always have two versions of your software. One should be clearly labeled "beta" and the other will be your well vetted final product. Let subscribed users have both versions and ask for feedback. Currently all of your live products are really in beta. You are asking users to let YOU know if new ideas work or not and if they result in an improvement in SQ. 

 

I hope that you will see these comments as helpful. Keep up the excellent work.

 

Paul

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.

[austinpop]

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.

[Crom]

Hi Guys,

 

I'm lurking with interest here - fascinating thread!

 

Regarding the new process assignment feature in AL, a couple of years or more ago when I had a two PC Jplay setup running Windows, I used a program called Process Lasso to assign certain processes to one or more processors. Whilst the impact was not enormous, there was a noticeable improvement and that was on top of motherboards that had clocks replaced, battery-run Compact Flash cards as hard drives etc etc. I've done a v quick scan and the software is mentioned in this thread: http://jplay.eu/forum/index.php?/topic/1718-processlasso-and-enhancements-sound-quality/

 

From memory, I believe that the generally agreed philisophy at the time was to dedicate one processor to the music software and then give it the highest priority possible in the software. AL is already doing the prioritising and this is another step to explore.

 

I think Piero is doing an amazing job. The release cycle has increased hugely and exciting new features seem to appear every month...or week! I agree though that the untested affect on SQ is a change to the norm...or maybe not and this is the first time that Piero has mentioned it! I don't have much time to tinker these days (young kids!) and as far as I'm concerned, the easier it is to tweak and upgrade the better. My linux is rudimentary at best, so the new scripts and menu are a great addition. As long as I can configure the processor from the options menu with maybe some initial text file editing to change any default settings, then I'll give it a go. Who knows what difference it will make to a Roon Server.

 

I guess that it would be useful to be able to export/backup settings so that I can be sure of duplicating all settings in any new installation that I do. Maybe settings could be saved to a text file (.conf?) and then could be exported and used when setting up a new image? I usually end up messing up the installs at one point or another with one-change-to-far and it would help to get back up and running as quickly as possible.

 

Anyway, keep up the great work Piero - it's much appreciated - and also, great thread guys, a good read!

 

In case it's of interest this is my server config: Supermicro E300-8d powered with an LT3045-based regulator from MPaudio which is in turm powered by the ad/dc adapter supplied with the server. It runs AL in RAM. I did have a NUC before but I wanted to run in RAM and my roon db was too big.

 

Cheers,

Crom

 

 

[lmitche]

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.

[Superdad]

1 hour ago, lmitche said:

Remember the server and endpoint are connected via wifi.

 

So if server side power supply changes are making a difference to a wi-fi connected end-point, then either something is getting "baked into" the wi-fi stream, or there are some other electrical paths (ground, AC, cables or whatnot) between server, endpoint and rest of system.

More research is required! 

[Dev]

2 hours ago, lmitche said:

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.

 

Larry,

 

first of all thanks for the excellent report!

 

Is your server also connected to wifi ? Past couple of weeks, I moved my NUC streamer to wifi and couldn't be happier. Not sure if I will ever get expensive audiophile switches and lan cables - I just don't feel the need anymore to do anything on the network side for the streamer. My next experiment will be to move my server to wifi network as well and see if it benefits as well but I don't see any reason why would it not.

 

Looks like the hdplex is a great and flexible LPS. I had their earlier version but it caused issues (which many know about). Their new version seems to be stable and lot better performance-wise. How hot does it get ?

[lmitche]

4 hours ago, Superdad said:

 

So if server side power supply changes are making a difference to a wi-fi connected end-point, then either something is getting "baked into" the wi-fi stream, or there are some other electrical paths (ground, AC, cables or whatnot) between server, endpoint and rest of system.

More research is required! 

Hi Alex, yes indeed, more research is required.

 

No question, there is a common earth ground between the two layers of floating ground ac isolation transformers on each side. On the NUC side three lps1.2s power everything and the NUC has an Iso Regen between itself and the DAC which shares a ground with the amp. The amp has a switch to make it float, but it sounds better grounded so the switch is in that position. All power supplies are ground shunted, although I haven't measured the Hdplex.

 

From the little I know, there can be no ground loops, as even the wifi extender is isolated from the server via an Ethernet isolation transformer. And yes, there may be some leakage current jumping through that isolation. Otherwise the entire system has no loops.

 

It does sound fantastic, so many thanks for the contribution of UpTone Audio isolation technology and the Hdplex multi-rail design.

[lmitche]

3 hours ago, Dev said:

 

Larry,

 

first of all thanks for the excellent report!

 

Is your server also connected to wifi ? Past couple of weeks, I moved my NUC streamer to wifi and couldn't be happier. Not sure if I will ever get expensive audiophile switches and lan cables - I just don't feel the need anymore to do anything on the network side for the streamer. My next experiment will be to move my server to wifi network as well and see if it benefits as well but I don't see any reason why would it not.

 

Looks like the hdplex is a great and flexible LPS. I had their earlier version but it caused issues (which many know about). Their new version seems to be stable and lot better performance-wise. How hot does it get ?

Dev,

 

The server is connected via a wired network with an isolation transformer to the network extender. The extender has two 5ghz radios one for the internet backhaul, the other for NUC and control laptop link. No other devices use the ssid.

 

I look forward to experimenting with the EtherRegen in various places in the current configuration.

 

The Hdplex temperature is around 40 degrees C on the surface of the top plate, so rather cool.

 

Agreed, the 5ghz wifi link does sound great.

[lmitche]

The Hdplex DC outputs are not ground shunted.

[bobfa]

Could AC power phasing be a part of the differences?  I have not personally paid attention to this.  

[Forehaven]

Great update Larry, and surprising to me at least.  No matter how much we've focused on isolated, regulated lps's the last yr., we're still finding better results with even better/dedicated ps's.

 

Thanks bud!

[austinpop]

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.

[lmitche]

1 hour ago, austinpop said:

Please correct me if I'm way off base here

More like off topic.

 

My write-up was about the $485 Hdplex 200 watt AC to DC power supply used in combination with the Hdplex 250 watt DC to DC supply to power a standard motherboard and processor. The latter is out of production and has been replaced with a 400 watt version.

 

Are there other power supplies that could be used for this purpose? Yes of course, many power supply manufacturers have solutions that could be used for this purpose including the Hdplex solution that you reference. Is it possible that they will sound better? Maybe, I wouldn't know until they are heard in my system.

 

I would be pleased to test and write-up any of these potential solutions. In the meantime the Hdplex 200 watt solution is very musical and enjoyable. With it's multi-rail design this power supply is also a great candidate for powering a NUC server and/or server side peripherals like network gear, or external hard drives.

[luisma]

11 minutes ago, lmitche said:

More like off topic.

 

My write-up was about the $485 Hdplex 200 watt AC to DC power supply used in combination with the Hdplex 250 watt DC to DC supply to power a standard motherboard and processor. The latter is out of production and has been replaced with a 400 watt version.

 

Are there other power supplies that could be used for this purpose? Yes of course, many power supply manufacturers have solutions that could be used for this purpose including the Hdplex solution that you reference. Is it possible that they will sound better? Maybe, I wouldn't know until they are heard in my system.

 

I would be pleased to test and write-up any of these potential solutions. In the meantime the Hdplex 200 watt solution is very musical and enjoyable. With it's multi-rail design this power supply is also a great candidate for powering a NUC server and/or server side peripherals like network gear, or external hard drives.

Thank you Larry for the update. I have been using wifi for streaming from the beginning and I am very pleased with the results. However would like to get validation and your opinion. 

I have an i3 fanless NAA connected with xover cable to a core i7 nuc running roon and HQPE on Ubuntu. The server has wifi on the other leg so it isolated from the network and only connected to the other device. Both are powered by uptone js2. 

This is different that your setup I know but would you consider that's enough isolation? The DAC is a denafrips connected USB to the naa. 

 

[rickca]

1 hour ago, austinpop said:

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!

Most high quality ATX supplies today have a single high amperage +12V rail.  Older ATX supplies sometimes had multiple +12V rails, but then you had load balancing considerations.  The consensus is that a single robust +12V rail is preferable.  So it's common that the 8-pin EPS12V and the 24-pin share the same +12V rail.

 

It'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.

[austinpop]

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.

[lmitche]

29 minutes ago, luisma said:

Thank you Larry for the update. I have been using wifi for streaming from the beginning and I am very pleased with the results. However would like to get validation and your opinion. 

I have an i3 fanless NAA connected with xover cable to a core i7 nuc running roon and HQPE on Ubuntu. The server has wifi on the other leg so it isolated from the network and only connected to the other device. Both are powered by uptone js2. 

This is different that your setup I know but would you consider that's enough isolation? The DAC is a denafrips connected USB to the naa. 

 

Luisma,

 

Good question. Until recently I had a similar setup. Let me explain.

 

My system is on the third floor. With no cable to the first floor cable modem and router, I have to use a network extender to get internet service up there. A side benefit of this is isolation from the cable system running into the house. It sounds like you have that isolation with your setup as well.

 

In the prior one box world, I ran a cable from the extender to the server. Later I learned that having a switch ala Mr. Swenson's Netgear fs105 with a ground shunt added value between the server and extender. I was looking forward to replacing this with the EtherRegen someday.

 

Then the NUC endpoint arrived with a WiFi card included in the kit. So rather than add another cable and bridging server NICs, I merely enabled the WiFi card to talk to the extender at 5ghz. This second, or third if you count the wifi backhaul, bit of isolation has worked well. SQ is awesome.

 

When the EtherRegen arrives it will be interesting to replace the NUC wifi link with a wired connection and to compare SQ.

 

I hope this makes sense. It is a bit complicated.

 

Larry

 

[jcn3]

I've been playing around with AL on my NUCs for the last week.  It's been great fun learning a bit about Linux, digging into the BIOS, and of course listening.  

 

Before giving my impressions, a bit of background:

 

* My progression on CA started with a basic CAPS server.  Played around with adding a better USB and a decent R-Core 12V LPS off eBay.  Used JRiver is a single box configuration with music on my Synology NAS.

* Next step was to move to a "two box" approach -- putting Minimserver and BubbleUPNP on my NAS, using JRiver as a simple endpoint.

* Next, replaced the CAPS with a NUC6i5 and a fanless case, ultimately buying AO and Fidelizer (still using Minimserver on my NAS).

* Finally, added Roon and Dirac Live, installing ROCK on a NUC7i5 (with another LPS off eBay) to be the server.  That left the NUC6i5 as the endpoint running Win 10 / AO / Fidelizer / Dirac / Roonbridge.  This has sounded fabulous to me.  My signature shows the rest of my gear -- nice stuff, but clearly at the lower end of the high end.

 

In trying AL, I wanted to see what stripping everything down to the bare minimum would do.  First put AL on the NUC6i5 running Roonbridge.  Stripped down the BiOS as has been recommended, running in memory, Extremed mode, etc.

 

The difference between AL on the endpoint and the Win 10 setup was clear -- AL put sharp edges around everything, clearly delineating instruments in the soundstage (which I liked).  In some ways, the soundstage seemed deeper, too.  Unfortunately, I also lost some low end energy and, more importantly, lost the lushness and beauty of the Win 10 / AO / Fidelizer / Dirac setup -- strings particularly were sharp and edgy.

 

To get the full AL experience, I also got a fanless case for my NUC7i5, increase RAM to 16g, and set up AL as the Roon core, doing all of the optimizations I did on the endpoint.  The difference in doing this was much more subtle, mostly providing a bit more of the etched sound that AL on the endpoint started.

 

As much as I wanted to love AL, for now I've gone back to my Win 10 / AO / Fidelizer / Dirac configuration for the endpoint.  I've got the lushness and beauty back, and the great benefits of Dirac.  I'm keeping AL on the NUC7i5 as the server, allowing me to keep some of the clarity it provides.

 

I know we all hear differently, have different equipment, and of course different rooms.  I'm game to make more changes to make AL work, but I'm not sure where to start.

 

Would love thoughts, recommendations, opinions.  Thanks!

[luisma]

3 hours ago, lmitche said:

Luisma,

 

Good question. Until recently I had a similar setup. Let me explain.

 

My system is on the third floor. With no cable to the first floor cable modem and router, I have to use a network extender to get internet service up there. A side benefit of this is isolation from the cable system running into the house. It sounds like you have that isolation with your setup as well.

 

In the prior one box world, I ran a cable from the extender to the server. Later I learned that having a switch ala Mr. Swenson's Netgear fs105 with a ground shunt added value between the server and extender. I was looking forward to replacing this with the EtherRegen someday.

 

Then the NUC endpoint arrived with a WiFi card included in the kit. So rather than add another cable and bridging server NICs, I merely enabled the WiFi card to talk to the extender at 5ghz. This second, or third if you count the wifi backhaul, bit of isolation has worked well. SQ is awesome.

 

When the EtherRegen arrives it will be interesting to replace the NUC wifi link with a wired connection and to compare SQ.

 

I hope this makes sense. It is a bit complicated.

 

Larry

 

It makes perfect sense, I run high quality wireless at my house and speed is excellent that's why I opted for bypassing the ethernet cable to the router but I have wanted to experiment with minimal hardware configs removing wireless, ssd and stuff (bios settings, turbo boost, etc) from the system, I have a fanless computer nuc type as naa and the smaller allo Bridge sounds a little better. Now I am in a path to convert this small nuc in a more minimalistic piece of hardware removing wireless etc and the bios is highly customizable (although rather buggy). 

And since you were trying different settings with power etc wanted your opinion on the isolation thanks