Euphony OS w/Stylus player setup and issues thread

[TheAttorney]

On 4/9/2021 at 8:24 AM, flkin said:

Given this, my 8-core CPU (non-hyperthreading) isolations are:

0 systemd 1 nfm 2 dhcpcd 2 dbus-daemon 2 haveged 2 lvmetad 2 avahi-daemon 2 gstp 3-5 stylus 6-7

I liked the methodical way you came to this - way more patience than I could ever muster. I also tend to get into a muddle when faced with too many variables, which I why I usually go for simple options.

 

Anyway, I copy & pasted the above exactly as is onto my 4 core/8 thread 7i7DN - and I really like the end result, despite our two systems being very different, and also despite this being a completely different configuration to my previous favourite. So I'll be running with this new one for a while.

[TheAttorney]

11 hours ago, Topk said:

Why do you give 2 cores to Stylus? I thought stylus was only the GUI? My instinct would give only 1 to stylus and more to gstp since it’s the player itself, but please let me know what you found!

 

Stylus, in this context, is not "just" the GUI.

In steady state music playing, without touching the GUI, the cores running Stylus are generally busier than those running gstp.

And the Stylus cores go into overdrive when, say, buffering to RAM or updating the database. Whether Stylus itself is doing this, or kicking of system sub-processes is a moot point. The end result is that cores allocated to Stylus are doing more stuff behind the scenes.

 

I had earlier found that giving up Stylus cores in favour of gstp was beneficial to SQ (but not to system responsiveness).

But with flikin's core isolation style, I no longer found this to be so. Too many variables to try to work out why.

 

What I did find still worked was to over-allocate the gstp to partly share it's neighbouring core allocations.

So, with start point of gstp 3-5, I found that gstp 2-5 sounded slightly better.

And gstp 3-6 also sounded slightly better.

But best of all was gstp 2-6, and I have a new reference that I'm delighted with 🙂.

 

In full, this is  0 systemd 1 nfm 2 dhcpcd 2 dbus-daemon 2 haveged 2 lvmetad 2 avahi-daemon 2 gstp 2-6 stylus 6-7

 

I can't explain why this should matter, but I expect the result to vary depending on how any particular CPU design handles its load balancing across cores and threads. As flkin has observed, there's more going on in the background than meets the eye.

 

Stretching gstp to even further beyond 2-6 did not seem to help, but by this stage I was getting into a muddle again. So I need to get used to my new reference for a while. It's so easy to by seduced by a new presentation and not spot the downside until later on.

 

[TheAttorney]

3 hours ago, biosailor said:

I have Euphony running Roon Core on a 4 CPU i5. When checking the temperature of the CPUs, Euphony often shows that one of the four CPUs runs at 100% full load. Is this something I should worry about? I also dropped the clock frequency to 1.5 GHz and the CPU temp is now never above 50 degs.

 

If you have Roon processes isolated to a single core AND Roon is running a significant database update (like importing several albums), then this may be normal. If these two points do not apply then something is wrong and needs further investigation. What are your Core Isolation settings?

[TheAttorney]

@biosailor, it looks like you don't have any core isolation set, so that is not the problem.

If you hit Apply now, you'll see a list of processes that are running at their default allocation. This won't change anything - it's just a display so perfectly safe. It only changes if you actually enter something in the field.

 

Anyway, the only other thing I can think of is that you have roon on-demand analysis set to fast. This may overload the CPU if playing a new file that hasn't been analysed yet. But I'm clutching at straws here - I don't really know.

[TheAttorney]

13 hours ago, ASRMichael said:

I’ve finally got to grips with how IRQ Affinity work in Expert core isolation.

 

I've also had a go at this. Being a simple kinda guy, I went for a simple approach  without changing my current favourite core allocation of

 

        0 systemd 1 nfm 2 dhcpcd 2 dbus-daemon 2 haveged 2 lvmetad 2 avahi-daemon 2 gstp 2-6 stylus 6-7

 

I first checked the default IRQ situation by typing ".".

The irq's were evenly spread across my 8 virtual cores, and  the biggest IRQ activity (USB data) happens to be called irq-131 running on core 6 (which is shared between gstp and stylus).

 

I then looked for the quietest core I could find, in terms of visible processes, other IRQ activity and core temperature. This turned out to be core 3, which had only gstp and one of the smallest other IRQ activity. So I then isolated 131 onto that core by adding "irq/131 3" to the end of the above string. I don't know how accurate this amateur logic is, but you have to start somewhere.

 

