Building a DIY Music Server
Building a DIY Music Server13 hours ago, Nenon said:
Very interesting. Thank you for sharing. Can you share more details?
What clock are you using? I see some external grounding (an external grounding box?)? What is the red board? A relay?
The clock is Connor Winfield DOCSC022F 24MHz.
Roon Server is grounded to Telos GNR 3.1mini.
The red board is a relay which acts a power-up timer to warm up the clock.
MB: MSI z390m Gaming Edge AC
CPU: i7-8700 (3.2GHZ)
Ram: Corsair DOMINATOR® PLATINUM 16GB (2 x 8GB) DDR4 DRAM 2400MHz C10 Memory Kit
Case: Streacom FC9 Alpha Fanless Chassis
SSD (OS): Samsung 970 Evo Plus (500G)
HDD (Music File): WD Ultrastar DC HC530 (14T)
SATA Cable: Pachanko "Aphelion" SATA
SATA PCIE Card: IOCrest Marvell 9235 - direct to CPU
NIC: Jcat Net Femto (Powered by Full ATX LPS) - direct to CPU
Lan Cable (Roon Server to Uptone eR): Supra Cat8 (13m) w/Telegartner Cat8.1 RJ45
Lan Cable (Uptone eR to dCS Vivaldi Upsampelr): Pachanko Ethernet "Aphelion (1.5m) w/Telegartner Cat8.1 RJ45LPS: Uptone JS-2Vibration Control: Thixar Silence, Stillpoints UltraSSPower Cable: Shunyata Alpha HCHook-up wire: NEOTECH 18 AWG UP-OCC (Teflon)Software:OS: WS2019 Datacenter w/ AO3 custom Roon Shell and Process LassoMusic Software: Roon ServerTuning :1. BIOS: Hyper-Threading = ON2. BIOS: Disable all other features of CPU and unnecessary components3. WS2019: Disable write-caching for SSD and HDD.4. WS2019: Network bridge in WS2019 (i.e., Roon Server direct connect to dCS Upsampler via a 13m long Supra Cat8 lan cable)5. WS2019: Disable 35 numbers of Windows Services6. Process Lasso: Assign CPU0-3 for OS / CPU4-11 for Roon7. Process Lasso: Turn off Process Lasso EngineDisable the following Windows Services in WS2019 Datacenter (AO Roon Shell):
2. Print Spooler
3. Windows Font Cache Service
4. Connected User Experience and Telemetry
5. Intel HD Graphics Control Service
6. Intel Push Notifications System Service
7. Program Compatibility Assistant Service
8. Intel Dynamic Application Loader Host Interface Service
9. IP Helper
10. Network List Service
11. Network Connectivity Assistant
12. Network Connection (Manual)
13. Network Connection Broker
14. Connected Devices Platform Service
15. TCP/IP Netbois Helper
16. IPsec Policy Agent
17. COM+Event System
18. System Event Notification Service
19. CRYPTOGRAPHIC Service
20. Web Account Manager
21. Windows Audio
22. Windows Audio Endpoint Builder
23. Human Interface Device Service
24. Quality Windows Audio Video Experience
25. Windows Connections Manager
26. Portable Device Enumerator Service
27. Windows Update
28. Windows Modules Installer
29. IKE and AuthIP IPsec Keying Modules
31. Shell Hardware Detection
32. Security Accounts Manager
CPU Voltage Tuning:CPU Core Voltage = 0.95vCPU GT Voltage = 0.6vCPU SA Voltage = AutoCPU IO Voltage = AutoCPU PLL OC Voltage = 1.2vCPU ST PLL Voltage = 0.95vDram Voltage = 1.35VPCH Voltage = Auto
Lush^2 - Share your configuration experiences
Lush^2 - Share your configuration experiences
I've now had my 2nd Lush^2 in for a couple of weeks or so, so time for some feedback:
This Lush replaced my USPCB between ISORegen and M-Scaler. In short, the Lush sounds better and well worth the effort - as some others have already posted. This was irrespective of the pin settings used, but nevertheless I quickly moved from default to JSSG360Cubed. I also tried the latest recommended jumper settings and, as before, I still preferred no jumpers - which is handy because this makes pin swapping a bit easier.
I put the short 0.4M Lush before IR, and long 0.7M Lush after IR - this simply because it made component layout easier on my hifi rack. So I ended up with...
WYR WYR Lush, NUC > IR
WYR WYR Lush, IR > HMS
[W]BY [W]BY Blaxius, HMS > DAVE
And this gave a great sound, but I also revisited Kurb's new favourite WY WY (I still preferred with no jumpers) and this proved interesting:
WY WY gave a touch more detail and dynamics, but
WYR WYR gave a touch warmer, more cohesive soundstage
What I really needed was something that combined both qualities. So how about directly combining these two with....
And Hey Presto! My new favourite (TANF) - that was somewhere in between the other two, but with the bonus of a greater perception of depth, which is very important to this headphones-only user (although strangely, width seemed reduced). So my final combination is now:
WY WYR Lush, NUC > IR
WY WYR Lush. IR > HMS
[W]BY [W]BY Blaxius, HMS > DAVE
The full notation for my TANF would be
A: xWYxxx, B: xWYRxx
I also tried
A: xxxxWY, B: xWYRxx to see if the antenna affect mattered, as the source end is right next to my NUC's wifi antenna.
And I didn't notice much difference. If anything, this new position was fractionally worse so I went back to the original position, as this is more convenient to try jumper configurations in the future. TBH, these are quite subtle differences, and any of the recent favourites would be fine - this is just fine tuning.
Euphony OS w/Stylus player setup and issues thread
Euphony OS w/Stylus player setup and issues threadOn 6/26/2019 at 8:19 PM, bobfa said:
I am excited to hear more. Can you post a couple of pix of your hardware? Where exactly have you landed on the CPU frequency settings?
I got diverted by an issue when installing Euphony onto the Optane drive (after purchasing the full license):
The install went fine, but I lost my WIFI on booting from Optane. So I had to temporarily rig up all sorts of extension cables to get an ethernet connection to my remote broadband router. I was tearing my hair out because I couldn't see what the problem was, and was not looking forward to persuading Euphony Support to support me on an unsupported feature. Then the solution literally popped up to me with a message saying that I wasn't on the latest version and would I like to get the latest feature upgrade? On upgrade to the latest version (29th May), WIFI worked fine. Phew! Happy Days. The lesson here is that Install won't necessarily install the latest version even though the USB stick I was installing from did have the latest version.
Back to CPU frequency. I've found that I can go from Full Throttle to Standby by changing just 1 digit in the Max Frequency setting as below. I find the Standby very useful for significantly dropping both power consumption and CPU/case temperature:
This results in the frequency and temperature results below:
The understanding of "isolation" in digital audio has been my passion for at least 10 years. There is a LOT of misunderstanding on the subject floating around in audio circles. Here is a quick summary of my current understanding and how the current products fit in with this.
There seems to be TWO independent mechanisms involved: leakage current and clock phase noise. Various amounts of these two exist in any system. Different "isolation" technologies out there address one or the other, but very rarely both at the same time. Some technologies that attenuate one actually increase the other. Thus the massively confusing information out there.
Leakage current is a property of power supplies. It is the leakage of AC mains frequency (50/60 Hz) into the DC output. It is usually common mode (ie exists on BOTH the + and - wires at the same time, this makes it a bit difficult to see. There seems to be two different types, one that comes from linear supplies and is fairly easy to block, and an additional type that comes from SMPS and is MUCH harder to block. An SMPS contains BOTH types. They are BOTH line frequency.
Unfortunately in our modern times where essentially all computer equipment is powered by SMPS we have to deal with this situation of both leakage types coming down cables from our computer equipment. There are many devices on the market (I have designed some of them) for both USB and Ethernet, most can deal with the type from linear supplies but only a few can deal with the type from SMPS.
Optical connections (when the power supplies are completely isolated from each other) CAN completely block all forms of leakage, it is extremely effective. Optical takes care of leakage, but does not deal with the second mechanism.
Clock phase noise
Phase noise is a frequency measurement of "jitter", yes that term that is so completely mis-understood in audio circles that I'm not going to use it. Phase noise is a way to look at the frequency spectrum of jitter, the reason to use it is that there seems to be fairly decent correlation to sound quality. Note this has nothing to do with "pico seconds" or "femto seconds". Forget those terms, they do not directly have meaning in audio, what matters is the phase noise. Ynfortunately phase noise is shown on a graph, not a single number, so it is much harder to directly compare units. This subject is HUGE and I'm not going to go into any more detail here.
Different oscillators (the infamous "clocks" that get talked about) can have radically different phase noise. The level of phase noise that is very good for digital audio is very difficult to achieve and costs money. The corollary is that the cheap clocks used in most computer equipment (including network equipment) produce phase noise that is very bad for digital audio.
The important thing to understand is that ALL digital signals carry the "fingerprint" of the clock used to produce them. When a signal coming from a box with cheap clocks comes into a box (via Ethernet or USB etc) with a much better clock, the higher level of phase noise carried on the data signal can contaminate the phase noise of the "good" clock in the second box. Exactly how this happens is complicated, I've written about this in detail if you want to look it up and see what is going on.
The contamination is not complete, every time the signal gets "reclocked" by a much better clock the resulting signal carries an attenuated version of the first clock layered on top of the fingerprint of the second clock. The word "reclocked" just means the signal is regenerated by a circuit fed a different clock. It may be a better or a worse clock, reclocking doesn't always make things better!
As an example if you start with an Ethernet signal coming out of a cheap switch, the clock fingerprint is going to be pretty bad. If this goes into a circuit with a VERY good clock, the signal coming out contains a reduced fingerprint from the first clock layered on top of the good clock. If you feed THIS signal into another circuit with a very good clock, the fingerprint from the original clock gets reduced even further. But if you feed this signal into a box with a bad clock, you are back to a signal with a bad fingerprint.
The summary is that stringing together devices with GOOD clocking can dramatically attenuate the results of an upstream bad clock.
The latest devices form Sonore take on BOTH of these mechanisms that effect sound: optical for blocking leakage and multiple reclocking with very good clocks. The optical part should be obvious. A side benefit of the optical circuit is that is completely regenerates the signal with a VERY low phase noise clock, this is a one step reclocking. It attenuates effects from upstream circuits but does not completely get rid of them. This is where the opticalModule comes into play, if you put an opticalModule in the path to the opticalRendu you are adding another reclocking with VERY good clocking. The result is a very large attenuation of upstream effects. It's not completely zero, but it is close.
The fact that the opticalRendu is a one stage reclocking (which leaves some effects from upstage circuits) is why changing switches etc can still make a difference. Adding an OpticalModule between the switch and opticalRendu reduces that down to vanishingly small differences.
So an optical module by itself adds both leakage elimination and significant clock effects attenuation. TWO optical modules in series give you the two level reclocking .
An opticalRendu still has some significant advantages over say an ultraRendu fed by a single opticalModule, the circuitry inside the opticalRendu has been improved significantly over the ultraRendu. (it uses new parts that did not exist when the ultraRendu was designed). In addition the opticalRendu has the reclocking taking place a couple millimeters away from the processor which cuts out the effects of a couple connectors, transformers and cable. The result is the opticalRendu has some significant advantages.
An opticalModule feeding an ultraRendu does significantly improve it, but not as much as an opticalRendu. So you can start with an opticalModule, then when you can afford it add an opticalRendu, also fed by the opticalModule and get a BIG improvement.
I hope this gives a little clarity to the situation.
Shootout at the Linux Corral: AudioLinux vs Euphony
Shootout at the Linux Corral: AudioLinux vs EuphonyOn 5/26/2019 at 3:26 PM, Balázs said:
I get equally good SQ in my dual box configuration with Roon.
It sounds like you have tuned your setup perfectly to your liking and so that's what's important. As for my post, it had nothing to do with a single-box configuration being better than a dual-box configuration, it had to do with my preference for Stylus over Roon and it just so happens that Stylus only works in a single-box configuration.On 5/26/2019 at 3:26 PM, Balázs said:
On the other hand to achieve the better-than-single-box-Stylus with Roon is a rather expensive way to go and might be interesting only for those who would like to keep their Roon environment.
I completely agree with this statement. I now belong in the camp that believes that the best dual-box configuration is 2 identical boxes meaning that the server and endpoint use the same powerful hardware and both boxes are equivalently powered to a very high standard. Unfortunately, this means 2X the cost. At Munich, Pink Faun was demonstrating a dual 2.16X setup at a cost of $32k and this setup was not doing any upsampling at all (Jord prefers no upsampling with his DAC). There is definitely an elegance and economy with a single box setup that I am very pleased with.On 5/26/2019 at 3:26 PM, Balázs said:
1. Forget about the standard NUC as an Endpoint. Although it provides very good dynamics and soundstage, it 's not able to control the bass neither to give the same level of detail like a PC with dedicated interfaces.
I agree with you as I have moved on from a NUC as an endpoint for the reasons I already stated. Also, it appears you are hearing the strengths and weaknesses of a NUC exactly the opposite from how I am hearing them. My i7 NUC had 4 clocks replaced and was being powered very well by a 19V rail from my SR7 and so this NUC presented much better detail than a powerful PC with dedicated interfaces unless that PC was also being powered by an SR7. Also, this NUC exerted excellent control of not just the bass but also the midrange and treble manifesting as tremendous agility and again, this has everything to do with a low impedance power supply. Where the NUC lacked was in dynamics and soundstage and this is what a powerful CPU that is independently powered gives you. If you cannot properly power a big PC, I cannot guarantee that it will sound better than a NUC.On 5/26/2019 at 3:26 PM, Balázs said:
2. The Roon Core must have an audio grade network card (mine has a JCAT Femto NET)
3. The Roon Endpoint must have both an audio grade network and an USB card (mine has JCAT Femto NET & USB)
Once again, I agree. I think both server and endpoint in a dual-box setup should be identical. Even identical CPUs. When I was running a dual box setup, my server was using a JCAT Femto NET card and this JCAT card was being powered by an SR7 rail. My endpoint had all 4 clocks (including the LAN and system clocks) replaced by a REF10 and was connected to my DAC with a tX-USBultra which was also connected to the REF10. Both the endpoint and tX-USBultra were being powered by SR7 rails. In between the server and endpoint were 2 SOtM sNH-10G switches in a serial configuration and I can confirm that the 2nd switch had almost the same impact as the 1st switch. Furthermore, both switches were being powered by SR7 rails and both switches were connected to the REF10. And so my preference for a single-box Stylus setup over a dual-box Roon setup had nothing to do with inadequate hardware.On 5/26/2019 at 3:26 PM, Balázs said:
4. The more power phases the motherboards has the better the SQ might get. I utilize the Asrock Z390 Extreme4 which provides 12 power phases.
I am inclined to agree with you and the key word is "might." I compared 2 Asrock boards side by side and the board with the better VRM sounded better to me. Whether this is specifically because of the VRM or some other variable is not entirely clear but it would make sense that the quality of the VRM "might" impact SQ since the VRM is responsible for the stability of the power that the CPU sees. As to whether more power phases also results in better power stability, this is not always true since the quality of the power phases matter just as the number of power phases.
Your Extreme4 board is actually a 10+2 design meaning 10 power phases are dedicated to the CPU while 2 power phases are dedicated to the integrated GPU and so only 10 of your power phases have significance. Your particular board uses SinoPower SM7431EH MOSFETS which are rated at 25A each. The Asrock Z390 Phantom 9 is a gaming ATX board that uses the same 10+2 design but uses the higher-end Texas Instruments NexFETs which are rated at 40A. The motherboard I have decided to focus on for now is the Asrock Z390 Phantom Gaming ITX/ac which is a mini-ITX board and because of its smaller size, it incorporates only a 5+2 design but this is where things get deceiving because this board utilizes higher quality power phases comprised of the Intersil Smart Power ISL99227 which many consider to be among the best and are rated at 60A each, more than 2X the current capacity of those used in your board. Regardless, each of these boards should be able to easily handle something like an i9-9900K that isn't being overclocked.
This illustrates the advantage of boards designed for gaming as they generally use better parts, especially with regards to power delivery. Another example, your board is only a 4-layer design while my board uses 8-layers which in theory, provides better isolation. Also, my board, even though it is smaller than your board uses a total of 8oz of copper in the traces resulting in better conductivity. If someone is building a server from scratch, it would be worthwhile to investigate the gaming boards. They don't cost that much more.
Ultimately, I chose the board that I did because of its size. I would have loved to have gone with a full sized ATX board with multiple PCIe 3.0x16 slots, however, it has been challenging to find a fanless chassis that can house a full sized ATX board that can accommodate multiple PCIe cards without having to use riser cables (ie HDPlex, Streacom). The problem with riser cables is they are generally of poor quality as they use cheap, thin gauge conductors and so I would prefer to be able to plug cards directly into the PCIe slot but perhaps my paranoia here is unjustified. If you know of a good full ATX fanless chassis that can accommodate at least 2 PCIe cards without having to use riser cables, I would like to know.On 5/26/2019 at 3:26 PM, Balázs said:
5. The signal path between Core and Endpoint must be taken care of (REF10, audiograde switch and LAN cables etc.)
As I already stated, in my signal path between server and endpoint, I was using dual sNH-10G switches that were being clocked by a REF10 and cabling throughout consisted of either SOtM's dCBL-CAT7 or Ghent's double-shielded CAT6A along with with a SOtM iSO-CAT6 LAN isolator (essentially, an isolation transformer) and so I feel my signal path was pretty well taken care of. I even introduced optical cabling between the 2 switches but ultimately preferred the SQ of copper cabling better. What is surprising is that all of this stuff is just as important with a single-box setup even though Stylus buffers files fully into RAM before playback. People will view this comment skeptically but I am convinced no one fully understands how a network impacts SQ. It's definitely not just about RF noise in the line or leakage current.On 5/26/2019 at 3:26 PM, Balázs said:
6. Both(!) the Core and the Endpoint have to be Euphony Roon servers. Yes, even on a bridge the Roon server software sounds better. Therefore two full Euphony licences are needed, unfortunately.
I actually own 2 full Euphony licenses since the less expensive Endpoint license wasn't available when I bought mine. Also, I was not successful in running RoonBridge on the endpoint and so I used RoonServer on both machines just like you are. While I cannot claim that 2 instances of RoonServer sounds better than RoonServer + RoonBridge, I know I prefer the SQ of Stylus. Having said that, as I own Roon, I continue to use Roon for library management because there is nothing better and then flip to Stylus for playback. Fortunately, it's not hard to do.On 5/26/2019 at 3:26 PM, Balázs said:
7. The client connection type must be Roon Bridge. No StylusEP, no Squeezlite.
I presume you mean RoonServer since you already stated you don't like RoonBridge. Personally, I find StylusEP sounds better than either SL or RoonBridge but fortunately, Euphony offers you the choice of either one and it's fairly easy to switch. In the end, my preference for Stylus has more to do with the balance of qualities it offers than any one property and it's obvious that what works for me may not work for someone else.
Audiolinux Server configurations, Software, Hardware, and Listening Impressions1 hour ago, lmitche said:
I can't remember the details but it is unamibiguous that it is disabled, if it is disabled successfully.
Thanks for the command. I get this:
[[email protected] ~]$ numactl --sho
physcpubind: 0 1 2 3
No NUMA support available on this system.
The new kernel (with NUMA disabled) sounds really good here on a NUC7PJYH1.
Expert config in AL
Audiolinux Server configurations, Software, Hardware, and Listening Impressions
Menu 109 with new Expert Menu:
1 "Minimize your system"
This is a custom AudioLinux script for disabling automatically some services and some kernel modules. Please use with care. You can list all loaded modules with the command
and all enabled systemd services with
systemctl list-unit-files --state=enabled
2 "Realtime expert configuration"
After pressing Yes you can edit the realtime special configuration script
This is really for experts. Please select No if you are not sure what this is
3 "Disable realtime expert configuration"
4 "Alsa system wide configuration file"
After pressing Yes you can edit the Alsa system wide configuration file
You can save with F2. Pressing F10 you will exit from editor and the file will be copied to /etc/asound.conf
As for CPU governors, Audiolinux does not really need to add balanced, conservative, powersave, etc. since there is the custom option already in the menu where you can define minimum and maximum CPU frequency manually (Turbo ON or OFF)
A novel way to massively improve the SQ of computer audio streaming
A novel way to massively improve the SQ of computer audio streaming
It's been a long time and so forgive me if I have a lot to say. As I indicated in one of my last posts back in 2018, I wouldn't post again unless I felt I had something meaningful to offer. I have received a lot of inquiries about the status of my audio setup and I apologize as I have not responded to most of these inquiries due to time constraints. To be honest, since I started this thread back in 2017, my system has been in continual flux but the time has come hopefully to settle down for awhile and so I felt it was finally time to share the status of my setup and to offer some personal observations based on my comparison testing. This marks my first public post since CA became Audiophile Style. I miss just being able to say "CA" and having the audiophile community know what I am referring to.
As always, what I have to share are personal observations and opinions based on my sensitivities and personal preferences. I have no financial motivations. I have 2 systems at home and what works well in one system doesn't always work well in the other. In other words, YMMV.
As for my 2 systems, they are as follows:
In my home office, I have a pair of near field desktop monitors that were custom made for me by Louis Chochos of Omega Speaker Systems based in Connecticut. They cost me <$2k and they remain one of the highest value purchases I have ever made. They are comprised of Louis' high efficiency, crossover-less Alnico drivers and excel in delicacy, nuance, and tone. I am continually amazed by how well these drivers express the subtlest textures. I used to own a pair of custom made Voxativs that were even more resolving and oh so velvety smooth but also a tad bright and not ideally suited for long term near field listening and so those are now gone. Paired with a fast JL Audio Fathom F110 V2 subwoofer and driven directly by a Chord Hugo TT2 / Hugo M-Scaler, I find this Omega setup to be very transparent, highly resolving, non-fatiguing, and transfixing. I own or have owned many fine headphones over the years (SR-009, HD800/HD800S, HE-1000 V2, Abyss 1266, LCD-4, Focal Utopia, Dharma D1000, TH-900) and when my children were living at home before they moved off to college, I found myself forced to headphone listening at night but my headphones have been collecting dust for some time because I have found my Chord DAC directly driving these Omegas to be that much more engaging, even at low listening volumes.
With my youngest son having moved out of the house and onto college late last year, my big listening room is where I do most of my listening these days. This room has been home to a lot of different speakers over the years and for most of the previous year, I was using a pair of large Martin Logan Renaissance 15A hybrid electrostats. Typical of line source, dipole speakers, these Martin Logans cast a giant ambient sound stage and are wonderful for recreating large venue performances at full scale. Driven by a Pass Labs X350.8 amp and XP-22 preamp, this setup excelled in beauty but ultimately lacked in resolution and transparency even when fronted by my Chord DAVE DAC with M-Scaler. These giant electrostat panels, while very fast and with exceptional clarity, created a softly focused image and so point sources like a solo cello or a solo vocalist sounded too diffuse, too tall, and too wide for my tastes, regardless of speaker position. As I made tweaks in my upstream setup, I could hear changes, however, I could hear these changes much more succinctly with my inexpensive Omegas and so for someone who values transparency, this drove me nuts. Imaging and focus improved considerably with a switch from Pass Labs amplification to a more resolving Luxman M-900U/C900U and ultimately to Soulution amplification. Imaging and focus further improved dramatically when I moved from a Shunyata Triton V3 to a Sound Application TT-7 line conditioner by Jim Weil but despite these improvements, I eventually came to the realization that I was not meant for line source speakers like electrostats or planars like my brother's Maggies. Don't get me wrong, these are wonderful types of speakers with tremendous appeal but my time with the Martin Logans have better educated me as to the type of listening I prefer and so I have moved on to point source speakers once again in my large listening room, specifically the Wilson Alexia 2s.
I offer the above details for the following reason. It's important to understand the context by which my observations and opinions are based and the priorities that I value as your priorities may be different. I'm guessing that we all claim live music as our reference and yet it's interesting to see how we each vary in our approach to achieving the recreation of a live performance. Because today's technologies remain incapable of faithfully reproducing a live musical performance and because we each are constrained by a budget, it helps to know what type of listener you are to understand which compromises you should accept above others. My goals, simply stated, are resolution and transparency in the absence of harshness. I aspire to beauty, organic, natural, and musical just like everyone else but these qualities are more in the eye (or ear) of the beholder and are not easy to define. I tend to run from things that are described as warm (meaning slow), thick, heavy, euphonic, or lush. Not that I don't like warm or lush, I just don't want everything sounding warm and lush if warm and lush aren't in the recording. Just not me. I find that if you can successfully address harshness at every step in your chain, there's usually no need to embellish or to colorize.
Moving on, here's a story about listening that some will find interesting. There are 2 types of listening that most of us do. There is critical listening where we focus on what we are hearing hoping to dissect the qualities of a performance, recording, or some piece of equipment and then there is pleasurable listening where the goal is to relax and to escape. Given the choice, I'm sure most of us would prefer the latter. Almost a year ago to this day, I hosted Rob Watts (who needs no introduction), Jay Luong (lead reviewer for AudioBacon.net), and Jim Weil (owner of Sound Application and designer of SA's line conditioners) in my home for a series of listening tests. What I respect about these 3 gentlemen is that they are each highly educated and accomplished electrical engineers but also passionate music lovers. It has been my experience that most engineers aren't true music lovers, don't know how to critically listen, or worse, they're closed-minded with fixed ideas about how digital electronics are supposed to sound based on theory alone. Not these gentlemen.
Rob had come all the way from Wales and brought along prototypes of M-Scaler and Hugo TT2 for us to listen to and for the better part of 5 days, we conducted a series of critical listening tests. We did a lot of listening, both sighted and blinded, to Rob's prototypes, to different DACs, amps, cables, line conditioners, and speakers. While it was a lot of fun to hang out with these individuals, our listening sessions were often more tedious than enjoyable. We listened to select portions of Mahler's 1st symphony so many times that I couldn't listen to this symphony again for months. What I found fascinating but not surprising is that while we each heard differences, we heard them differently and had different preferences. Jim Weil had a strong aversion to anything bright. Rhodium and silver-plated copper are Jim's enemies and he could sniff them from a mile away. Jay Luong was especially sensitive to tone and timbre and would gladly trade detail for warmth. Rob was particular to depth. An organ that was 30 feet away had to sound as if it was 30 feet away. Everything else was secondary and so not surprisingly, his DACs excel in depth accuracy. My sensitivities are more toward transient response and the air and space around voices and instruments. I also crave variation over harmony. Even 2 Stradivariuses should never sound exactly the same and a system that makes them sound exactly the same simply isn't transparent enough. We are who we are and so gear will speak differently to each of us.
Single box server vs server + endpoint
There are compelling examples to support either strategy. In the perfect world, I would love to have the convenience of a single box solution but I have yet to hear a single box solution that I prefer over a multiple box solution. With multiple boxes, there is the option for finer level tuning which I will discuss further but ultimately, it comes down to how well each box can be powered. If all I can come up with is a single good PSU, than a single box server is all that I will aspire to.
Those who have followed this thread from the beginning know that its original goal was to figure out ways to improve endpoints like the sMS-200 or microRendu. It's amazing how endpoints have evolved since January 1, 2017. The concept behind the endpoint was to create a low noise rendering device to interface with the DAC that isolates against noise generated by a powerful computer server. Low noise was the rationale for using low power processors like ARM-based CPUs and even Celerons. It was also the premise behind the avoidance of other noisy components like SSDs and switching power supplies. While some of these principles have passed the test of time, others have not, at least not to my ears. Low power CPUs are not necessarily what sound best. How else can I explain how an i7 NUC board with its noisy switching regulators can sound better than an ARM-based sMS-200ultra or ultraRendu? How else can I explain how an i7 NUC can sound better as I ramp up CPU clock frequency? It's completely counter-intuitive but it suggests that aside from noise, there is performance to consider and sometimes performance requires power and sometimes performance is more important than low noise. To my ears, an i7 has the potential to sound more spacious, fuller, and more dynamic than a Celeron or ARM-based CPU and the number of physical cores, CPU frequency and size of the CPU cache seem to matter. The downside of the i7 is that they are potentially more challenging to power well.
Thus far, I have tested 5 NUC boards comprised of either a Celeron, i5, or i7 CPU and ranging from 2-cores to 4-cores and from 2MB of standard CPU cache to 8MB of SmartCache. The best sounding board I have heard thus far is the NUC7i7DNBE based on an 8th generation i7 that I first discussed a few months ago.
I am open to the idea that a more powerful, non-NUC device could sound even better as an endpoint but once again, powering it would be the challenge. Here is the Asrock IMB-1215 which will be released to the U.S. in a few months.
It is a mini-ITX board that can accommodate an 8th or 9th generation i7 and with an open PCIe slot that can be powered by a single 19V rail and so I find this board to have intriguing possibilities.
SOtM has reportedly designed an i7-based motherboard from the ground up with high level clocks that can be powered by a single 19V PSU. I very much look forward to trying out this board.
The NUC7i7DNBE when purchased as a board are more difficult to come by and also more expensive at a price of around $650 USD. Ironically, the NUC7i7DNKE NUC kit, which houses a NUC7i7DNBE board within a standard Intel chassis are much more readily available and cost $100 less. I just purchased one a few weeks ago and it took all of 5 minutes to explant the NUC7i7DNBE board from the chassis.
The NUC7i7DNBE has the option of being powered by a 12-24V PSU and higher voltage DEFINITELY sounds better to me. Bigger and more dynamic. It also has the option of being powered via either a 2.5mm x 5.5mm barrel connector or 2x2 mini Molex connector. With 2 NUC7i7DNBE boards on hand, I was able to recently do a direct A/B and powering via the 2x2 Molex connector sounds very slightly better.
As for power supplies, I could not successfully power a NUC7i7DNBE board with a single LPS-1.2 at 12V even though my Kill-a-Watt meter suggests this board never consumes more than 8 watts during bootup. I could get it to post to the BIOS screen but even with Turbo and Hyperthreading turned off and with only 4GB of RAM installed, I could not successfully boot into AudioLinux from a USB stick. I purchased a special serial Y-cable from Ghent Audio and this allowed me to combine two LPS-1.2s and this worked. The cable that I had Ghent make for me is comprised of high quality Neotech 18g 7N OCC copper and so I spared no expense to get it as I was very excited by the prospect of being able to power the NUC with 24V using two LPS-1.2s set at 12V each.
Unfortunately, for reasons that remain a mystery, I could not get this to work. Each time, one of the LPS-1.2s would start to blink red during the boot process and turn very hot. I own three LPS-1.2s and regardless of which one I swapped in, one of the LPS-1.2s would start to blink red and it was not always the same LPS-1.2 that would give out. When I kept one LPS-1.2 at 12V and switched the other to 9V (12V + 9V = 21V), this somehow worked and the NUC booted just fine. 19V (12V + 7V) also worked. The problem with using two LPS-1.2s in serial is that they don't sound good at all and this was very disappointing. In fact, I found better SQ powering the NUC with the 19V rail from my HDPlex which came as a surprise. It appears that using 2 or more LPS-1.2s in serial is not a good thing to do. The NUCi7DNBE also likes headroom and the LPS-1.2's 1.1A of headroom is a limitation. To hightlight the importance of headroom further, a 12V SR4 sounds very good powering this NUC but a 12V SR7 with its greater headroom sounds even better.
Beyond headroom, the avoidance of any voltage drop is also very important and a 12V DR (double regulated) SR7 sounds better yet although I am getting my very best SQ with this NUC powered by a 19V SR SR7 rail. With this NUC powered by the 19V rail from an HDPlex 400W ATX LPSU, while the SQ is not in the same league as an SR7 or even the SR4, it is much less harsh than the stock 19V switcher that Intel provides and so the HDPlex is more than just a passable option. The JS-2 or a bespoke PSU from either Sean Jacobs or Adrian Wun at TLS could be even better options but at a cost. As I stated above, the downside of the i7 is that they are potentially more challenging to power well but I do feel the rewards are there.
As for clocking, not surprisingly, this makes a significant and worthwhile difference. I had the TLS DS-1 on hand for a few months and it's single OCXO reportely replaced 3 clocks on this board (system, Ethernet, USB).
While much has been made about the mediocre performance characteristics of the Connor-Winfield OCXO that Adrian at TLS likes to use for all of his products, the removal of 3 noisily powered clocks from this board and replacing it with a cleanly powered clock even if that clock is of suspect performance has paid significant dividends. I had a stock NUC7JYH board with its Celeron J4005 CPU on hand and it is the very same board and CPU that Adrian used for the DS-1. Direct A/B revealed a significant uptick in detail clarity and spaciousness with the DS-1. Compared against my stock NUC7i7DNBE, this superior detail clarity was still very much evident although I found the i7 NUC to sound more spacious still. Regardless, I heard enough to know that it would be worthwhile to send my i7 board to SOtM for clock replacement and indeed, it has been worthwhile. To have replaced the 4 replaceable clocks on this board has resulted in a notable decrease in harshness resulting in cleaner transients, better definition, more accurate timbre, and a greater sense of space.
However, the benefits of clocking have to be placed in proper perspective. To my ears, the power supply still makes the bigger difference. I have the benefit of having 2 NUC7i7DNBE boards on hand (one is stock and the other has been reclocked) and this has allowed me to make careful A/B comparisons. With the stock i7 NUC powered by a 19V rail from my SR7, I am getting better SQ overall than the SOtM-modified NUC powered by the 19V rail from the 400W HDPlex. If forced to choose, the choice would be easy.
With my inaugural post on this thread, I had described my observations about how LAN bridging resulted in increased transparency of the endpoint to the upstream server. While the mechanism for why this improves transparency remains unsettled, with bridging, it was clear to me that the quality of the server mattered. With the release of the SOtM sNH-10G switch last year, I reported that I was no longer able to differentiate between the Zenith SE and my noisy 12-core Xeon-based Mac Pro when either one was used as a Roon server. But that was before AudioLinux came into the picture which allowed me to play with CPU frequency settings and this has made all the difference. The Zenith SE houses a powerful and low noise PSU but it is mated to a very weak Celeron while my Mac Pro utilizes a noisy switching PSU mated to a much more capable 12-core Xeon with a giant CPU cache. Without any OS manipulation of the CPU, cursory A/B comparisons between the two yielded no significant difference to my ears suggesting that the sNH-10G had effectively blocked the higher noise that was being generated by my Mac Pro.
But what would happen if I pushed my Mac Pro's CPU clock from it's base idle frequency to max turbo levels? Of course, this is the beauty of AudioLinux and it has proven to be a very useful learning tool. With higher CPU frequency, dynamics goes up but at the expense of subtlety and nuance and with progressively increasing harshness and the sNH-10G is incapable of completely isolating against these changes. I have read commentary that the upcoming opticalRendu will supposedly be completely immune to the virtues of the upstream server. I suspect this is probably the goal of the upcoming EtherREGEN also. Well, I believe this is both naive and wishful thinking and so people will need to adjust their expectations appropriately or else they will be disappointed.
I say this because I currently have 2 SOtM sNH-10G switches in my possession and I can tell you that while 1 switch makes a very big difference, 2 switches make an even bigger difference.
What is nice about these switches is that they have both standard RJ-45 Ethernet ports as well as optical Ethernet ports and so with these switches connected by a single-mode fiber optic cable, here is what I found.
With the optical cable compared against a 50+ foot Blue Jeans Cables CAT6A Ethernet cable, the noise floor with the optical cable was noticeably lower and there is a clear preference for the optical connection. With the optical cable compared against a 22-foot Belden CAT6A cable with JSSG360 shielding that was made for me by Ghent, the gap was smaller but there was still a slight preference for the optical cable. With the optical cable compared against a heavily shielded 1.5m SOtM dCBL-CAT7 cable, the noise floor was equivalent (at least to my ears) but tonality with the SOtM cable sounded more natural. The optical cable sounded a touch thin and bright in comparison and so in this instance, the copper Ethernet cable sounded better. Regardless, in each and every comparison, optical or otherwise, if I varied CPU frequency, I could hear differences in the server. The server still ABSOLUTELY matters and this is because it's not just about noise, there is also the matter of performance and it would appear that RoonServer likes horsepower. At this time, the delta I am hearing from my best server setup to my worst server setup is about the same as the delta I am hearing from by best endpoint setup to my worst. In other words, my current stand is that the server matters as much as the endpoint.
My testing has shown me that modern CPUs are preferable to older generation CPUs A few generations ago, an i7-4790 yielded a TDP of 84w with 4-cores/8-threads, 8MB of SmartCache and CPU turbo speeds reaching 4GHz. Today, an i7-8700T yields a TDP of only 35w but offers 6-cores/12-threads, 12MB of SmartCache and CPU turbo speeds reaching the same 4.0GHz. Basically, more performance with less noise and A/B comparisons between these 2 CPUs reveal exactly that. An 8700K houses potentially even greater performance with a max turbo rating of 4.7GHz using better binned parts according to Intel and so I decided to compare this against the 8700T.
Ultimately, it didn't seem to matter since I heard no benefit clocking either of these CPU beyond 3.8GHz when powered by the HDPlex 400W ATX LPSU due to harshness but who knows what would happen if I had a better ATX PSU on hand? I have explored such a PSU with both Adrian Wun of TLS and Sean Jacobs but the cost of a "no compromise" ATX PSU from these gentlemen will run somewhere in the $4-5k range. Regardless, the CPU matters and if I were to build another server, I would probably go for a standard i7-8700 since they're more readily available and less expensive then either the 8700T or 8700K.
My testing has shown me that the motherboard matters also. Borrowing a page from Pink Faun's book that gaming boards can sound better, I decided to compare a standard Asrock Z370M-ITX/ac motherboard against an Asrock Z390 Phantom Gaming-ITX/ac motherboard.
First of all, I only looked at Intel boards since it wasn't clear to me that an AMD board was compatible with Optane memory. Second, I specifically targeted the Z370/390 chipset because these chipsets were capable of running the latest generation i7s (both 8th and 9th gen). The Z390 board happened to be designed for gaming meaning they were engineered to be overclocked. As such, this gaming board has an 8-layer PCB with a whopping 8oz of copper to maximize conductivity and to enhance the ground plane. This board also has beefier heat sinks to improve heat dissipation and a more robust VRM (voltate regulator module) to make sure the CPU is never starved of current. While the differences weren't large, the gaming board had more substance to the sound stage with greater authority to its presentation but not to be completely outdone, the Z370 board had a touch better finesse and subtlety. The point is that even these more minor differences were easily audible in the server.
SSD vs Optane
Just for kicks, I decided to compare a 58GB Optane card against a Samsung 500GB 960 EVO NVMe SSD in the M.2 slot of the Asrock board. This was a very brief comparison because it didn't take long to realize how much more harsh the SSD sounded even with all of my isolation schemes in place. It's amazing how many commercial music server manufacturers continue to use SSD drives in their servers as if powering an SSD cleanly somehow addresses this harshness when it does not, at least not to my ears. I suppose you get used to the harshness over time but an SSD is about the worst thing I can imagine putting into a music server with the super fast NVMe drives sounding the harshest of all. As some may recall, in previous testing, I found the older, slower SATA II SSDs (especially the SLC variety) to sound less harsh then the newer, faster SATA III SSDs although the faster SATA III SSDs made music sound more alive and more immediate and so there was a trade off. It would appear that the Optane cards have the best of both worlds and so hats off to Larry for introducing us to the Optanes.
I have read comments about how running AL in memory doesn't result in much improvement in SQ except for a slight improvement in smoothness. The point here isn't just running AL in memory for the sake of latency but also to be able to completely avoid using an SSD in the server. The Optane seems to be a nice compromise if capacity, low latency, and low noise are desired since Optane behaves more like RAM than an SSD. For those with a large Roon database who are looking for a brisk user experience with Roon, an Optane drive may be preferable to a USB stick for the Roon database. For sure, it would be preferable to an SSD. From a SQ standpoint, is an Optane drive preferable to having more RAM (16, 32, or even 64GB)? I'm not sure although according to Intel, a 58GB Optane drive only consumes 3.5w and so it would appear to draw much less current than RAM as a 3.3V device.
I haven't done much testing with memory to see what is ideal. Apparently, Sound Galleries has found that RAM timing matters with respect to SQ but they are keeping mum about what they found to be the ideal RAM timing for their servers. It made sense to me to target low latency memory and I have had good success as far as compatibility with Kingston's HyperX DDR4 for either Asrock board and for the i7 NUC but I haven't yet played with RAM timing. As I previously posted, I have not been able to distinguish any difference in sound between 4GB vs 8GB or single channel vs dual channel memory and I believe these findings are supported by the findings of others. I have been asked about using as much as 64GB of memory in the server. I have to wonder what the benefits of using large amounts of memory are except for the purposes of a RAM drive to store music since AudioLinux doesn't even occupy 4GB when ramrooted. According to Crucial, both DDR3 and DDR4 memory consume about 3 watts per 8GB. That means 16GB consumes 6 watts and 64GB consumes 24 watts. As 1.2V devices, that represents quite a bit of current draw. In fact, 24 watts is more than the whole i7 NUC board consumes and while RAM isn't as noisy as an SSD, I have to guess that this amount of consumption is going to result in increased noise in the ground plane. While storing or caching music files in RAM seems to lead to a slight increase in SQ with AL (a touch more smoothness), I would have to guess that any gains made would likely be offset by the noise created by that much RAM. I think even 16GB offers no SQ advantage for 2-channel audio, even with OS's that pre-fetch all streaming music into memory (i.e. Euphony).
Ethernet - JCAT Femto Network Card
I've already provided my experience with optical Ethernet in the SOtM sNH-10G switch and I suspect it would apply to a LAN card one might use in a server also. With long runs of cable, optical seems to provide an advantage but with short runs, optical has potentially no advantage or actually sounds worse. This suggests to me that much of the noise that optical is mitigating is coming from the Ethernet cable and not the server and that with short runs of Ethernet cabling or with well-shielded cabling, the higher amounts of jitter that optical creates now becomes its Achilles' heel. Regardless, even in the best case scenario where optical imparts a benefit (i.e. when compared against a 50+ foot run of Blue Jeans Cables CAT6A), the improvement pales in comparison to what I am hearing with the JCAT Femto Network card. The JCAT card is a game changer.
I looked at other cards, specifically TLS's LAN card with OCXO but I decided to go with the JCAT card because it had 2 Ethernet ports that I could bridge and because it was the only card I could find that I could independently power with an outboard PSU. Adrian at TLS told me his network card had redundant linear regulation on board and so bus power should sound as good as an outboard PSU but I refused to believe it. It just so happens that the JCAT card has the option of either being bus powered or being powered by a 5V outboard PSU and so it was easy to do this comparison. No surprise, this card when powered by a 5V SR4 sounds incredibly better than bus power. What did come as a surprise is that the LPS-1.2 is not a good choice for the JCAT card. To power both Ethernet ports, you need to feed this card at least 1.5A according to Marcin although the LPS-1.2's 1.1A is enough to power one of the Ethernet ports. The problem here is you not only lose the option of bridging but SQ was just not great because the LPS-1.2 sounds like it's working too hard just to power the one port. The noise floor is low and articulations are clean and clear but they sound weak and thin. Even the 5V port from the HDPlex sounds better overall.
Not to knock the LPS-1.2 since I regard this PSU very highly and in fact, I own 3 of them but I find that components that draw anywhere close to it's max rating of 1.1A aren't going to sound that great powered by the LPS-1.2. Also, there are some components that just benefit tremendously from headroom. A good example is the sNH-10G switch. The LPS-1.2 powers it fine but it doesn't power it great. This switch really scales with a 12V DR SR7. At a minimum, I would suggest an SR4, otherwise, you may feel underwhelmed with this switch. I imagine the upcoming EtherREGEN will be a better match for the LPS-1.2.
Chassis - HDPlex H3 V2
This proved to be an excellent chassis in many ways for my intended build. First, it is a fanless chassis capable of dissipating 80w of heat according to HDPlex. Testing with an i7-8700K running for extended periods at a fixed 4GHz showed that this case could handle that level of CPU just fine. At no time did CPU temps climb beyond 65 degrees C, however, at that speed and at those temps, harshness was quite evident. Second, and more importantly, the design of this chassis allowed for the utilization and easy comparison of different outboard ATX power supplies. The key word here is outboard. Despite the greater impedance that comes with having to use long umbilical cabling with an outboard PSU, I have found digital components to be very sensitive to vibration and to house a large vibrating transformer in the same chassis as the server is fundamentally against my design philosophy and among the chief reasons I struggle with single-box servers, at least on theoretical grounds. My former Innuos Zenith SE did a good job isolating the impact of it's large 300VA transformer on the rest of the server but as we know, when it came time to build their no-compromise Statement server, Innuos felt they had to separate the PSU from the main chassis. If there is a downside to the H3, it's build quality is not to quite to the same level as the fanless cases by Streacom but, nonetheless, it is a solid chassis and nowhere as resonant as many of the Akasas. Like with all my digital gear, I find that this chassis benefits from good vibration dampening footers as they result in cleaner transients with tighter image focus.
One mistake that I did not make with this server that I made with my previous server is the use of EMI paper. With my previous server build, for those that recall, I lined the whole chassis with EMI paper with the idea that if a little is better, a lot is better still. Well, I found that too much EMI paper kills the sound and has the potential to sound lifeless and overly damped. It turns out playing with the harmonic frequencies even at frequencies beyond the audible frequencies (>20kHz) has a very audible effect and so with this build, I have purposely shied away from using EMI paper. If another used Tranquility Base shows up on Audiogon, that is what I will preferentially target.
PSU - HDPlex 400W ATX LPSU
I was so impressed by my i7 NUC endpoint with its clocks replaced and powered by a 19V SR7 that I wondered what it would sound like to have the same i7 NUC with the same clocks replaced and powered by a 19V SR7 as the RoonServer. Well, I tried this and it resulted in an exceptionally clean sound with wonderfully crisp and clear articulations and incredible detail resolution but somehow, compared against the either the 8700T or 8700K, the i7 NUC as a RoonServer lacked soul. The more powerful machine sounded more dimensional, airier, fuller, more authoritative, and more real. I went back and forth because each had its appeal but ultimately, the more powerful machine won out as my preferred Roon server.
This led me to wonder how much of what I was hearing was the more powerful CPU vs the PSU. Was the HDPlex 400W ATX PSU really that good? I decided to power the i7 NUC with the 19V/10A lead from the HDPlex and even using a custom JSSG360-shielded OFC DC lead made for me by Ghent, compared against the 19V SR7, the HDPlex was a fairly significant step backward. Noise floor was higher, bass sounded bloated and ill-defined, mids sounded a bit muffled, and treble sounded rolled off. Not to say the HDPlex sounded horrible (as I previously mentioned, the HDPlex is actually more than just passably good), it's just the 19V SR7 is that much better.
This outcome is a good example of performance being more important than low noise. When I first described my experience with an unmodified NUC (with AudioLinux) sounding better than a microRendu or sMS-200, people wondered how devices that were built from the ground up for audio playback with high level clocks and low noise regulators could be bested by a cheap NUC. My only explanation is that low power CPUs like ARM-based processors leave a lot of performance on the table and with Roon Core or RoonServer, I believe this all the more true. It turns out horsepower isn't beneficial only for upsampling with HQP. I'm sure this comment will stir a lot of debate and even heated comments but unless someone can propose a better answer, this is what I'm going with.
Some will ask why I didn't go with the 200W HDPlex LPSU when this server consumes no more than about 50 watts max and more typically about 30 watts. First, I wanted as much headroom as possible. After speaking with Sean Jacobs, he was very much in favor of over-provisioning any ATX PSU he would design for me to avoid core saturation. In fact, his design incorporated a 300VA transformer even though I told him I was expecting my server to only consume about 30-35 watts. Second, I wanted to avoid a DC-ATX converter. Having purchased and tried the HDPlex 400W DC-ATX converter already back in 2017, I was less than impressed with its performance even when powered by the 19V rail from my SR7. Sean was also willing to share a few things about what he had learned regarding ATX PSUs (as we know, Sean designed the PSU for both the Zenith SE and the Statement). According to Sean, the 5V rail is extremely important and requires high current for optimum performance (ideally 4-5A) even if you're not planning on powering any 5V devices such as an SSD. Apparently, many parts of the motherboard utitilize this rail and unfortunately, the 5V rail on the 200W HDPlex outputs only 2A. Even if I wished to bypass a DC-ATX converter and create special cables to directly power a motherboard, 2A of output, at least according to Sean, would be less than ideal.
As I started doing my listening tests with the HDPlex 400W ATX LPSU, I compared it against a Corsair RM650X ATX PSU.
I specifically chose this 650w Corsair because it had comparatively low ripple noise measurements and very good voltage stability and indeed, before the arrival of the HDPlex, I was quite impressed by its performance. I wasn't sensing any of the fatiguing harshness I had heard with my Mac Pro or HP workstation. Against the HDPlex, the Corsair was no match, however. Noise floor was even lower but the sound signature was also fuller, more dynamic, and harmonically richer.
As I was building servers for others, I had the good fortune of having 2 HDPlex 400W ATX LPSUs on hand and so I got a chance to use both at the same time.
I used one HDPlex to power the motherboard via the 24-pin ATX connector and the other HDPlex to power the CPU via the 8-pin EPS connector using custom shielded cables made for me by Ghent. This resulted in further significant improvement -- even better low end dynamics and a more substantial sound stage. Is it worth another $800 to buy a 2nd HDPlex? I have to say that it's a very tempting proposition and something worth considering because the difference is there. Because I had an older 200W HDPlex on hand, I decided a few days ago to try powering the CPU from the 12V lead of this HDPlex using the same custom XLR cable that Ghent made for me and unfortunately, with the 8700K, the 400W HDPlex sounds more dynamic by itself. I'm sure that a bespoke ATX PSU built by Sean or Adrian would be even better but for $800, I am very impressed with the HDPlex 400W ATX LPSU.
X Factor - Furutech Nano Liquid
This needs to be filed under the "needs to be heard to be believed" catergory. I received a tip awhile back from a trusted friend to give the Furutech Nano Liquid contact enhancer a try. Those that know me know that I use a full loom of High Fidelity Cables everywhere except for USB and that's only because High Fidelity Cables don't make USB cables. Anyway, as good as HFC cables are, I was very impressed by how this Furutech contact enhancer, which is basically a proprietary formulation of silver and gold particles suspended in squalene oil, resulted in an even smoother, richer, and more liquid presentation. Yes, I know, it wreaks of voodoo but I loved what I was hearing.
For my initial server build using the 8700T CPU, I decided to cautiously apply this contact enhancer to the CPU, RAM, Optane card, JCAT card, and the ATX and EPS connectors. Upon completion of my build, I immediately tried powering on this server but it wouldn't power on. My first thoughts were that this contact enhancer had somehow caused a short or ruined the board but I decided to wait 24 hours to see what would happen. To my relief, after 24 hours, the board powered on but the board was only seeing one 4GB RAM stick and not the other. I switched around the sticks and it became clear that the RAM itself was not the problem but slot 2 on the motherboard was somehow not functioning or at least not detecting RAM that was inserted into this slot. Was this a defect in the board or a result of the Furutech Nano Liquid? I'm not sure but I wasn't bummed long because the SQ I got from this server was beyond what I was expecting. Was it the CPU, the JCAT card, the HDPlex ATX PSU, or the Furutech liquid that was responsible for the magnificent sound? It was impossible to know for sure.
I was asked to build a second server for a friend similar to this first server. With this second server, I strongly suggested the Asrock gaming ITX motherboard and the i7-8700K. As I mentioned above, I believed this particular motherboard should, in theory, sound better than the first board because it had more layers in the PCB, more copper in the ground plane, better heat sinking, and a more robust VRM. Because the 8700K was structurally identical to the 8700T, they should operate similarly but because the 8700K used better binned parts, I reasoned that the 8700K could potentially perform better or at least more durably since I would intentionally be running this CPU well below it's rated peak capability of 4.7GHz. Not wanting to risk the same headache, I elected not to apply the Furutech Nano Liquid to this build, at least not initially. The machine powered up fine and with what I thought were appropriate expectations, I was quite let down by what I heard. It sounded very dynamic but there was a dryness and a harshness to the sound that I wasn't hearing with my other server. I quickly moved back to my other server and this was immediately confirmed. My other server sounded smoother, more liquid, and harmonically more pleasing.
Despite 100 hours of burn in, the new server failed to come close to what I was getting with my other server and so I had to let my friend know these findings. I told him I couldn't say for sure but I didn't think it was the 8700K that was the culprit since I was getting the same temperature readings based on the frequency I was running compared against the 8700T. I postulated that it had to be either the motherboard that was the culprit or else the Furutech Nano Liquid was the missing X-factor. I offered him the option of applying the Furutech Nano Liquid but he would have to accept the risk that this liquid could damage his motherboard. He agreed and so I tore down this machine and started over, this time more copiously applying the Nano Liquid to the CPU, Optane card, RAM, JCAT card, and ATX/EPS connectors. Since I was given the green light, I figured if we were going to go down and be forced to buy a new motherboard, we might as well go for a home run. Well, after application of this Furutech liquid, this server did improve...dramatically...and it was noticeable immediately. If I have to guess, it is with the CPU where this liquid makes the most difference.
Operating System - AudioLinux vs Euphony
It would be a gross understatement to say that I was merely pleasantly surprised when I first heard a NUC running AudioLinux in RAM and I have Adrian of TLS to thank for this. What is just as impressive is how open-minded and responsive Piero has been to suggestions and so it has been amazing to see how AudioLinux has evolved in such a short amount of time. Rajiv and I had asked Piero to allow us the ability to specify CPU frequency and the ability to tune the CPU frequency has been extremely educational. It also allows for the utilization of just about any CPU since the user is no longer tied to just the base frequency or the peak turbo frequency of a CPU. Regardless of whether you're using an 8700T, 8700, or 8700K, you can dial in almost any frequency from 400MHz all the way to >4GHz and so with just about any CPU, it becomes a matter of the number of physical cores and the size of the cache.
As you go up in frequency, dynamics improves but it is at the expense of subtlety and nuance and at some point, harshness will set in. I have found that harshness sets in sooner with lower quality PSUs. With the HDPlex, I can push to 3.8GHz with the 8700T/K before the harshness gets unacceptable. With the SR7 powering the i7 NUC, I can push as far as the i7-8650U will go (maxes out at 3.8GHz even though Intel claims it can go to 4GHz) and unacceptable harshness never really becomes an issue but this depends on the server CPU frequency. What is fascinating is that with my large orchestral tracks, I had a preference for running the server at 800MHz which gave me my very best detail while running the NUC endpoint at 3.8GHz which gave the sound more body. With heavily amplified rock, I found the server sounded best at 3.2GHz and with the NUC endpoint at about 2.2GHz. It seemed that with the server running at a lower CPU clock speed, the NUC endpoint was receiving a cleaner (less harsh) signal that it could then amplify more agressively without penalty. With the server running at a higher CPU clock speed, there was more body to the sound but as I advanced the NUC's clock speed, harshness became evident much sooner. Regardless, to have this level of control has been amazing and I can tell you that these preferred settings apply only to my large listening room with my Wilsons and not to my smaller listening room with the Omegas. I'm also convinced these settings would be different had I still had my Martin Logans.
This is also the beauty of the core isolation feature and being able to switch between RoonBridge and Squeezelite on the endpoint. Core isolation in my system results in a tidier and more precise sound signature resulting in tighter focus but at the expense of bloom. With my Martin Logans, I would have had core isolation tuned on in both the server and the endpoint but with my Wilsons, it sounds too mechanical and so I leave it on in the endpoint but off in the server. Squeezelite is similar to my ears. It is a cleaner and more precise presentation whereas RoonBridge can sound more uncontrolled with undersirable overhang but for certain types of music, Squeezelite can sound less natural and overly sterile. Regardless, I like the option of being able to easily switch between the two.
A couple of weeks back, I decided to give Euphony a try at the recommendation of a friend who was impressed with the upgrade from version 2.0 to 3.0. Euphony lacks the fine manual controls that AudioLinux provides and so this was an immediate red flag for me. With Euphony, there is no option to set CPU frequency, isolate cores, or bridge LAN ports but it does give the user a polished and easy to use interface. Where AudioLinux is a tweaker's dream, Euphony was designed for those looking for a more no fuss turnkey solution. Having spoken by phone with Željko Vranić, one of Euphony's programmers, he said their focus was to lower OS latency as much as possible which really has been Piero's goal at AudioLinux also but it would appear that they have approached latency differently. Željko told me Euphony makes no attempt to isolate cores or to adjust the CPU frequency since they found this made no difference. This certainly has not been my experience with AudioLinux. After comparing the two, at this time, I am getting better SQ with Euphony than AL, especially on the server, and I must say this comes as a surprise, especially since Euphony doesn't allow me to bridge the 2 LAN ports on my JCAT card. As both products utilize ArchLinux as its platform, I'm confident that AL will continue to evolve and that parity will become possible but thus far, I have been unable to configure AL to match Euphony's performance. Ultimately, competition is good for the consumer and as I now own both products, I am rooting for both to succeed.
I apologize for this War and Peace length post. It's unlikely you'll see a post like this from me again as I have grown tired of doing comparisons. Best wishes to all.
EtherREGEN: The long development and active launch discussion thread.On 1/28/2019 at 9:12 PM, greenleo said:
1. If LPS-1.2 is used to power the switch, is shunting needed?
2. Does it applies to the EtherRegen as well?
Good question. Allow me to explain step-by-step.
a) John has identified certain forms of AC leakage traveling over Ethernet cables--from computers, NAS, modems, other switches, etc.
b) If both the magnetics and PHYs of an Ethernet switch are wired in a certain way (only a small percentage of commodity switches are), AND IF that switch is grounded to AC mains, then the high-source-impedance leakage coming into that switch from other sources will be minimized and not passed between ports (which is desirable in an audio system where one would like to keep such leakage currents out of the DAC-connected endpoint).
a) For the EtherREGEN we have of course chosen magnetics (actually pretty special ones with 12 transformer cores per port) and PHY that are matched and wired to block port-to-port leakage. [While this is worthwhile it is far from being the key feature of the EtherREGEN's tech; John has found a few $20 switches that when grounded do this.]
b) In order for the port-to-port leakage-shunting to occur the EtherREGEN must be somehow grounded (see next few points).
c) The UpTone-branded 36W SMPS brick that will be included with the EtherREGEN (same model as what everyone receives as the charger for the UltraCap LPS-1.2 simply because I have no desire to stock a separate one) is already an internally "ground-shunted" design--meaning its zero-volt DC output "ground" is connected to AC mains ground.
And since the EtherREGEN's DC input jack -VE "ground" is already common to half the power ground plane of the board, using our SMPS--or any power supply where you can confirm continuity between DC plug barrel and AC ground--you will be properly grounding the EtherREGEN such that its port-to-port leakage blocking is in effect.
And finally (to your question):
a) Our UltraCap power supplies, as well as batteries, our JS-2, and a few other LPS units have "floating" DC output zero-volt "grounds" (you see I always put the word ground in quotes because unless actually earth-grounded, the -VE, zero-volt--wire opposite to the +DC--is NOT ground).
b) If powering the EtherREGEN with such a "floated" output power supply, it will be necessary to separately earth-ground the EtherREGEN in order to obtain port-to-port leakage blocking. The EtherREGEN has a ground terminal (it may be a pin jack or a thumbscrew—we have not finalized it) for just that purpose. Use of the ground terminal is not needed unless the power supply is of the "floating" variety as explained above.
I hope the above is pretty clear. If it is not please let me know because I'm bookmarking what I just wrote for inclusion in the EtherREGEN's User Guide.
Play with dsp
A novel way to massively improve the SQ of computer audio streamingOn 1/26/2019 at 9:15 PM, auricgoldfinger said:
Here are 2 screenshots that will hopefully explain what I am doing. In Device Setup, note the area inside the red box, which shows where I have set DSP volume. The volume limits are immediately below. I accepted the default values, but perhaps they can be changed elsewhere. In my case, the volume limits are the same for both Device and DSP.
I have DSP enabled so that I can equalize a single band using Parametric EQ. This is shown below.
I suspect this is definitely a situation where YMMV. Let me know if you have more questions.
Here is one more screen shot with the volume shown. If you click on DSP, it will take you to all the settings.
Thanks for suggesting, I'm giving it a try for a day or two by setting preamp to 100 on my PS Audio Junior DAC. I always assumed fixed was better. Not a major change - but does sound very nice, and possibly better which I wasn't expecting.
A novel way to massively improve the SQ of computer audio streaming1 hour ago, lmitche said:
For those of you using a USB stick to boot Audiolinux and Roonbridge on your NUC endpoint, version 1.6 of Roon is available today with a new build of Roonbridge. The update will install per normal Roon operations into the ramdisk in the endpoint and play music as normal.
To permanently save this build on your USB stick, boot the NUC leaving the USB stick in place, login to the NUC and run Save System from the Audiolinux menu. Depending on your version of AL, this can be done from a browser, terminal emulator or console terminal via keyboard and monitor.
If you are running an older pre-menu version of Audiolinux, typing the ramsave command from the root prompt will save the changed contents of the ramdisk to the usb stick.
Make sure that the Roonbridge software has updated to version 1.0 build 169 before doing the ramsave operations described above. To check, in Roon go to Settings: About to see the currently running version numbers. Relaunch the Roonbridge if it hasn't been done yet.
Since Roon is writing new files to the installation directory /opt/RoonServer directory (this is not a standard and correct procedure in linux systems with packaged applications...) installation could fail.
To be sure that all is fine, please install manually with
yaourt -Syy roonserver roonbridge --noconfirm --force
Where --force in this case is unfortunately necessary.
If you want, you can edit the file /opt/scripts/alupdate.sh and add --force to the same line.
This will be added in the next menu release, that will have an automatic script for transferring roon database to anther drive and some more option (Turbo=off) for CPU governor
Note: to be sure of version type pacman -Q roonserver
Audiolinux Server configurations, Software, Hardware, and Listening ImpressionsOn 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.
Rajiv NUC start
A novel way to massively improve the SQ of computer audio streaming
My NUC Impressions
Roy graciously lent me his NUC7CJYH encased in the Akasa Newton JC case, and I have been putting it through its paces. I am just amazed at the SQ out of this wee tyke. But let's step back and start at the top to set expectations. My expectations with this NUC were unclear. First of all, while many have found the SQ improvement astounding, they were not starting from the baseline of a Zenith SE, which is no slouch in its own right! On the other hand, Roy had found this NUC coupled with his SR-7 to be so good that he sold his SE? That gave me food for thought.
I've previously reported my findings with just the OS changed. AudioLinux headless in RAM raised the SQ of my SE by a notable amount, both running as a standalone Roon player, as well as a Roon Bridge. Here are my key observations. Unless noted, everything is running AL in RAM.
NUC vs. SE as an endpoint, Dell as server:
- With SE running AL/RAM: the NUC is a small but subtle improvement. This is with the NUC powered by the SR-4. The NUC is more dynamic, and open sounding. What is astounding is this from a < 300 box!!!
- With SE running the original InnuOS, the difference is larger. This is consistent with the fact that running AL/RAM on the SE raised the SQ, closing the gap somewhat.
NUC endpoint+Dell server vs. standalone SE:
- The gap widens. The Dell as a server sounds more dynamic. I still feel this config is somewhat harsher (this purely a comparative statement - both configs sound gorgeous) than the all-in-one SE (not by much), but I think there are many paths now to tune that out, which I can explore.
PSUs for the NUC:
- I ran the following: sPS-500, LPS-1.2, SR-4, and finally SR-7 DRXL.
- The sPS-500 quickly was superseded by the LPS-1.2, which sounds wonderful. On careful listen, the SR-4 is subtly better. This is actually closer than when I ran these PSUs on my tX-U. With the NUC, the SR-4 provides an inky blackness and tames a bit of the harshness I alluded to earlier. The LPS-1.2 is more expansive, but just a smidge more fatiguing. Again - please remember, these are comparative statements only. The LPS-1.2 is by no means fatiguing.
- Then came the SR-7 DRXL. Man - I am astounded every time I hear this PSU! How is it possible to improve on such excellence as the LPS-1.2 and SR-4?! But it is! With the SR-7, I finally understood what Roy has been hearing. There is clear daylight now between the NUC+SR-7 and my SE. The SR-7 adds even more dynamics, but along with it a refinement and ease, that is hard to describe, but easy to hear.
Whither clocks? tX-USBultra - in or out?
- Until now, for the last 18 months, the tX-USBultra, powered by the SR-4 and disciplined by the Ref-10 has been the one component that has been "old reliable, old faithful" in my chain. What about with the NUC as endpoint?
- With the NUC, powered by the LPS-1.2, I compared with and without the tX-U, wow - the tX-USBultra is now a bottleneck! I could not believe this when i heard it, but sure enough Roy and @Johnseye are spot on. The tX-U sapped the dynamics a little, and imparted a thinness to the sound! This is the complete opposite of what it has done in the past. Amazing.
- But wait, there's more! With the NUC powered by the SR-7, AND the tX-USBultra powered by the SR-7 (both rails are DR), the situation reversed again! With SR-7 power, the tX-USBultra again adds SQ to the path! I've discussed this with Roy, and the main difference we have in our setups is that he has only one DR rail, which he applies to the NUC. We (Eric and I) had the luxury of 2 DR rails at our disposal.
- Verdict: at the very least, the effect of the tX-USBultra is much smaller with this NUC than it has been with all my previous endpoints. Depending on power supplies, it could be either a benefit or a hindrance. If you have one already, try it and decide for yourself. If you don't, no FOMO here!
There really is something special about this 7th generation of NUCs. Whether this is a happy accident, or Intel actually focused on audio quality, the end result is something special. However, let's give credit - a lot of credit - to the SQ improvements due to AudioLinux. It's the combination that is truly spectacular. As always, PSU quality remains a critical requirement.
What I've heard has convinced me to try out this solution. I've sold my ZENith SE Mk II Std., and now have a NUC7i7DNBE and Plato X7D winging its way to me. Over time, I will also look at improvements on the server end, and the network.
But let me end on a note of appreciation for the Zenith SE. My decision to sell the SE (btw - demand is through the roof!) was highly personal, and based on my own urge to experiment. Not everybody likes to dabble and tweak. If you own one of these, don't feel you are missing out a lot with all this NUC euphoria. This is a seriously good piece of kit, and Innuos is an innovative company. Trust me, they are watching this space closely, and will very likely offer some of these improvements in their own way. And you can always dip your toes into the pool, like I initially did, by booting up your box with an AL/SE USB stick - the original config is just a reboot away - or by adding a NUC downstream of the SE.
There are many path to nirvana!
- NUC vs. SE as an endpoint, Dell as server:
A novel way to massively improve the SQ of computer audio streaming
Warning - pretty long post.. ?
The Pink Faun 2.16 Streamer - a journey of creation
Over the past year or so, CA and especially this one thread has been educating me about computer hifi specifically the front end of the chain and all the myriad of devices that includes the functional boxes, wires, power supplies, power and power supplies for the power supplies etc. Along the way, like many here, I assembled my version of the Trifecta Stable system that includes the tx-USBultra, sMS-200, isoRegen, Clocks and more. Items that all have a contribution to the ultimate sound.
And then I was ready for the next step - a custom server of my own with the view to keep the glorious sound but simplify the system if possible. After reading about the benefits of power, clocks and simple low-power motherboards with special SSD memory, eMMC drives, RAM etc it didn't seem all that difficult to specify and get built a good streamer at a good price.
Near the end of my efforts and when almost ready to commission a build, I did one last check with other high end servers to see if there was anything I left out in my planned build. And that’s when I came across the rather obscure Pink Faun website in Dutch language. The pictures of the streamer there was exciting. A highly complex box full of equipment and wires. No reviews online for the device as yet.
The Pink Faun streamer is made by the Triple M Audio Shop is a Dutch company based in Rhenen. The streamer is now v2.16 in its current incarnation and has been around for over a year now but it's only recently that I came across it during my research to assemble my own extreme server. Apart from the basic motherboard, most of the streamer is designed in-house and hand made.
With my interest generated, I wrote in to Jord the proprietor of the Triple M Audio Shop company for more information on his State Of The Art streamer than what was already provided in the website.
In a nutshell the Pink Faun 2.16 streamer can have
- Up to 20 liner power supplies
- Up to 4 OCXO clocks internally
- Option wiring with zero inductance
- Star earthing and supply cabling design
- Custom built OS and Bios
That was far more technology than I was planning in my own streamer. And far more costly too. But I figured that if I went with my own streamer design I would also have to consider adding an external bespoke power supplies like a Paul Hynes or Sean Jacobs or an extreme clock like the Mutec Ref10 or Cybershaft OP14, the price would get closer. And to get the clocks working you would need to add a re-clocking card, optimised cables and modifications to utilise the clocks. Not to mention having to choose and setup an optimised OS like Windows Server 2016 with Audiophile Optimizer or Fidelizer Pro or even perhaps Linux installation.
After some consideration about the daunting task of going ahead with my own streamer design or go with a company of which I hadn't heard much off and without any reviews of the 2.16 streamer, it was close but I chickened out of making my own and went with Jord's design.
Pink Faun has a few streamers on offer - a basic box which you can then choose what you want to place inside starting at euro1750, a medium streamer model 3.4 starting at euro3490 and their top of the range 2.16 which starts at euro6990.
Considering what they had already described to me, I decided to go for the 2.16 but also added some optional extras to it making it the 2.16x version. This included:
- 4 OCXO clocks in various locations
- 3 Pink Faun Rhodium 10mm fuses
- Furutech FI-09 Rhodium IEC inlet
- PCX-1 zero inductance cables for the ATX motherboard PSU, the processor PSU, the SPDIF bridge PSU and SATA cable for OS-SSD
As I proceeded with this project of customising the PF2.16 server (and it's a truly custom design actually as all their multitudes of i2S cards, spdif i2S Stereo, I2S Multi-channel, s/pdif coax, AES/EBU, USB, LAN etc are all self designed and hand built along with their clock and power boards) I figured that the project would be a lot more fun if I dug out their thoughts behind their designs as it was not easily found online. So I asked Jord and we discussed the following:
On Power Supply Design - there are 3 transformers in the case.
1) Why do you use three smaller separated and not one larger mains transformer?
There are two reasons for this, first smaller transformers are more stable under high current swings, and have less chance of humming during high current peaks. Secondly and most important, each transformer is used for it dedicated area of operation. One for the processor, one for the motherboard and one for the peripherals. A streamer supply has a highly peaking current load, and all currents add up in the transformer core and interact with each other. By separating the main areas of a streamer in each transformer interaction is less and will improve the final sound quality.
2) Why are chokes use in your power supplies?
Due to its intrinsic properties, a capacitor buffered power supply does not draw a continuous, but a highly peaked current. Each 100Hz capacitors are filled up for the full cycle in only microseconds, depending on the duty cycle of the power supply. The higher the capacitance and the lower the inductance (and Rdc) of the transformer, the lower the duty cycle, and the higher these peaks are. These peaks introduce large Hf noise in power supplies. In Pink Faun power supplies we use high inductance power transformers (low field saturation in the core), and we use pi-filtering to keep the peaks at a minimum and thus Hf noise. The less rubbish in, the less we have to filter later.
3) Why do you use separated power rails and not on single mains supply?
All loads in the end come together in the source of power. In this source they interact, resulting in harmonics and intermodulation noise. The earlier all separated loads are split in the device, the less they interact, resulting in lowest initial noise in power supplies. Also by using a lot of smaller separated and regulated supplies, we can keep current loops very minimal and local, which also will reduce spread of EMC inside the device. This is why Pink Faun streamers use separated rails for dedicated areas and a separated regulator each for each load. Great care is taken in adding these power supplies all together in one star ground, and also to source all ingoing voltage from star outputs in the power supply, resulting in minimal interference and minimal Hf noise and harmonics.
4) What can we do to get lowest noise possible in the streamer power supply?
Even the best regulators have very poor Hf characteristics. Noise of the regulator itself is a factor in the final supply's output noise, but even more important are the noise of the mains power, EMC noise (from outside and the device itself) and noise generated by the rectifying and current peaks of the capacitors. All these noise sources have to be minimized in order to let the regulator get to its optimal performance. This means special low inductance transformers, schottky diodes, low ESR capacitors and a lot of common and differential mode Hf filtering, separated rails, lots of regulators with localized current loops, star sources and ground, shielded power planes on the PCBs, cable setup, etc, etc. In the end the final result is the addition of all efforts taken right from the mains input of the power supply to the connector of the motherboard.
In my particular design, the 3 transformers are providing 4 main power rails from which all separate voltages for each part of the streamer are regulated. Every part of the streamer has its own dedicated regulation from the corresponding power rail. The transformers are housed just behind the front panel in an internally shielded section furthest from the sensitive electronics at the back of the case. The use of Schottky diodes, feed coils on a nano-crystal line core and Nichicon capacitors providing a capacity of 800,000uF is included.
Jord explained that during the development of their single ended, class A 2x40 power amplifier (pic below), they found that if transformers were carefully placed at angles, their natural fields would cancel each other out. In that amp there were 3 power transformers (left/right/peripherals) 2 big chokes and two big output transformers.
- - ATX to motherboard: 5 dedicated regulators
- - SSD OS: 1 dedicated regulator
- - SSD 1T: 1 dedicated regulator
- - OCXO: 4 dedicated regulators
- - LAN card: 1 dedicated regulator
- - USB card: 1dedicated regulator
- - Processor: 1dedicated regulator
Total 14 dedicated regulators on the audio side. In fact I'm told that there are more liner regulators as there are many other parts of the system that are not directly related to audio, like the External Switch ES to power on/off a DAC with the system, this ES has also its own regulation (there is a small transformer in the middle for that) also the standby LED for the power switch etc. all have their own regulation. Apparently this is to prevent distortion on the other power lines.
On the Pink Faun Arch Linux OS
Pink Faun earlier used a version of the Windows for the OS and still offer do if customers require it but when I asked what Jord believe would offer the best sound and he strongly recommended to use the real-time, low-latency kernel Arch Linux which allows one to build exactly the modules required for audio and nothing more.
He said that in concept Windows and Linux are totally different. The benefit of Linux is you start with nothing and only configure what you really need for audio playback. With Windows, the opposite is true, it comes loaded with all kinds of stuff and preprogrammed priories and actions, so you have to peel of the entire OS to your needs.
When ask about the allocation of the processor cores to their duties of running the basic applications like Roon and HQPlayer, and whether it was advantages to have certain cores dedicated to certain applications to avoid cross interactions (ala SGM), Jord offered:
" The 2.16 Linux OS gives realtime priority (in a decreasing way) following the configuration file they made in the Realtime Kernel. In this configuration file HQPlayer is the first and Roon second in order of high priority. There are here 2 possibilities:
- If you are using Roon with HQPlayer. In this case Roon is only giving the file to HQPlayer, but is not processing audio. So HQPlayer gets all the priority, Roon doesn't get any because is only used for library management and not for processing audio.
- If you are using Roon without HQPlayer, since the presence of HQPlayer is ineffective since is not loaded so all the priority is going to Roon because Roon is processing audio.
Linux uses all cores if the applications allows it and HQPlayer needs all possible cores to work at best. I don't see an advantage in giving some cores to Roon and some to HQPlayer, for what I have written in option 1 (Roon is not processing audio). "
In use having spend many working years with Windows, I can say using Linux is very refreshing. No updates or configurations to worry about or virus issues. It simply works and as claimed in a Dutch review by Michael van Meersbergen in January 2018 Recension (http://www.hvt.nl/hvt-xtra-streaming/pink-faun-streamer-2-16/), it is "as stable as a elephant on 16 legs". Living in Thailand, I understand what he is trying to say. ?
Shutdown is 6 seconds and boot-up takes around 30 seconds. Nice
My 2.16x version of the streamer comes with four Connor Winfield OH200 series OCXO clocks, one each for the processor, motherboard, USB card and LAN card. I didn't specify for the i2S card as I don't have a DAC capable of using this connection but I will probably opt for one in the future. Apparently their re-clocked i2S card is something special. My LAN card is still forthcoming as Pink Faun just created a new redesigned card and I wanted the latest version of the card with the latest clock.
As I write this, we are awaiting for their new generation of clocks to come out - one that was custom built for Pink Faun and is a simple swap (not user installable) out from the existing clock boards. The phase noise of this new clock is out and is a very nice -133 dBc/Hz (10Hz) at the use frequency of 20MHz.
Why is this very nice? Because this suggests even lower phase noise levels when compared to external reference clocks at lower use frequencies. Is apparently easier to reach lower phase noise figures at the reference clock frequencies of 10MHz but the problem is that 10MHz is not directly usable in audio. In the Pink Faun streamer, 20MHz (USB bridge) or 24.576 (I2S bridge / SPDIF bridge) and 25MHz for the system and processor clock is required.
For those here that understand the science behind clocks, this is what Pink Faun engineers explained when comparing their clock noise with the Mutec Ref10's phase noise of -142 dBc/Hz at 10Mhz:
" All the specification you referred are at 10 MHz not 25 MHz (or 20MHz).
Due to physics: Frequency multiplication by N increases the phase noise by N2 (i.e., by 20log N, in dB's).
If you move the frequency from 10MHz to 25MHz you will loss theoretical = 8 dB in PN ( 20log 2.5)
In practice you can calculate with 15 dB loss because the best Q value of the crystal is around 800k at 25MHz instead of 1.3M at 10MHz
We are on the physical limits already at 10MHz in the moment with -145dBc/Hz at 10 Hz ( 10 dB better than Vectron and CTS). The best value we could reach is -130 dBc/Hz at 25 MHz
The Vectron 10 MHz OX-204 has 135 dBc/Hz at 10 Hz => best PN would be -120dBc/Hz at 25 MHz
The CTS Model 122 10 MHz has also 135 dBc/Hz at 10 Hz => best PN would be -120dBc/Hz at 25 MHz
At the moment we don't have any crystals with a Q value of 800k available. So at first we need to produce such crystals and check if we could guarantee at 25 MHz the PN better than -120dBc/Hz at 10 Hz at 25 MHz "
This new clock should be quite a bit better than the current clocks which are already pretty decent now being installed on board close to where they are required. On that matter, my 2 processor and board clocks are installed under the motherboard in order to shorten the signal path of the clock to the components. This was optional but necessary in my opinion.
Each OCXO clock has their own printed board with linear power regulation. Jord claims that the phase noise is not only determined by the clock itself, also the used wiring, PSU and way of mounting the clock are a major part of phase noise and so have taken this into consideration during the clock card designs. They must have done a good job as the acclaimed SGM server uses a Pink Faun designed clock board. Pink Faun actually worked on a power supply design for SGM too also but in the end they opted to use another approach.
On why Pink Faun believes they need a separate OCXO clock for the processor:
" The system clock (chipset) is needed to synchronize all components/clocks on the motherboard. This clock also synchronizes the clock for the CPU, but the CPU clock is only used on the chip itself. Because the CPU needs to perform more operations per time than the motherboard the clock frequency will be multiplied in the CPU. Our clock runs on 25Mhz and is multiplied 136 times. The System runs at a fixed frequency of 3,4 GHz "
On the Motherboard
As time went on, I started to get a feel about Pink Faun and their unconventional approach to audio. A quirky, extreme approach backed by logic and ability to execute. And this extends to their choice of motherboard to use. Whilst the current approach by all is to use low power, lowest power consumption CPUs required for their function boards, Pink Faun opted to use an extreme gaming motherboard the ASRock Fatal1ty X370 Professional Gaming that uses a Rizen 8-core processor https://www.newegg.com/Product/Product.aspx?Item=N82E16813157756. This board is full of technology designed to push output to extreme levels necessary for gaming. Why would it then be suitable for the quiet noise free environment required for audio use?
In order for the board to operate at extreme gaming levels, many of the supporting functions must have been enhanced and optimised to perform at all costs. Like the enhanced power delivery to the CPU, the chokes that allow higher saturation currents to the board and the RAM heatsinks to cool memory. And when run at the lower demand audio levels, these peripheral supporting hardware still operate well below capacity, fully allowing effortless and low noise functioning.
Jord emphasised that this board and his power, clock and Bios adjustments on it provided for Low Latency operations. The time it takes to issue an instruction to the 8-core processor and the time it takes to execute it has been reduced to the very minimum. The core is working at full speed all the time and so there isn't any issues of cores running at different frequencies with power saving modes kicking in which also complicates the OS and produces further latency. The downside of this Class A approach to CPU output is that it will run hot and so the 2.16 has a passive cooling system of pipes attached to large heat sinks at both sides of the streamer. I can confirm it runs hot and when I am upsampling with HQPlayer to DSD512/48 the case is almost too hot to keep my hand on the case but the streamer seems to remains stable. Over the course of a few months of use not once has the Pink Faun crashed or hung.
There are so many details to the design that I found it difficult to ask the right questions. When I made the order, I had not know all of the above yet and only discovered it as the project developed. My decision was based on my soft spot for quirky, artistic designers that have a passion for their work. The product usually is more true to their goals and contains a bit of genius that make for that little extra - something necessary in my mind for SOTA designs. And of course the fact that their technology got-to-have check-list was already longer than my own planned SOTA streamer list.
As a testiment to their focus on designing and making products and not with marketing, much later in the process it occured to me that I needed to use HQPlayer along with Roon and asked about it. It was then casually mentioned that the 2.16 came with HQPlayer Embedded, one of the very first streamers to do so. Oh my, how nice!
I then asked about how to place the unit as it was a hefty 20+kg and if I could use my special footers under them. That was when off handedly Jord mentioned that the streamer includes their own special isolation footers which had steel ball bearings in between 2 aluminium parts designed to absorb energy that in their experience sounded very nice. Wow, another pleasant surprise!
It is obvious that Jord, Mattijs and the Pink Faun team has put a tremendous effort in the design of this 2.16x streamer and it's a shame its not recognised more due to their quiet approach to the market. I'm glad I decided to choose their streamer and so confident they are with their product, they offered me a full money back guarantee of satisfaction with it. A guarantee that I will not use as I am totally happy with their product! Hopefully this quick description of my decision to go with the Pink Faun 2.16x streamer will place more information about their product and approach to audio into the internet for all to consider.
Hope it was enjoyable reading,
Regards, Kin ??
The listening tests of the 2.16x streamer in different configurations:
- 2.16 - DAC
- 2.16 - tx-USBultra (clocked) - DAC
- 2.16 - sMS-200 - tx-USBultra (both clocked) - DAC
- SonicTransporter i5 - 2.16 - tx-USBultra (clocked) - DAC
- SonicTransporter - switch (clocked) - 2.16 - tx-USBultra (clocked) - DAC (ala Roy's findings)
- Antipodes Cx and Ex set comparisons, if I can get @Kritpoon to lend me his set. In various combinations to be determined.
* Spoiler alert! One of the combinations above is truly magical ?
- usual disclaimers: Not in the business, no affiliation to Pink Faun or Triple M Audio Shop. Purchased at retail price. etc.
Roy intro to NUC
A novel way to massively improve the SQ of computer audio streaming
It's been awhile but I made a promise to someone that I would submit this post and so here goes. I have not kept up faithfully with this thread or any other thread but friends have periodically brought certain important findings to my attention and so I am aware of how splendidly so many of you have continued to push the envelope with regards to digital. It's nice to see that the spirit that this thread was founded on remains vibrant and strong. Thanks especially to Rajiv for continuing to moderate this thread so ably.
Much has changed with my own system since I last posted. While I have largely retired from posting due to other time commitments, my curiosity for the unknown aspects of digital continues to burn strong. I have no scientific explanation for so many differences that I hear but as best as I have been able to figure out, good digital amounts to 3 things: (1) low noise, (2) low impedance, and (3) low latency. Maybe there are other characteristics I have left out but as I have attempted to improve my own digital setup, I have sought to address primarily these 3 things.
As those who have followed this thread from the beginning are aware, I put together my own single chassis server some time ago and it was the very best I knew how to do. Foundational to this server were a modified DFI motherboard, 7 SR7 rails, 9 clock replacements (from the router all the way to my final endpoint just before my DAC), and a REF10 that tied all these clocks together. My OS of choice was Windows Server 2016 running off an Intel X25-E SLC SSD which was further refined with AO/Process Lasso/Fidelizer Pro. Roon was my player of choice. What I got was smooth, harsh-free digital playback with robust dynamics. Sitting atop a Synergistic Research Tranquility Base, I was pretty happy with this setup...for about 3 months.
Then came along the Innuos Zenith SE and it highlighted some important deficiencies in my system. While my server brought about a greater sense of resolution and less harshness thanks in large part to all my clock replacements and the REF10, the SE displayed superior dynamics, even with my SR7 powering my server. Having taken apart my SE and carefully examined what went into this build and having spoken with Nuno of Innuos and Sean Jacobs, the SE's PSU designer, it became clear to me there were several reasons for what I was hearing but a big reason was the SuperMicro board they chose was superior to the DFI motherboard I used with my build. With the SE followed by my tX-USBultra powered by a DR rail from my SR7, this was now my very best setup and so I purchased an Innuos Zenith SE. I was pretty happy with this setup...for about 6 months.
There remained a subtle harshness with my digital setup that was tolerable in my large listening room where I had my large Martin Logan Renaissance electrostats but less tolerable in my nearfield Voxativ setup. Voxativs have a tendency to run bright and so any HF harshness tends to get magnified with these speakers resulting in fatigue. When I swapped out the SE for my old modified Mac Mini that ran MacOS off an SD card, this harshness went away but it was at the expense of vibrancy and immediacy. There was a definite tradeoff. I swapped in my other modified Mac Mini that ran Windows Server 2016/AO off an integrated PCIe NVMe SSD and the vibrancy and immediacy came back but the harshness was even worse than the harshness I heard with the SE. Just like in the past, after 5-6 hours of listening, there was fatigue. In my view, it had to be the SSD that was the culprit. According to Ed Hsu of Sound Galleries, SSDs emit a noise in the 6GHz range that is very difficult to filter and the faster the SSD, generally the noisier it is. Based on what I was hearing, I had no reason to doubt what he was saying.
Late last year, I was introduced to Adrian Wun, owner of The Linear Solution (TLS) by a fellow CA member. Adrian was designing his own server that incorporated the same SuperMicro motherboard used in the Zenith SE although he modified this board with multiple OCXO replacements and powered it with his own custom designed multi-rail ATX PSU. What really intrigued me was his custom OS, basically a modified and purposefully-tuned Linux OS that he compacted down to a size below 6GB and so he was able to completely run this OS from memory. With this OS completely running from 8GB of RAM vs a PCIe NVMe SSD, he said latency improved by a factor of 10-150x depending on what processes were running. I filed this little tidbit into my own memory because I knew I would want to eventually explore this.
A New Motherboard Discovery
My Innous Zenith SE experience taught me what many others on CA had known for some time, that performance is likely to improve if the CPU and the rest of the motherboard are powered independently. This means that my DFI motherboard was being crippled by the single 12V DC feed that was powering the entire board. In my mind, if I was to one day build something even better than the SE, I would need to target a motherboard that provided independent power to the CPU which meant I would be forced to using an ATX PSU (or at the very least, a DC-ATX converter). Paul Hynes told me he would one day get around to designing one but he had too much on his plate to know when this would happen. Sean Jacobs told me he could build one for me immediately. As the Zenith SE I owned already incorporated one of Sean's wonderful designs, I figured my best bet was to stay put, however, I continued to be on the lookout for better motherboards that would allow me to completely do away with an SSD.
Earlier this year, I came across a particular Intel NUC motherboard that incorporated a certain feature that has intrigued me for some time. This motherboard is the Intel NUC6CAYB and here is that motherboard:
What intrigued me about this board is its use of an eMMC device for OS storage. This is 32GB of solid state storage that is "embedded" onto the board that is as electrically quiet as an SD card but has "near" the speed of a typical SATA III SSD. Other features include an embedded low power Celeron CPU with an SoC architecture and up to 8GB of RAM capacity. Unfortunately, there was no way to power the CPU independently as this board takes a single 12-19V DC feed, however, given the very small 4" x 4" size of this UCFF (Ultra Compact Form Factor) board, I figured it should have even lower impedance than a larger mini-ITX board and was worth $100 to test it.
I was able to convince Adrian to "loan" me his customized OS for this build and so while his OS is permanently stored on the eMMC drive, upon boot up, this OS transfers completely into 8GB of RAM and so the eMMC drive serves only as a place to store the OS when the server is shut down. While you could argue that I could have used an SSD drive in this situation and that the SSD would sit idle since the OS would be running completely from memory, my contention is that even a dormant SSD still generates noise. In the end, the proof is in the listening.
With Adrian's Dream OS loaded onto this board and running completely from RAM, with Roon Server running as the sole app, and with this inexpensive server powered by a DR rail from my SR7, I was hoping it would come close to my Zenith SE with respect to dynamics but improve upon the SE with respect to less HF harshness. I was not prepared to discover that this setup quite soundly bettered my $7k SE in every way. Unlike my DFI board, it was as if this board was allowing my DR SR7 to really show what it could do. Dynamics were superior to the SE. Transients were cleaner. Immediacy and tonal vibrancy were better and with none of the harshness! I compared this NUC board against both my modified Mac Minis and against my custom server and this new build easily bested both Mac Minis. Against my previous custom server, the perceived detail resolution was still superior with my custom server due to all the clock replacements but dynamics were easily superior on the NUC. If I followed the NUC with my tX-USBultra/REF10, this was now my very best setup. So good that I have sold my SE.
But Wait, There's More...
I tend to follow the product offerings of many music server companies to see what new innovations they have come up with and I noticed that earlier this year, Antipodes announced their new flagship was now a dual PC setup called the CX + EX, basically a server + renderer combo instead of the single box DX Gen 3. I found 2 things to be interesting:
(1) Mark Jenkins felt that splitting up server and renderer duties between 2 machines resulted in superior SQ compared to a single PC functioning as both server and renderer. This is not an entirely original concept as JPLAY has been championing a dual PC setup for years based on this premise. Moreover, devices like the original microRendu have popularized the concept of a separate server and a low power NAA or Roon endpoint for some time.
(2) Mark decided to employ the "direct Ethernet connection" via bridged LAN ports between the CX and EX that many of us who have been following this thread since its inception began employing some time ago. In his words, this direct Ethernet connection "provides a dramatic improvement over connecting your server and renderer through a noisy switch or over a long length of network." Good for Antipodes.
While neither of the 2 concepts above are original, Antipodes is the first server commercial manufacturer that I'm aware of that is not only advocating both concepts simultaneously but is also selling a turnkey setup that incorporates both setups and unlike an ultraRendu or sMS-200ultra that are incapable of running standalone, both the CX and EX are standalone PCs meaning if the owner chooses, they can run either one without the other.
This really got me thinking. While I left my SOtM trifecta some time ago because I preferred a more elegant single box solution, I decided to run my NUC as a Roon renderer only (Roon Bridge) and my Zenith SE as a Roon Server. With both connected to my network via the standard "indirect" method, there was certainly an improvement in terms of "less edginess" but the improvement was subtle. With the two connected directly via bridged LAN, the improvement in SQ as far a "less stressed" sound but also better transparency was more pronounced. Of course, to relegate the $7k Zenith SE for server only duty didn't sit that well with me and so I decided to swap out the Zenith SE for my unmodified Mac Pro with 12-core Xeon, 64GB of RAM and 1TB of PCIe NVMe SSD to see how much degradation in SQ I would get and the degradation was indeed significant with respect to harshness. This was the exact same observation I reported early on in this thread, that the direct Ethernet connection is not only more transparent to the qualities of the upstream server but also more transparent to any inadequacies that upstream server may possess.
At some point during my testing with SE as server and NUC as renderer, I decided to move my SE into my home office where my near field Voxativs were kept while keeping my NUC in my larger listening room with my Martin Logans. To directly connect these 2 devices, I had to run 53 feet of Blue Jeans Cables CAT6A Ethernet cable in my crawl space and that is exactly what I did. While the improvement was still quite desirable, it was not as pronounced as what I had experienced with my SOtM trifecta which consisted of an sMS-200ultra, a cheap SOtM-modified switch, and a tX-USBultra. As I first described my experience with installing a reclocked switch into this "direct" pathway early on in this thread, I found the impact of this switch to be dramatic and nearly on par with the tX-USBultra and so I knew that I needed to throw in the switch.
The Importance of the Network Switch
There was no doubt in my mind that introducing a reclocked switch into this direct pathway between the SE and the NUC would result in further improvement but I was curious to know if the impact would be greater with the switch connected closer to the SE vs connected closer to the NUC. Keep in mind that these 2 devices are separated by 53 feet of BJC CAT6A cabling and I never had to contend with this length of cabling with my SOtM trifecta. Most would probably guess that the switch would have a greater impact if I connected it closer to the NUC and indeed, that is what I found. With the switch separated from the NUC by only 0.5 meter of Ethernet cabling, the improvement was quite dramatic. It was like adding a buffered gain stage (ie an active preamp) to an amplifier. Noise floor drops, dynamics improve, sound stage improves and detail clarity improves. The switch before either the SE or the NUC when connected to the network in a standard configuration makes a difference but when the switch is placed in this "direct" pathway, the difference is definitely more stark.
To be honest, the above findings were expected rather than revelations. What was a revelation was how well this switch now isolates the renderer from the server. When I first described the impact of introducing a reclocked switch into the "direct" pathway, I was using only low-noise, high quality servers exclusively. By this time, I had already established that the quality of the server matters and so I never bothered to go back to my noisy Mac Pro with 12-core Xeon. In this instance, with the reclocked switch in the "direct" pathway, I decided to swap out my SE once again and replaced it with my noisy Mac Pro and what I found was truly revelatory. This switch very effectively isolated the noise coming from the Mac Pro. As I A/B'd between SE and Mac Pro, the difference between the 2 was now subtle at best. In blind testing, I was unable to tell that there was a meaningful difference at all.
The significance of this is potentially huge, especially for those interested in DSP or upsampling. Now, with my untreated noisy but powerful Mac Pro, I am able to run RoonServer effortlessly. Even with tens of thousands of tracks in my library, I can search and skim through my library with ease resulting in a much more pleasant and lag-free browsing experience. I can run DSP and probably even upsample to DSD512 if I chose with this beast and with this switch in place, there would be no detriment to SQ! While I haven't tried upsampling to DSD512, I have implemented my version of a "loudness" feature where I have boosted my signal at 100Hz and 10kHz by 7dB so that I can maintain dynamics at low listening levels. While this breaks the "bit-perfect" nature of the stream, I have found this to be a wonderful "can't do without" feature with low volume listening. While this is not CPU intensive, to enable this feature within the NUC results in smooth playback but there is a definite SQ hit in terms of an edginess. With this feature enabled on my Mac Pro and with my NUC freed from any unnecessary side processes, I feel for the very first time that I have a true "no compromise" setup.
Which Switch Is Best?
Despite Adrian's talk about his "super server," he was still months away from having a unit available for me to listen to although earlier this year, he asked if he could ship me one of his OCXO network switches to evaluate. I was already quite happy with the switch that SOtM modified for me that was being clocked by my REF10 and was being powered by my SR7 but I eventually agreed to have him send me one. I know there has been some snickering about the "lowly" specs of the OCXO that Adrian chose for this switch. According to Adrian, it was important for him to find an OCXO that fit inside the chassis of their switch and so he realized that performance specs had to be compromised for the sake of small size although it was his contention that placing an OCXO directly onto the board would have its own advantages and as far as he is aware, his switch is the only switch currently in production that incorporates an OCXO within the switch chassis. While he also tested lesser expensive clocks from Crystek, he preferred the sound he got from this mil-spec clock produced here in the U.S. by Conner-Winfield. Like the switch modified for me by SOtM, the TLS switch also incorporates improved regulators and capacitors. For his introductory price of $650, his switch also includes a custom 5V/2A linear PSU that was designed specifically for this switch.
Once again, say what you will about the pedestrian specs of the clock used in this switch and I realize there are the "engineer types" on CA who believe they already know how something is going to sound even "before the needle hits the groove" based purely on specs but this switch soundly outperforms my SOtM-modified switch even when clocked by my REF10. Obviously, there's more to a component than just the clock and Adrian has voiced this switch beautifully with all that he has done to it. If this switch has one downside compared against my SOtM-modified switch, there is a touch of brightness/harshness with the TLS switch that is not present with the SOtM-modified switch, especially when combined with the REF10. If there is one thing the REF10 does so well, it is the removal of harshness, however, with the TLS switch powered by my SR7, soundstage is bigger, dynamic contrasts are more robust, and detail clarity is improved. When combined with TLS's heavily shielded CAT7 cable (<$200 for 1.5m length), much of this brightness is nicely ameliorated although as good as his CAT7 cable is, I find SOtM's more robustly shielded and filtered dCBL-CAT7 cable to still be better. No matter how good the switch, the quality of the Ethernet cable still seems to matter.
A few weeks ago, May asked me if I wanted to try SOtM's soon-to-be-released sNH-10G network switch. Of course, I said "yes" and here is what their switch looks like:
Their switch (on the bottom) is quite monstrous in size compared to the other switches I have on hand. The switch directly on top of the SOtM switch is the TLS switch. On top of that is my "John Swenson" suggested switch with ground tweak and directly on top of that is the SOtM-modified switch that has been my reference for the past year. At the very top of the heap is my ZyXel Paul Pang TCXO switch that started it all. I would say that the Paul Pang switch and the John Swenson recommended switch with ground tweak work well but result in the smallest benefits. On a scale of 1-10 (where 1 is the smallest improvement and 10 is best), I would assign both of these units a score of 1. My original SOtM-modified switch when connected to the REF10 scores a 5. The TLS switch scores a 7. That means the new SOtM switch scores a 10.
This switch is completely of Lee's design and incorporates an sCLK-EX board. The isolation used is based on Lee's iSO-LAN6 technology. The unit I have is a prototype and so not all of the ports are functional but when connected to the REF10, I would call this switch Lee's best work yet and it is a masterpiece product. It performs roughly on par with the tX-USBultra but considering this switch is placed before my NUC while the tX-USBultra is directly connected to my DAC, this level of impact is remarkable. The fact that this switch allows me to connect my NUC to a noisy Mac Pro and result in the best SQ I have heard in my system makes it a game changer and a more valuable piece than my tX-USBultra. Are these switches sensitive to the PSU that feeds it? Despite all the regulation built into this switch and the TLS switch, the answer is absolutely and emphatically yes. As rare and valuable as my SR7 rails are, I tend to reserve them only for the products that truly benefit and these switches are as deserving of an SR7 rail as any component that I have.
I am aware of the AQVOX SE switch which is no doubt a contender although I have not yet had the opportunity to compare that switch. Of course, we're all waiting for Uptone's new switch. As network switches are right in John's wheelhouse, no one will be surprised if this switch rises to the top, especially if value is taken into consideration, however, for now, SOtM's new sNH-10G when combined with the REF10 has set the bar for the very best switch I have experienced in my system with the TLS switch setting the bar for best value.
General AL setup
AudioLinux and NUC Troubleshooting and Tuning11 hours ago, BigAlMc said:
Awesome work guys and great discovery.
At the very real risk of pushing my luck it would be great if we could have a simple 'how to' guide for the technically incompetent (like me) showing how to set buffer size for:
Roon bridge endpoint
And ideally in both the 4gb and 8gb flavours that are likely most prevalent.
The obvious question is whether the 4gb flavour has sufficient ram spare to make a difference in SQ via this buffer setting or whether 8gb is worth the investment?
Either way this is terrific stuff and an excellent area of exploration. Even if I need to read it twice in order to understand half of it! ?
Alan, I have 8GB, so I've not tried to cram things into 4GB. With the SQ improvement we've heard with crazy large buffer sizes (still unclear why 2GB buffer is better than 20MB buffer for small audio files), I suspect you'll want to consider 8GB
Couple hygiene items above the usual AudioLinux install stuff (make sure to do this will ramboot off so you have all the changes on your USB stick) I'm learning that one can't edit posts here, so if there are typos or incorrect information, my apologies in advance that I'm unable to correct.
* Set IRQ priority for the DAC USB to the highest: https://www.audio-linux.com/html/realtime.html
This will show you the real time priorities for various applications and IRQs (HW interfaces)
This will show you your audio cards. In my case, my DAC is card0, and sits on USB1 IRQ=123 IR-PCI-MSI 344064-edge xhci_hcd
RTIRQ_NAME_LIST="usb" <--- All the USBs have high priority
RTIRQ_NAME_LIST="xhci_hcd" <---- Only the DAC interface has high priority
If you like, you can also make your ethernet a high priority by having it be:
This may be helpful if you run Roon Bridge (which streams data continuously). I am using SqueezeLite (more on that later), which buffers the data up front, so I do not have ethernet as a priority (I don't want random ethernet stuff impacting the system during playback)
* Set app priority for squeezelite and RoonBridge to be second highest
I have squeezelite as the highest priority application. The order in the list reflects priority order if you have multiple apps running. In practice, you'll only have one running, so not something I worried about. I set the max priority for applications to be a hair less than the max priority for the IRQ to the DAC.
APPLICATIONS="squeezelite RoonBridge jackd mpd hqplayer hqplayerd RoonAppliance mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity"
At this point, if you're running Roon Bridge, you should be able to reboot and confirm that everything is still working fine.
Now to the buffer stuff.
Alas, Roon seems to be a black box when it comes to buffers. Per Rajiv's findings, it streams data from core to the end point continuously, and I'm not aware of a way to impact that. Given how Roon works (multi-zone, responsive UI, etc.) that is unlikely to change. All that behavior is made better (from a user experience stand point) by having minimal buffers.
If you want to play with buffers and try to isolate ethernet activity from streaming to the DAC, squeezelite is the end point of choice right now. Alas, that comes with some "endearing quirks" (skipping, issues when seeking within a track, latency, etc), Whether the delta between convenience and SQ is something you can try and see if it is worthwhile for you. For me, I'm leaving the system on Roon Bridge (for civilian use), except when I'm playing with maximizing SQ. Squeezelite is a bit too quirky right now to impose on people that don't care about SQ.
First step is to install squeezelite (if you have AL headless...it is already installed on the full version). From the AL site: https://www.audio-linux.com/html/user_guide1.html (copy/pasted here)Quote
Software Install – Squeezelite-R2;
The install process asks you some questions:
It will ask you if you wish to edit some files = n, on all occassions.
When asked whether to continue building = y
If asked for a password = audiolinux or audiolinux0
Proceed with installation = y
When completed successfully it will report: No database errors have been found!
> Type: yaourt -Sy
This will update the system
> Type: yaourt -S squeezelite-r2-git
This will load the squeezelite software
> Type: su
Enter the root password
> Type: squeezelite -l
Identify the USB output you are going to use
> Type: vi /etc/conf.d/squeezelite
Update squeezelite to use that output
> Type: systemctl daemon-reload
> Type: systemctl start [email protected]
> Type: systemctl status [email protected]
Should be shown as running
> Type: systemctl enable [email protected]
It will now start automatically at boot.
If you're tweaking squeezelite parameters to experiment in your system, I found it is easier to do it from the command line. You start squeezelite, test it, hit control c to kill it, modify the parameters, start it again, rinse and repeat.
To do this, go to alconf and select "Stop and disable all running audio services"
From the command line, after some more experimentation, here is my current squeezelite config of choice in my system:
/usr/bin/squeezelite -o front:CARD=Blu2,DEV=0 -b 4097152:97152 -d all=info -a 1000000:4 -c pcm -x -p 93
For you, you may need to change some of the parameters.
The -o parameter is the output device. You get this info for your DAC by running: squeezelite -l
the -b parameter is the buffer memory that squeezelite preallocates for input from the network (first number) and output to the day (second number). The unexplained finding is that bigger buffers are better. I have it set so that the bulk of the buffer is allocated to the ethernet side. The thinking here is that since we're hearing bigger buffers are better, and having an asymmetric buffer allows us to allocate more buffer space to the ethernet side. Why 4GB vs 2GB matters for 20MB music files is a crazy making question, but I'm blaming Roon Core because they're not here to defend themselves
The -d parameter just sets the debug output level so you can see what squeezelite is doing as you experiment.
The -a parameter manages the buffer between squeezelite and the OS (and eventually to the DAC). This is still a mystery to me, but above are my current settings of choice (1MB allocated to the buffer, with a periodicity of 4). I'm still working on my Italian to suss out what all these mean, and there is more learning/experimentation to do here.
-c says squeezelite only accepts PCM, and -x says no downsampling. Shouldn't effect SQ, I just have them for hygiene.
-p sets the real time priority for the squeezelite output thread. Since I set this 93, and I have the IRQ real time priority set to 95. From rtstatus, everything else is 50 or below.
Once you have a config that you're happy with, you need to edit and add it to the following file: /etc/conf.d/squeezelite
parameters="-o front:CARD=Blu2,DEV=0 -b 4097152:97152 -a 1000000:4 -c pcm -x -p 93"
If you go to alconf and select "START and enable Squeezelite" next time you reboot, squeezelite will be started with these parameters
Aside from the tactics, here is my high level strategy/thinking for the recipe (all hypothesis driven, we haven't figured this stuff out yet). I would love to hear criticism/correction/redirection on this from others.
Get an end point as focused as possible on moving data from ethernet to a USB DAC, with as little variability and as much predictability as possible (aka, as close to precision real time data streaming to DAC as possible)
- Maximize processing/memory allocated to bridging bits from server to end point, to preload data as quickly as possible
- Have an end point doing as little as possible when streaming data to DAC (everything turned off, front load network access, etc)
- Highest priority given to end point talking to DAC (DAC USB IRQ, squeezelite thread, etc)
- Use a stripped down semi-real time OS (AudioLinux) doing as little as possible
- Minimize power use (RF, etc.) by shutting everything unneeded off, running in memory, etc.
- Use the highest power silicon on a chip system with reasonable power use you can find, and manage the trade off between lower latency (good) and higher power (bad)
(as an aside, I'm OK with absolute latency, I just don't want the latency to vary...my working theory is that low latency systems are a proxy for having less variability, because they have faster CPUs, more cache, better components, etc, and less contention and more headroom at any given time)
* NUC with high quality DC inputs, so you have all the goodies combined into single Silicon on a Chip implementation (assertion:
there is less variability with SoC)
* AudioLinux running headless, tuned for real time, OS running in RAM (max speed, lowest latency)
* End point software that allows tuning and optimization and buffering (squeezelite)
* Maximum buffers between server and end point (-b parameter), to preload data to memory over the network as quickly as possible
- Isolate data streaming to DAC streaming from rest of chain as much possible, for as much of the music playing time as possible
* Maximum buffers and priority between end point and DAC (-a parameter)
- Feed DAC the steadiest/most stable/least variable data stream as possible during music playback
* Have as little as possible other things happening during music playback
- minimal network access, no storage access, unused features disabled, lower priority for all other things running in OS, etc
All the above is hypothesis, but a snap shot of my current thinking. Many here have been working and experimenting and thinking about this stuff much longer than I have, so I would give their experiences and gut intuition much more credence (I'm still working my way up the learning curve with this kit).
A novel way to massively improve the SQ of computer audio streaming
Science Experiment: Audiolinux Extreme on Zenith SE
Some of our favorite detractors of this thread like to dismiss the things we try here as science experiments. Well, here’s a report on something that could indeed be called that. Of course, other detractors quibble that what we do isn’t science, nor can it be called an experiment, nor can it even be called empirical, and indeed even our so-called findings are not really that, but rather a mass delusion wrought upon us by our expectation and confirmation biases. Well, those detractors should stop reading now.
To the subject at hand!
While I await a NUC of my own to try, it occurred to me that it should at least be possible to boot up my Zenith SE with a USB stick to run AudioLinux Headless (AL) with Roon in RAM. If so, that would allow me to compare the benefit of AL in ramroot mode vs. InnuOS.
Once I started down this path, consulting Larry and with the nice write ups posted here, it was all pretty straightforward. But I should warn that I am a computer professional, and I do have a Unix background. For me the only challenge was finding the (different) Linux commands to the AIX ones I remembered. This isn’t something I recommend people to try if they don’t know what each step in the flow is for. You can get yourself in a world of hurt if you do something wrong, especially as root. Obviously Innuos does not support this use case. I will say that they have not locked the machine in any way (other than access to the full SSD within InnuOS, now that I think of it), so it is trivial to attach a VGA monitor and keyboard, boot into the BIOS and change the boot order to boot from a UEFI USB stick.
I first started with the easy path - bringing up the SE as Audiolinux/RoonBridge in ramroot. But after some listening, I really wanted to see what the SE running AL/RoonServer would sound like. That was a bit more involved, but I'm glad I did!
I did not make any hardware mods to the SE. For example, I didn’t disconnect the SSD drive, so it was active even in the Roon Bridge case, where it was not used. In the Roon Core config, after I restored my Roon database from backup, fixed up my storage links, and ensured my full library was operational, I did some additional steps to move the Roon DB off the root partition so that:
- It wouldn’t bloat the / partition by the 1.5GB my database occupied, and
- I could make the database live on a persistent store (the SSD), so that changes would be persistent, even in the transient ramroot mode
I did the same thing with Roon executables, so that a Roon update would persist, even in ramroot mode, without relying on ramsave.
Since I compared so many configurations, here's a handy table to keep track:
Config # Nickname Music Server Player/Renderer HW OS SW Music location HW OS SW 1 SE native Zenith SE InnuOS LMS SSD Zenith SE InnuOS squeezelite 2 SE RoonServer Local Zenith SE InnuOS RoonServer SSD Zenith SE InnuOS RoonServer 3 SE RoonServer Remote Core Dell XPS 8700 Audiolinux RAM RoonServer NAS Zenith SE InnuOS RoonServer 4 SE RoonBridge Remote Core Dell XPS 8700 Audiolinux RAM RoonServer NAS Zenith SE InnuOS RoonBridge 5 AL-SE RoonBridge Remote Core Dell XPS 8700 Audiolinux RAM RoonServer NAS Zenith SE Audiolinux RAM RoonBridge 6 AL-SE RoonServer Remote Core Dell XPS 8700 Audiolinux RAM RoonServer NAS Zenith SE Audiolinux RAM RoonServer 7 AL-SE RoonServer Local Zenith SE Audiolinux RAM RoonServer SSD Zenith SE Audiolinux RAM RoonServer
The table shows the Roon service that is running - i.e. either roonserver or roonbridge. As per the Roon nomenclature - see https://roonlabs.com/howroonworks.html and https://roonlabs.com/downloads.html - the actual Roon components that run in each case are:
- roonserver: Core and Output
- roonbridge: Output
- Configs 3 and 6 were of academic interest only, and confirms the idea that it is better to run just RoonBridge on the renderer, rather than the full RoonServer. Since the active Core is on a remote machine, the Core running on the renderer is just wasting resources.
In an earlier post, I've reported on 1 through 4 before:
- 1 sounds better than 2, but 1 is not Roon, and that’s important to me!
- When I installed AL on my Dell server, the SQ improved where 3 and 4 were better than 2, while still not quite as good as 1. The SQ order was 1 > 4 > 3 > 2.
- however, 2 was tonally calmer (less harsh) than 3 or 4.
With these new experiments, I started with 5. This was a substantial improvement over 4. I would say this was the most dynamic and spacious of all the configs. But, there was a slight harshness and edge to the sound.
So then I began to wonder - in my experience so far, there is really something special about the SE's local playback, that occurs when I avoid the network path. So how would 7 sound - i.e. SE as standalone Roon player, except running AL Extreme in ramroot mode?
Well, 7 has stolen the show for me! While 5 is just a bit more dynamic and open, 7 is so much cleaner, less fatiguing, and calm, while preserving 95% of the spaciousness and dynamics of 5. 7 also exceeds the SQ of 1. One of the things I've always noticed about 1 is that while it sounds wonderful, there is a slight hollow phasiness to the sound - as if it's slightly out of focus. In contrast, 7 is razor sharp, big, and dynamic. Wonderful!
I suspect that with a better server, with the SOtM switch, and with the SR-7 powering things, it may be possible for 5 to comprehensively exceed the SQ of 7. We shall see. Once I get Roy's loaner NUC, I'll borrow Eric's SR-7 and use it to power the NUC. I'm not sure how to improve on my server without an expensive machine outlay.
Finally, I have to say there is something really seductive and simple about config 7, which I attribute to the care in noise elimination that Nuno et al. took in the SE's HW design.
For now, I'll be running 7 for a while to see how it holds up.
In terms of SQ, my rankings in reference to the numbered configs in the table would be:
- 7 > 5 > 1 > 4 > 2
I’ve shared these results with Nuno, and he is certainly very interested in our findings. They are already going down the path of “testing a real-time kernel with a lot of optimizations but not ram-loading at the moment…” They’re aware of the AL experiments of course, and with these findings, they plan to add AL to their research. The encouraging news - at least for me, as a customer - is that he is very interested to offer some kind of “extreme” solution for us bleeding edge types. Perhaps even a USB stick. Obviously, their core customer is quite the opposite, i.e. those that are not computer literate, who want something simple that just works.
As you’ll note, in this case, Roy and I seem to have preferred different configurations. Roy is clearly finding the distributed configuration of “powerful Roon Core+simple NUC endpoint” to sound the best, whereas I am - at least currently - still finding the local all-in-one Roon Server to sound best. Of course, there is pending work to be done. It may turn out that there is really something special about these latest Intel NUCs, which may reverse the finding for me. Or it may just be that my ears, with my system as a whole, are finding they prefer something different.
Isn’t it ironic that about a year ago, Roy was the one who was championing his custom server and the SE as his preferred configuration, while I was still in the camp of distributed chains a la the SOtM trifecta? We’ve now reversed our preferences! And so it goes...
ram boot setup
A novel way to massively improve the SQ of computer audio streaming
AudioLinux Guide 4
Environment: AudioLinux already launched in GUI mode
1. Open the Start here folder
2. Open the Expert folder
3. Open the Ramroot folder
4. Run the Ramroot enable
5. Warning may come out. Don't worry.
6. Click the power at the bottom bar.
7. Click Reboot
8. In the UEFI menu, choose the USB disk
9. Answer yes
10. Wait for quite some time.
Done. RAMboot complete.
SOTM Switch Intro over
A novel way to massively improve the SQ of computer audio streaming23 hours ago, Soma said:
Thanks to this forum, I am now interested in getting network switch, seems like important component in audio chain.
Another update and perhaps my final post for awhile. Just too much on my plate.
My SOtM sNH-10G network switch arrived late last week. I was gone through the weekend and so this switch has been burning in and has about 100 hours on it now. Initially, when it arrived, it was sounding a touch harsh but this harshness has mostly disappeared and should continue to disappear. My unit has the EVOX caps, OCC silver DC wire, and the EMI paper upgrade. I figured, why not? It also has a 75-ohm master clock input. With all the bells and whistles, the price of this switch is quite high (close to $2k) but based on my favorable experience with the prototype, I knew I wanted one. I look forward to Uptone's upcoming switch. TLS supposedly has an improved switch in the works and of course, there is the AQVOX SE. Lots of promising options which is good because a good network switch is a must unless you go wifi.
Straight out of the box, even without the Ref10 and despite the initial harshness, I was simply blown away by this switch. What is amazing is I thought I knew what to expect based on my experience with the prototype and yet my expectations were still exceeded. As good as the TLS switch is, this switch is operating several notches higher. This switch isolates, that's for sure, but more impressively, it acts like a gain stage. Dynamics are unreal. Everything is just bigger and badder but this switch also portrays the subtlest of nuances and the most delicate textures. To my ears, this sNH-10G is their most impactful device that I have heard. More impactful than the sMS-200ultra Neo, tX-USBultra, or sCLK-OCX10 master clock and so if I were forced to choose a single SOtM product, this would be it. Even without the master clock connected, this switch is just killer. With the Ref10, there is greater refinement with truer timbre and a touch more air but the Ref10 is more of a finishing piece and not an absolute must. If you're on the fence between buying something like the Ref10 vs this switch, by all means, buy this switch first.
How well does it isolate? Really well and it is a landscape-altering piece. Back when I first received the prototype, I stated that I could discern no meaningful difference when either my Zenith SE or my Mac Pro was functioning as my RoonServer. As I was without SOtM's switch for all of my NUC testing until now, as you know, I suggested that the RoonServer was making a pretty big difference. With SOtM's switch between RoonServer and RoonBridge, there is still a discernible difference but depending on your listening preferences, you may actually prefer not to use headless AudioLinux on your RoonServer.
Let me explain. On Friday, before I left to attend some medical meetings, I had a friend come by because he wanted to borrow one of my NUCs to try in his system and so while he was by, I got his opinion on this switch. This friend has a very good system comprised of an Ayon tube DAC, tube preamp, and tube amplification. While it is not entirely my cup of tea (a bit too soft and rounded for my tastes), absolutely nothing sounds harsh in his system and with certain vocal tracks, it is just heavenly and you can listen for hours without fatigue. Nonetheless, my friend prefers a more laid back presentation and he found that with the SOtM switch in place and with headless AudioLinux running on my Mac Pro in Extreme mode, the presentation was too forward and the bass was too strong. While I don't completely agree with his assessment, I do agree that with this switch in place, I could very easily live without AudioLinux on my RoonServer. I do still prefer the more incisive nature of AudioLinux with the Mac Pro for my orchestral pieces but it is no longer a dealbreaker not to have it. Without a doubt, with this switch in place, the quality of my RoonServer matters less.
When I feel I have something useful to contribute and when time allows, I'll post again but I'm not sure when that will be. Until then, best wishes and happy holidays!
linux setup pt 2
A novel way to massively improve the SQ of computer audio streaming
AudioLinux Installation Guide 2:
** Continue from the end of Guide 1. **
1. Unplug the USB disk. Note: After the burning, Windows can't recognize it and hence can't eject it.
2. Insert the USB disk to a PC (power off) which you want to run the AudioLinux GUI mode
3. Power on the PC, get into the UEFI, from the boot menu, choose the just created USB disk as the boot device and boot.
4. Wait a relatively long time until you see a Windows environment (see the image below). In the process, some text comes out from the screen. Error message may come out but don't worry. Wait until Windows environment comes out.
Steps to mount a local drive
1. Click the Start here folder (it may lag few seconds depend on the speed of your computer and the USB disk)
2. Click the local Drive that contains your music files
3. Input the password audiolinux0 as the password to mount
4. Check the mount is complete.
5. (As an example) Launch HQPlayer
6. Add you library, set the settings of HQPlayer and play your music by HQPlayer.
End of guide 2. Enjoy!
1. After reboot, the mount of the local drive is gone.
2. Linux is pretty stable, you may leave for tens of days. Hence 1 won't introduce much problem.
3. Auto-mount of a drive is possible but needs using terminal, issue commands, and editing the file fstab. It's better for the users to read the instructions and follow. The boot may not be possible if fstab is wrong (as stated in the official site.)
4. In principle you may do the RAMBoot. However it's better to set up everything properly before using RAMBoot.
rufos dd build
A novel way to massively improve the SQ of computer audio streamingOn 11/4/2018 at 1:13 AM, austinpop said:
The trick with the audiolinux site I'm finding is that instead of looking for a "guide" per se, you should just search on the page for terms you care about. For most people, these are the things you want to know:
- install on USB: search "install"
- "Roon" to start/stop Roon Core, Bridge
- "DHCP" to switch between dynamic and static IP
- "ramroot" and "ramsave" about running in RAM
It still requires you to be computer literate, so this is really not for everyone.
It seems that a few members are still waiting for the guide. I'll post, for the computer illiterate.
AudioLinux Installation Guide 1:
0. download the RUFUS and but the image from Piero.
Process A: Installation to an USB disk
2. Choose the DD option
3. Select the image
4. Burn the image to the USB disk
5. Everying will be erased. click OK to proceed.
6. Wait till and 100% and wait more.
7. When the burning is truly finished, the start button will be available again.
Will try to do some screen capture for the running of the lxqt (GUI) version and post it here later. Hope everybody may enjoy this sw, one of my best invested $29 ?
Roon and audiolinix
A novel way to massively improve the SQ of computer audio streaming
The trick with the audiolinux site I'm finding is that instead of looking for a "guide" per se, you should just search on the page for terms you care about. For most people, these are the things you want to know:
- install on USB: search "install"
- "Roon" to start/stop Roon Core, Bridge
- "DHCP" to switch between dynamic and static IP
- "ramroot" and "ramsave" about running in RAM
It still requires you to be computer literate, so this is really not for everyone.
Mac Better than HP?
A novel way to massively improve the SQ of computer audio streaming
Right now, I'm too busy to respond to some of the questions asked of me or to provide more details about recent findings but I will provide this one detail. With Piero's help, I was able to run headless AudioLinux on my Mac Pro and I was able to compare it against headless Linux on my HP workstation. In both instances, AudioLinux is running completely in RAM and so the PCIe SSDs on both these machines are running idle and not being utilized. I know this because my drive lights are not coming on at all.
As previously stated, my HP workstation utilizes an 8-core Xeon with a base frequency of 3.4GHz and 25MB of SmartCache and a TDP of 150w. My Mac Pro utilizes a 12-core Xeon with a base frequency of 2.7GHz and 30MB of SmartCache and a TDP of 130w. I can tell you that the Mac Pro is sounding better.
Is this because more cores is more important than faster CPU clock speed? Is the bigger SmartCache responsible? Both have monster TDPs but is the lower TDP of the Mac Pro's Xeon contributory? I'm not sure but if I were to hazard a guess, I'm thinking that more cores do make an impact and the avoidance of higher clock speeds is resulting in lower noise. Obviously, having a larger SmartCache can't hurt.
Roon core info
A novel way to massively improve the SQ of computer audio streaming
A further update...
I was able to obtain a NUC7i7DNBE motherboard today to compare against my NUC7CJYH.
To compare the differences, this new board has a 4-core i7 running at a base frequency of 1.9GHz along with an 8MB SmartCache while my other board uses a 2-core Celeron with a base frequency of 2GHz and only a 4MB cache (not a SmartCache). The new board uses an integrated Intel I219LM Ethernet controller while my Celeron board uses a Realtek 8111H Ethernet controller. With the more expensive NUC, better parts are used. Both boards utilize an SoC architecture meaning the integrated LAN and USB ports have direct, low latency access to the CPU similar to the PCIe bus. The NUC7i7DNBE board has the capability of being internally powered via a 2X2 Molex connector whereas the Celeron board can only be powered via a 2.5x5.5mm barrel connector although at this time, I am powering the new NUC board via the same barrel connector as my Celeron board.
My first order of business was to compare this more powerful i7 NUC against my even more powerful HP Workstation as a RoonServer. Even though Intel suggests you can uprate the TDP of the i7 on the NUC from 15w to 25w, there is no way to do this in the BIOS and so it is probably something you have to do within Windows and so at this time, I am forced to keep this NUC at the 15w TDP setting. The BIOS allows me to turn Turbo and Hyperthreading on and off. I can also select "All Cores" or only "1 Core" as being active. As a RoonServer, both Turbo and Hyperthreading were turned on and "All Cores" were selected. I also selected "Maximum Performance" rather than "Power Saving."
The Kingston HyperX RAM that failed to work in my Celeron NUC somehow works fine in this i7 NUC and so it would appear there is a compatibility issue with this particular HyperX RAM and the Celeron NUC even though both the HyperX and Ballistix memory are 1.2V DDR4-2400 SODIMMs. Just like with the Celeron NUC, I have elected to use only 4GB of memory with this new NUC.
There is a BIOS setting that allows only "trusted" OS's to boot. This needs to be unchecked, otherwise, the AudioLinux USB stick fails to boot. With this setting unchecked, AudioLinux and RoonServer boot into memory just fine. When compared against my Celeron NUC as RoonServer, the improvement in SQ with this i7 NUC is immediately evident. The thinness is gone. However, compared against my much more powerful HP workstation, the HP still sounds better overall. There is a slight harshness with the HP possibly due to the more powerful and noisier hardware which includes a PCIe SSD but dynamics are better and more dimensional and tone is fuller. The harshness isn't readily noticeable with my very best recordings but I suspect it could be fatiguing with certain tracks and with prolonged listening. While this particular i7 NUC isn't powerful enough to satisfy as a RoonServer, it has now shown me that perhaps a higher power diskless (or at least SSD-less) RoonServer is indeed the way to go.
I then assessed the i7 NUC as a Roon endpoint. The first thing I did was to assess this NUC with "All Cores" turned on versus only "1 Core." With only a single core operational, this core now gets the entire 8MB of SmartCache to itself. Well, "All Cores" sounds better than "1 Core" and so it would seem that RoonBridge is a multithreaded app and that the ability to parallel process among multiple cores is more important than having a big cache.
I then compared Hyperthreading and Turbo "off" vs "on." The difference is more subtle but to have Hyperthreading and Turbo turned "off" sounds better (smoother) and so they were kept off.
With the i7 NUC compared against the Celeron NUC as a Roon endpoint, I"ll cut to the chase and state the i7 NUC is better. Tone is richer and fuller and more dimensional. There is also a more effortless quality to the presentation of the i7 NUC. Here's the problem, this i7 NUC board cost me $530 while the Celeron NUC board cost only $120. Is the i7 NUC worth more than 4X the Celeron NUC? Because the Celeron NUC already sounds so darn good, I could make a case for sticking with the Celeron NUC. At the price point of the Celeron NUC, I am not aware of a product that performs anywhere close to it, however, for those looking for that last ounce of extra performance, I'm sure there are those who will find the i7 NUC to be worth the extra expense.
AudioLinux and NUC Troubleshooting and Tuning
Random Tips and Tricks
Here are some random tips and tricks for AL headless. Since these are for system changes, don't run this in ramroot mode. ssh into the system, and run as root. Finally, make sure the USB stick is inserted. Been burned by this before!
First, disable ramroot
- ramroot remove
Fix the time zone:
timedatectl set-timezone America/Chicago (pick yours - look in directory /usr/share/zoneinfo)
Start NTP daemon (to keep the system time in sync)
Edit the file: /etc/systemd/timesyncd.conf
Change previous [Time} stanza to:
NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org 3.pool.ntp.org
Run timedatectl set-ntp true
It may take a few minutes for the sync to occur, after which your system date and time will be accurate.
hostnamectl set-hostname <NAME>
List detailed system HW info
(pop out of root to run yaourt)
yaourt -S inxi
Once installed, run: inxi -Fc0
Reducing the size of the RAM root partition
You might want to do this for a couple of reasons - to reduce boot time, and to increase free memory - for example, to run squeezelite with larger -b buffer. As you do each step, monitor the used space on the / filesystem with command df.
Uninstall unwanted packages
List all installed packages: pacman -Qe
For each package you want to uninstall, e.g. in my case, I don't use HQPlayer.
pacman -R hqplayer-network-audio-daemon hqplayer-embedded
Warning: don't go nuts here. Most of the packages are there so you can build any new packages you may want to install. I would just focus on the audio packages like Roon and HQPlayer.
Delete pacman temp files
Clean up journal
Check current journal size: journalctl --disk-usage
Pick a max size you’re comfortable with, say 32M
Trim journal down to that size: journalctl --vacuum-size=32M
Set threshold for future growth:
Uncomment (remove #) and change line to SystemMaxUse=32M
Delete core dumps
rm -rf /var/lib/systemd/coredump/core*
rm -rf /run/systemd/coredump/core*
Once you're done making changes:
ramroot -F enable
Monitor free memory at run time
Monitor memory in use with free and/or top
After RoonBridge has been running for a long time, when you run free, you'll notice that the size of the FS cache - see the buff/cache column in the output of free - has grown quite large. If you want to reclaim this space and make it free again, say to run squeezelite with large -b values, run:
echo 3 > /proc/sys/vm/drop_caches
- First, disable ramroot