In short, this was just a single IRQ isolation change added to the end of an unchanged main core isolation.

I will also not disclose the end result impact on SQ, as this is early days yet and I was still in the honeymoon period with the previous change, but I will say right now that you've got to try it 🙂.

 

I also tried a few other options of both IRQ and main core isolation changes and soon got into a muddle, so nothing conclusive to report on how far this can still go.

[TheAttorney]

@RickyV, I'm just a beginner on this too, but I think you've got it correct.

 

Your USB IRQ was already in a good place, so you left it alone.

And your Eth IRQ was in a less good place, so you moved it to a better one.

 

After a brief correspondence with ASRMichael, a couple of things have been clarified for me:

 

1. Both USB and Eth IRQs should be on the same cores as gstp, which you now have.

2. Different servers may behave differently with IRQ allocation after running the initial core allocation (processes only, not IRQs): On Michael's server, the default positions of IRQs moved after running core allocation. On my NUC the IRQs stay in the same position whether core isolation is used or not. It looks like your NUC did move the IRQs after initial core isolation, but not in the same way as Michael's.

 

BTW, when you type "." to get the display, there is no need to clear the field first. The dot does not overwrite anything. This saves much time.

 

 

[TheAttorney]

4 minutes ago, RickyV said:

Which one is the USB IRQ? XHCI?

 

Many thanks 
 

Correct. Some more complex systems may have more than one eth or xhci - my simple NUC has only one of each.

[TheAttorney]

5 hours ago, ASRMichael said:

When you use “.” Its only to find out where all your IRQ are & what numbers they are. Once you have IRQ numbers forget about the “.” Because as soon as you hit your core isolation the “.” Info changes. In your case all of them go to core 0.

This information can be misleading - depending on your start point. I regularly use the "." dot function.

 

On ASRMichael's server, there is a specific issue: By default, IRQs are spread across all cores, but on core isolation, the IRQs all get squashed into the first set of cores listed - in his case 0-3. So it's usually worthwhile to spread them out again by applying IRQ core isolation.

 

But on my 7i7DN NUC, running core isolation does not change the default IRQ core allocation. And, from looking at RickyV's screenshots, his NUC (also 7i7DN I think) appears to behave exactly the same as mine - which is:  At point of allocation, the display shows that all IRQs are allocated to 0 (see screenshot above), but in practice none of the IRQ shift from their default allocation (unless you specifically allocate an IRQ). This can be seen by hitting dot in the core isolation field (also see RickyV's earlier screenshots above).

 

Therefore RickyV and myself do not need to trouble ourselves with un-squashing the IRQs. All we need to do is look at the dot display and see which are the busiest IRQs and whether it's worth allocating those to a more appropriate core. And I find it useful to occasionally check dot to see that all is working as expected and which are the busiest IRQs. When simply playing music, some IRQs hardly increase  from one minute to the next, so it's hardly worth bothering with even if they're not in the perfect allocation.

 

When just playing music to USB, by far the busiest IRQ is the USB (XHCI) one. This is the crucial one to consider moving to a quieter core - that is also allocated to the gstp process.

 

My networking uses wifi-only, so I have an additional WiFi IRQ and this is the second busiest after XHCI - but it is several orders of magnitude less than XHCI when playing local files (a different story if I was to stream Qobuz etc). So, in relative terms, it's hardly worth bothering with, but nevertheless I found a slight improvement by moving the WiFi IRQ away from gstp and onto a Stylus-only core (when playing local music, any network activity is just control and display functions, so makes sense to keep it away from gstp - it may well be different when streaming Qobuz etc).

 

If all this sounds frightfully complicated to IRQ-newbies, then it's much harder to write about than it is to actually do. And I think it's worth the effort. As start point, all you need to do is hit dot in the core isolation field, as long as you have the latest Euphony version 117.

 

PS. The dot display shows cumulative IRQ activity since last reboot. So if you move an IRQ to a different core, then the old core will still show activity - but frozen at the point of move. The count only gets reset at reboot.

[TheAttorney]

1 hour ago, c-w said:

Has anyone tried comparing
1) USB IRQ on the same core as gstp
vs
2) USB IRQ on a dedicated core - not the core reserved also for gstp or anything else

I'll give it a go tonight. I did consider this a while back, but can't remember if I actually tried it.

 

@ASRMichael, all I know from my limited tests is that moving USD IRQ from a core that shared both gstp+Stylus to a core that ran gstp alone gave me the biggest increase in SQ during this exercise.  The first core was definitely busier in terms of % CPU and temperature. It could have been a coincidence, but it was good enough for me. What c-w seems to be alluding to, is that the quietest possible core could indeed be important - yet to be confirmed by a listening test.

 

It's possible that RickyV's NUC did not behave exactly like mine (although it seemed very similar), but too many screen shots and examples have flown by in the meantime, so I'm not inclined to trawl through it all in detail at this point. Onwards and upwards. Everything is WIP at this stage 🙂.

[TheAttorney]

Update on my IRQ testing:

 

From start point of Euphony 117 and flkin's Core Isolation recommendation of

 

    0 systemd 1 nfm 2 dhcpcd 2 dbus-daemon 2 haveged 2 lvmetad 2 avahi-daemon 2 gstp 3-5 stylus 6-7

 

I made the following consecutive steps:

 

1. Over-allocated gstp to 2-6 (sharing with its neighbours at either end).

2. Moved USB IRQ to a less busy, gstp-only, core (from 6 to 3) and moved WiFi IRQ away from gstp to stylus on 7.

3. Fully isolated USB IRQ by setting systemd to 0, and USB IRQ to 1 (Isolating different cores gave no obvious improvement over this).

 

Resulting in my final configuration of:

 

   0 systemd 0 nfm 2 dhcpcd 2 dbus-daemon 2 haveged 2 lvmetad 2 avahi-daemon 2 gstp 2-6 stylus 6-7 irq/131 1 irq/135 7

 

Each of those steps increased vividness (a combination of clarity, dynamics, focus etc) to generally good effect, but also caused a bit of brightness to start creeping in, most obviously noted in over-bright recordings like Feist's The Reminder. Ultra clear, but with a somewhat glassy presentation that was not welcome. Toning down the vividness wasn't the answer because the presentation then seemed to get more smeared and flat.

 

I was about to report that my WIP was still not conclusive - when new version 421 dropped in. Well. it may have been wishful thinking, but those remaining brightness concerns seemed to magically disappear. All good and, for the nth time in the last few weeks, my system has never sounded better 🙂 .

 

And I noted a further slight improvement by changing my previous favourite CPU speed from 1.2 GHz to 1.3 GHz. Yes, yes, I know... desperate measures for desperate times! But it's a reminder that all these configurations can impact each other.

 

I also noticed that 421 has a new feature (press power button) to interrupt the offline play feature. I was somewhat skeptical that this would work, but it did on my NUC (could well be h/w dependent). So the offline play feature is now much more user-friendly although, strangely, I don't hear any improvements on my system when I disable WiFi when playing buffered tracks. 

 

PS. No core temperature difference for me with new version 421.

 

[TheAttorney]

On 4/22/2021 at 9:56 PM, edwardsean said:

However, as much as I prize precision, my goal is always a "creamy clarity." In my Dave-based system, 421 is still missing the fullness and fluidity of 102. 421 is smooth, but I still find the sound somewhat tight and small. On balance, 102 is missing 421's focus and is too diffuse, but there is simply this gorgeous analog texture and freedom of flow. It also renders with larger scale and dynamics to my ears.

 

This makes it very tempting to go back to one of those older releases to find out what magic I may be missing. But I hate going backwards and losing functionality.

 

In the meantime, I've made one final isolation tweak to 421 after reflecting on flkin's comment that isolation of systemd process was important in his system. My last settings effectively sacrificed systemd in order to make space for isolating USB IRQ. So this time I shuffled things round a bit so that systemd and USB IRQ each had their own virtual core (at the expense of gstp). With end result:

 

0 systemd 2 nfm 3 dhcpcd 3 dbus-daemon 3 haveged 3 lvmetad 3 avahi-daemon 3 gstp 3-6 stylus 6-7 irq/131 1 irq/135 7

 

And this is the one that I'm sticking with (along with CPU speed reverting back to 1.2GHz) - I'm done with tweaking now and will just enjoy listening to music.

 

So, I'm no longer tempted to try those older releases because I don't feel I have a problem that needs fixing - the clarity/fullness balance seems just fine to me. Onwards and upwards. If Z can re-introduce some of that old magic into a future release then that would be great. In the meantime. I'm perfectly happy with what I've got - no more FOMO for me 🙂.

[TheAttorney]

 

20 hours ago, flkin said:

Here’s an option to stir things up - try no core isolations. With each new Euphony version, I find it’s worth trying. 

There’s one isolation I’m thinking that might be significant but has not yet been discussed - the conversion of Flac files (assuming many people store in this format) into WAV before playback. It takes resources and has to be done. Does anyone know which Linux resource this might be? Or perhaps Euphony has already done the conversion before buffering into RAM for playback.

I did try no isolation and it sounded fine. TBH any setting sounded much the same on 421, but this could be because I'm getting comparison fatigue, which is another reason for stopping. Nevertheless, my current favourite isolation config still wins out on vividness, where images pop out more clearly from the mix. "No isolation" is softer and more restrained, which of course may be preferable to some depending on personal preference and system synergy.

 

I don't know at what point Euphony does its FLAC expansion, but a while back I did a test comparison of the same file in FLAC and WAV form, and came to the conclusion that I could not reliably tell the difference. I did hear some very subtle differences, but could not consistently state which was which, so this could have just been mind tricks. In short, I felt that FLAC expansion was an area that I did not need to worry about at this point in my hifi journey.

 

14 hours ago, RickyV said:

 

Quick question, what is your IRQ135 assigned to? My nuc doesn’t have it.

This is my WiFi IRQ, so only those using WiFi instead of ethernet will have it. I also have an eth0 IRQ, but it is much less busy so I've not worried about it.

 

12 hours ago, drjimwillie said:

I will have to look at the IRQ to determine this but? I do not use USB, I use I2S from a pinkfaun ultra card and I am wondering how to identify the IRQ and if that should be isolated.

Just hit dot in the core isolation field to display how busy each IRQ is. Then choose the busiest one - it should be very obvious and will be order of magnitudes busier than all the others put together. At least when playing local files.

[TheAttorney]

Having stopped playing about with core isolation, something forced me right back:

 

One day, the sound seemed "off" and, on checking dot, I found the reason: My primary xhci should have been allocated to irq/131, but instead that number was taken by something called ahci (and xhci was allocated irq/132). I've since noticed that these two do occasionally swap numbers after reboot. Now, ahci seems to do nothing at all (the irq count never goes above 0), but the SQ degradation was because the all-important xhci was randomly allocated to a shared core. I fixed this by allocating both 131 and 132 to the same core, so it wouldn't matter which way the swap went next time.

 

Whilst in the area, I took the opportunity to try out an idea inspired by others' recent posts - and I now have a new favourite 🙂 :

 

      2-3 systemd 0 nfm 1 gstp 5-7 irq/131 4      (the full list includes the less significant irq/132 4 irq/135 3)

 

The key thinking behind this is: Find the really important things to isolate and let the o/s sort out all the rest. So, important to completely isolate was the primary irq, systemd, and new for this time nfm, and of course gstp. And lump stylus and various daemons in with "everything else". I put "everything else" into virtual cores 2-3 simply because I wanted to put less busy processes into 0-1 because physical core 0 has traditionally run slightly hotter than the other cores. My OCD like balance.

 

Trying slight variations of above (like dropping nfm) yielded inconclusive results, so there may well be a still better combination, but I've stuck with the one that first gave a me a Wow response. It wins at all levels: it's got all the vividness and focus as before, but now with extra fullness, flow, soul, and a deeper, more powerful, yet still-tight, bass - all helping to add some very welcome depth and spaciousness to the sound stage. What's not to like?

 

To show that any change may impact other parameters, my previous favourite CPU speed 1.2GHz is now beaten by 1.3 or 1.4 GHz.

 

Following edwardsean's example, I also tried no isolation (0-7) and non-ramroot. Both sounded fine on 421, but neither was as good as my new favourite on ramroot and, with the proviso that all such changes are probably objectively tiny, the subjective impact is considerable. I'm done with changes now. Really I am.

[TheAttorney]

6 hours ago, Lukasluis said:

My NUC 8i7 has a native CPU frequency of 2.7Ghz and Turbo up to 4.5Ghz. I also tried 2.4Ghz which is the double data rate of the RAM but I prefer the sound with with the 1.2Ghz single data transmission per clock cycle. 

I also found that 1.2GHz sounds best on my 7i7DN, which has a base speed of 1.9 GHz and Turbo 4.2 GHz.

I came to this conclusion purely by listening and only later realised that my Apacer RAM was running at 2400 Mbps, and did wonder if this was coincidence or not.

 

More recently, with my last core isolation changes, as posted earlier, I found that slightly higher speeds of 1.4 and 1.6 also had their advantages and there's currently no absolute winner. But here's the weird thing:

 

Although each of the speeds within my 1.1-1.9GHz test area were fractionally different, there was a consistent theme that the even speeds (1.2, 1.4. 1.6, 1.8) were more vivid/dynamic and the odd speeds (1.1, 1.3, 1.5, 1.7, 1.9) were slightly softer and smoother. Apart from over-imagination, I can't think of an explanation for this, but I'm pleased that I can change the character of presentation so easily. Overall, the vivid speeds win for me.

[TheAttorney]

24 minutes ago, PavelDosko said:

can you recommend any specific type of Apacer RAM?

As has been posted not so long ago....

On 5/16/2021 at 9:56 PM, RickyV said:

 @TheAttorney and me are using these Apacer rams now, these are industrial grade -40 to +95 degrees c.

 

https://nl.mouser.com/ProductDetail/Apacer/D2323240S004/?qs=GBLSl2AkiruWco00G6Jb1Q%3D%3D

This 2666 speed Apacer sounds better than the 2400 that we had before (and the 2400 was considerably better than Crucial RAM that originally came with my NUC). There's also a 3200 version that I haven't tried. This for NUCs, which generally do not support ECC. If your server supports ECC RAM then there are even better Apacer models around that have been described before on this and similar threads.

[TheAttorney]

19 hours ago, auricgoldfinger said:

Look for posts from TheAttorney throughout this thread for detailed, specific information.

 

I should point out that, as of a few days ago, I've thrown money at my downsizing objective (to reduce box and spaghetti count) and replaced a whole line of components, including my NUC, with a posh dedicated server (see the Grimm MU1 thread). That has it's own linux-based system and is closed-box, i.e. nothing visible to adjust and no option to try Euphony on it. So it's a fond farewell to Euphony - I don't know whether to sell my fanless Porcoolpine NUC 7i7DN, or keep it as spare (anyone interested in buying can PM me to force my hand).

 

As a conclusion, my final Euphony config was:

 

* Ramroot enabled, with 8GB Apacer 2666 RAM.

* Files all pre-buffered before play (TBH, I found this less critical than ramroot, Apacer RAM, or CPU speed andcore isolation below). 

* Low CPU speed of 1.4 MHz (slighly less bright than my previous, also good, 1.2 Mhz. To the person who recently asked, you change this using the Max speed setting in Expert settings, much easier than changing it in BIOS)

* Unlike some others, I found 421 release to sound great in all departments, but the very latest release is as good if not slightly better.

* Core isolation as follows

    2-3 systemd 0 nfm 1 gstp 5-7 irq/131 4      (the full list includes the less significant irq/132 4 irq/135 3, explained in earlier posts)

 

My previous core isolation thinking was to isolate only the really important processes and let the o/s sort out all the rest. So, important to completely isolate was the primary irq, systemd, possibly nfm, and definitely gstp.

I subsequently found that over-allocating gstp further improved SQ - even if it meant sharing some cores. But not to over-do the over-allocation, so left systemd and primary IRQ (USB in my case) completely isolated. Ending up with:

 

     2-3 systemd 0 nfm 1 gstp 1-7 irq/131 4   

 

This gives such a well-balanced sound, with lots to love and nothing to complain about. If ever I should fall out of love with my new Grimm MU1, and go back to an open app and server, then Euphony Stylus will be my fist port of call.

 

[TheAttorney]

Sorry, I was typing from memory and made some mistakes in my core isolation settings, and it's really frustrating that this site doesn't allow one to edit a post so soon after writing it.

 

The final recommendation should have been:

 

       2-3 systemd 0 nfm 1 gstp 1-6 irq/131 7

 

I.e. systemd and primary IRQ are each completely isolated, with gstp over-allocated across all the remaining cores.

Which doesn't mean that other variations can't also sound great - just this this was slightly ahead on my system.

Sometimes when I've tried variations, my mind gets muddled and everything sounds much the same. At other times, this one just hit the spot, above all other variants.

[TheAttorney]

2 hours ago, auricgoldfinger said:

 

Congratulations on your new server!  I know your downsizing objective has been a long-term, ongoing process.  What other changes did you make?

Well, ultimately I'd really like a single box that I can just plug my headphones into. But there's nothing on the horizon that can do that at the high level SQ I demand. So I currently have a 2-box system, MU1 to existing DAVE DAC/amp.

 

So nothing else planned until next year when Grimm add an optional DAC into the same integrated box, called MU2. If (and it's a big if) Grimm pull off the same magic with their DAC module, then DAVE's days will be numbered - because then MU2 could talk directly to a dedicated top end headphone amp that is powerful enough to drive even really inefficient headphones such as Susvara.

[TheAttorney]

14 hours ago, edwardsean said:

 

Did you try out a Bartok? Not to get too far afield on this thread. I know that austinpop was able to get Euphony running on it.

I did consider the Bartok. But, rightly or wrongly, I didn't see it as a true server that can fully manage a locally stored music system. I saw it more as a DAVE rival with some networking/streaming capabilities. Not a NUC rival (as I  said, I could be mistaken - it's sometimes hard to unravel the differences between a streamer and a server). The Bartok is also a very large box and, in true DCS style, I'd have to fret whether to also get the upsampler for maximum performance - and that is another large box and cable and power cord and suddenly I'm not downsizing anymore. And the dealer that stocked Grimm/Taiko/Innuos did not stock DCS and I wanted to keep my comparisons simple. Other than all that, I would have loved to have tried the Bartok 🙂.

 

Anyway, interesting though this topic is, to keep this thread on track, I suggest any more questions about Grimm and rivals to be taken to the Grimm MU1 thread.

[TheAttorney]

4 hours ago, zeblo69 said:

The question is about ddr4 apacer industrial grade ram. I've found a dealer who sold 3200 mhz sodimm modules, but the above nuc ram specification is stated 2400. Are 3200 modules compatible downwards with nuc7i7dnke, working without issues at 2400 mhz?

I haven't specifically tried the 3200 version, but the 2666 version worked fine in my NUC7i7DN, despite it only running at 2400, as shown on the BIOS display. I could not find a way of changing the default 2400 RAM speed in BIOS, and I think this parameter is only adjustable in certain (probably server-level) systems. Nevertheless, the 2666 version running at 2400 sounded better than the 2400 version running at 2400, so I suspect the same will apply to your 3200 version. 

[TheAttorney]

8 hours ago, jacky5555 said:

Have you bought the H10 @TheAttorney?
I have installed Euphony OS as well as music storage to my H10 for a year and how to make sure the OS had been installed to Optane partition (and not to NAND partition)?

I didn't go for the H10 in the end. Purely to keep things as risk-free as possible, I ordered a pre-installed fully working Optane solution from SimplyNUC: A pure Optane 32GB card pre-installed with free Ubuntu (and configured as an SSD, not as an accelerator). Which meant my start point was a fully working system that was easy to then overwrite Ubuntu with Euphony. There was space on the 32GB Optane to add some music files as a proof of concept, but for my main music filestore I simply plugged in a thumb drive into one of the NUC's USB sockets.

 

From a price/performance/operational/SQ perspective, this worked very well for me. But my total redbook FLAC filestore was under 256GB, so using a thumb drive was easy - it's not so suitable for those who have large music libraries.

 

So unfortunately I can't help with your H10 question, but if you don't get an answer in this forum, maybe you could try emailing your H10 or NUC supplier? SimplyNUC's tech department were very good at answering my questions at the time.

[TheAttorney]

On 7/2/2022 at 9:51 AM, al2813 said:

Question to those running Euphony on a NUC. How is your experience compared to a more classic PC? Have you changed the case? Also, are you feeding it 12v or 19v and have you seen a difference in SQ. 

 

I am interested in reducing my rack space (essentially removing one of my two racks) and considering retiring my full-blown case audio PC in favour of a NUC (starting with a server and end point in one box and maybe moving to two boxes in the future). 

Euphony on my stock 7i7DN NUC sounded considerably better than my previous JRiver or Roon on my Windows laptop. And got better still once I tweaked the NUC with better power supply, Apacer memory and Euphony configurations, as per my old posts.

 

This was with server and end point both in the small and cute Porcoolpine fanless box and using the NUC's built-in WiFi for networking. Whilst some have gone for ever more powerful and complex solutions, the 7i7DN is great for a simple, low-powered, downsized solution.

 

I did try different voltages, but found that the fundamental quality of the power supply was much more important that its voltage setting.

 

A while back, I further downsized my system by going for a much more expensive dedicated server (Grimm MU1). I have so far kept my NUC as a spare, but haven't used it for a year, so it's going to go up for sale. PM me if anyone is interested - I haven't got round to putting it up in Classified yet.