bobfa

View Profile See their activity

Posts
1996
Joined
February 27, 2017
Last visited
9 hours ago
Country
United States

11 Followers

About bobfa

Retained

Member Title
Fully Immersed!

Personal Information

Location
Illinois, USA

Recent Profile Visitors

52911 profile views

Mops911

18 hours ago
hlkaye

Sunday at 12:41 PM
mgbpuff

September 18
Crom

September 17
Ozeki

September 15

Bookmarks

Filter By
- All
- Sticky

for study
A novel way to massively improve the SQ of computer audio streaming

@flkin, thank you for taking the time to report your findings in great detail. Your data points, especially against the Antipodes CX+EX, are of great interest to me personally. Ultimately, it is how one component compares to another component that I find the most valuable perspective and you did that very well!

Based on your initial favorable comments about the Pink Faun 2.16 some months ago, I had phoned Pink Faun in the Netherlands to try and better understand their philosophy. I want to say that I spoke with Jord but I can't remember for sure. Regardless, we spoke for nearly 1.5 hours and I came away intrigued by their approach. Here were my main takeaways:

1. Because upsampling with HQP is a key component to their 2.16 server, they believe that more power (and not less power) is better because "faster" = lower latency. This appears to be Sound Gallerie's approach with their SGM 2015 (and now, their new SGM Evo) and so if a comparison is to be made, ideally, it should be against the Evo. Having heard how good the SGM 2015 sounds, I think they have made a good case for this "more is more" approach.

2. Unlike everyone else, Pink Faun feels AMD sounds better than Intel which is why they went with the specific 8-core AMD CPU, chipset and board that they did. Based on your own favorable comparative assessments of the 2.16, it would appear that their decision to go in this direction has been well founded.

3. The 2.16 can incorporate up to 6 independently powered OCXOs depending on the buyer's preference (CPU, chipset, LAN, USB, SPDIF, I2S, etc). Wow.

4. The 2.16 has the potential for up to 20 linear rails of power (depending on the needs of the user) coming off of 2 large transformers. Moreover, the power supply has an energy storage capacitance of >800,000uF. This is more storage capacitance than my Soulution amplifier! There was a time when I thought something like this was overkill but not any longer. There's a reason why a Paul Hynes SR7 sounds better than an SR4 for a tiny component like a tX-USBultra that barely draws a few watts and according to Paul, it has to do with having plenty of overhead so that the supply is always operating within its optimum power band. Unless it's a typo, it looks like the new Sound Galleries Evo will have a storage capacitance of 3.76 million uF. Let the server PSU wars begin.

5. The 2.16 consumes 100 watts at idle and runs fairly warm and so it requires a well ventilated space. Because the OCXOs need to be kept heated to sound their best and because it can take a long time to heat up the OCXOs, the 2.16 should ideally be kept constantly running. I don't think the 2.16 is going to win any "eco" awards. This is a legitimate concern and probably the biggest downside of the 2.16 for me since my equipment is stored in a cabinet.

6. Pink Faun is presently testing their own low-power mini streamer based off an ASUS Tinker Board which is even smaller (and potentially lower latency) than a NUC. This streamer will have both USB and SPDIF output capability and can be powered by a 5V/2A supply. Color me intrigued on this device. At the time of my conversation with them, there was no word yet on how good this sounded.

Now, taking into account your own findings, it would appear the 2.16 is the best server you have heard/owned to date and you certainly have put it against some tough competition. Here are a few of my own recent findings and comments and so perhaps, I can add to the body of information that could help the community at large.

@lmitche was kind enough to configure a low power NUC for me with his optimized version of headless AudioLinux running on it (thank you, Larry!). The model I purchased (NUC7CJYH) cost me $120 and incorporates my preferred J4005 2-core Celeron with a 10w TDP and a 4MB L2 cache (2MB of cache per core). My previous NUC had only 1MB of cache per core. This particular model has no eMMC drive and so once AudioLinux boots into RAM via a USB stick, Larry configured it so that I can remove the USB stick and so this is a completely diskless NUC endpoint running RoonBridge. Where my previous NUC's OS consumed 5.8GB of memory, this more compacted version of AudioLinux consumes <3GB of memory. Most would assume that this NUC should sound better than my NUC and indeed, that is correct. The improvement is considerable and so kudos to Larry.

During this time, I also had access to SOtM's latest sMS-200ultra Neo. When I last owned an sMS-200ultra, it was before I owned the Ref10 and so I felt it was important to revisit the latest incarnation of the sMS-200ultra to see how it would compare to the NUC. As a similarly small device designed from the ground up for audio, I always felt these types of devices should rule the world. WIth the sMS-200ultra Neo connected via Habst cable to my Ref10, even though I no longer had an original sMS-200ultra on hand for direct comparison, I very much liked what I heard and it was indeed better than what I recall my sMS-200ultra sounded like. Where I felt the original sMS-200ultra sounded incisive, airier, and more detailed compared against my microRendu, there was a beguiling smoothness and naturalness to the microRendu that was also very pleasant. What is interesting is that the ultraRendu has gone more in the direction of the sMS-200ultra and in some ways, sounds even more detailed and more mechanical whereas the new Neo has gone more in the direction of the original microRendu as it has given up some of its incisiveness for a harmonically richer and more natural sounding presentation. In isolation and when powered by my SR7, my immediate inclination is that the new Neo is a winner and it definitely is. However, in comparison, I still found my NUC to be better and not by a small margin. If I were to provide 2 descriptors that sum up what this NUC offers, especially when powered by a DR SR7 rail, it is "presence" and "energy." It was this same presence and energy that drew me to the Innuos Zenith SE and now draws me even further with this NUC.

But here is where things get interesting. As I previously reported, I found my best SQ when this NUC was used purely as a Roon endpoint (renderer) while server duty was taken over by a separate server. While this NUC was capable of full server and endpoint duty and while playback occurred smoothly, SQ sounded strained. While my Zenith SE filled the bill very nicely as a RoonServer, when I placed SOtM's new sNH-10G network switch between my RoonServer and Roon Endpoint, it no longer seemed to matter what I used as a RoonServer. In other words, my unoptimized Mac Pro with its noisy 12-core Xeon, 64GB of RAM, dual GPU, and 1TB of PCIe SSD storage sounded just as good. If there was a difference, it was too small to worry about it.

WIth my 2nd NUC in hand, I now had the luxury of trying my original NUC as the RoonServer. Even though I couldn't hear much difference between Zenith SE and Mac Pro as RoonServer, would this NUC running AudioLinux in RAM result in an improvement? Of course, with only 8GB of memory, there isn't much room for any kind of a Roon database and so I configured this NUC for Tidal streaming only through Roon. Even with the lower latency you get by running your OS completely in memory, there are definitely latency penalties by using a Celeron vs a 12-core Xeon when it comes to all the tasks that RoonServer is responsible for. For example, browsing through my Tidal library occurred much more slowly through the NUC. Nonetheless, it is SQ that matters and here is what I found.

With my original NUC powered by a 12V rail from my SR7 and functioning as RoonServer and with my new "Larry" NUC powered by a DR 12V rail from my SR7 and functioning as RoonBridge, transients had better snap and seemed faster. However, with my Mac Pro functioning as RoonServer, there was better dimensionality with richer, deeper and more natural tone. In this instance, the Mac Pro was sounding better overall than my NUC as RoonServer. How could this be?

A couple of thoughts...

1. I no longer have SOtM's sNH-10G switch in my possession as that switch is now with Rajiv. While SOtM thought they would be shipping this switch by now, they are having difficulty procuring enough chassis and so it remains unclear when their switch will be available and so I am presently using TLS's very fine switch but I don't think this switch isolates as well as SOtM's switch and so this may be accounting for some of the differences I am hearing.

2. When it comes to the heavy lifting required by RoonServer, I believe Pink Faun's philosophy is the correct one. More power = faster = lower latency. I continue to argue that with a "one trick pony" RoonBridge device, blazing speed and power are unnecessary and even unwanted and so I am very intrigued to see what Pink Faun's new Tinker board mini streamer will sound like but when it comes to RoonServer and especially if the user plans to upsample with HQP or employ DSP room correction, the more power the better. The challenge with a high power RoonServer is they are more difficult to power well (just look at what went into the 2.16) and so there will be cost, energy, and heat considerations to take into account.

I believe there is growing consensus from the likes of Antipodes and Pink Faun that for ultimate SQ, you need to distribute tasks between multiple machines. In my current situation (without SOtM's switch), it would seem that both server and renderer matter and that attention needs to be paid to both which is an unfortunate bursting of my bubble, however, I continue to strongly believe that the renderer has the greater overall impact. If I were to assign a level of importance, in the absence of upsampling or convolution, I would say the renderer has at least 80% impact while the server has at most 20% impact. This bodes well because a good renderer costs a lot less than a good server and so I am hoping this observation stands the test of time.

For those who plan to upsample or employ DSP-based room correction, I feel you have less choice. If SQ is your top priority and if finances permit, then it would seem that the 2.16 should be on your short list but then so should Sound Galleries' offerings. Otherwise, you might just find this cheap AudioLinux-based NUC to be the worldbeater that the audiophile community has been waiting for.

A final word on convolution. I have explored this with AudioVero's Acourate convolution software and I expect to explore it further because I do feel it has merit but there are consequences. With the help of Uli Brueggeman from Germany, I was able to map my room and at various seating positions, we were able to determine my room's frequency response and where my nodes are. He created idealized convolution profiles for me that I plugged into HQP and while I was able to effectively flatten my frequency response, it seemed to occur at the expense of harmonic richness and depth. In other words, altering the audible frequency response of my room had an impact on the harmonic frequencies that was akin to trading accuracy for emotional impact. The biggest negative was the soundstage became flatter. The good news is that Uli is capable of creating graded profiles and so it's possible I will come across a profile I like. The reason I bring this up is to highlight the pros and cons I have found with room correction. If you're going to do it, definitely do it in the digital domain because with analog EQ, there will be resolution penalties but even in the digital domain, there are challenges. If you employ it at the server level, then you will require a powerful server. If you buy a device specifically designed for digital room correction like a Lyngdorf, DEQX, or Kii Three, then you're stuck with the DACs that are built in to those devices and thus far, I have not liked what I have heard. If at all possible, I feel it's better to optimize the room rather than to digitally shape the sound but I also realize that this isn't always possible.

December 29, 2018
A novel way to massively improve the SQ of computer audio streaming
A novel way to massively improve the SQ of computer audio streaming
Note from @austinpop

While I am now the OP of this thread, I did not start it. That would be @romaz. I have just been given authorization by him to take on the OP role.

A brief history of this thread - by @austinpop

Last update: Dec 13, 2018

This thread is almost 2 years old, with over 12,000 posts, and over 860k views.

While it was started by Roy @romaz about the positive SQ impact of ethernet bridging between a music server and an endpoint, it has since grown to span the gamut of the entire digital chain. Loosely speaking, this thread is an exploration of mechanisms that are observed to improve SQ in the streaming chain. This covers the path from the music file at rest on a storage device all the way to the input of a DAC. Conventional wisdom would suggest this path should have no, or very little, impact on SQ. Yet, as the 2 years of experience on this thread has shown, this path has a profound impact on SQ.

Undoubtedly, the topics covered have meandered. This is, after all, a forum thread! Over its lifetime, the topics and areas covered have included:
1. Network bridging
2. quality of power supplies
3. quality of clocks - both data (related to the data sample rate) and system (USB, ethernet, and motherboard) clocks
4. reference clocks
5. mods - mobos, NICs, USB cards
6. DDCs
7. cables
8. DACs
9. NUCs
10. Audiolinux
11. and many other topics.
The focus of this thread is on direct listening impressions. We were lucky that, from the outset, the early participants set a tone of experimentation with the proposed ideas, and reporting their results. Over time, this guiding principle has been enthusiastically adopted, and many participants have extended the body of knowledge with their experiments and reports. This has resulted in a thread with a reasonably high S/N ratio. Most of what is discussed here does not have a readily available analytical explanation. We would not have gotten this far if we had gotten mired in the "how could this possibly matter" debate.

To preserve this S/N ratio, and to keep the thread from disintegrating, we ask contributors to focus discussion on direct listening experiences.

I have created an index of useful posts to help the new reader navigate this massive thread. Please scroll further down to see the index.
Moderation

We welcome your participation in this thread. Please note that discussion needs to stay focused on direct listening experiences with audio experiments discussed here. This is not an opinion thread. Most of what is discussed here does not have a readily available analytical explanation. Once we get into arguing about the why's, this thread is going to disintegrate. If anyone comes in here, makes no contribution, and attacks people, I reserve the right as OP to delete their posts.

Further - this thread is about listening impressions. We do not:
- Demand proof
- Require a specific methodology
- Require measurements.
Original post by @romaz

======================================================================================

Ok, MASSIVE is a bit of an overstatement at this level of high-end audio but now that I have your attention, I would say that this improvement is quite significant, nonetheless, and once you hear it, I suspect you will not wish to go back to your previous setup. More importantly, this is neither difficult nor expensive to implement.

Much has been said about how ethernet renderers like the microRendu and the sMS-200 are immune to upstream components. Because ethernet is transformer coupled, it is inherently galvanically isolated and because of the error correcting packet protocol it employs, data is always bit-perfect and so it would seem that ethernet is an ideal data delivery vehicle for a digital audio stream. Indeed, when I first purchased my microRendu back in May, I tested it with a variety of standard sources including a Windows NUC, Windows laptop, Mac Pro, Macbook Pro and sonicTransporter and even when a certain source was powered by my HDPlex, I noticed no significant difference among these sources, at least not enough to care which one was feeding my microRendu. I have also explored and compared a variety of ethernet optimization techniques including optical isolation with FMCs (powered by LPS-1), an audiophile switch with TCXO clock by Paul Pang (powered by LPS-1) and various audiophile ethernet cables (BJC CAT 6A, SOtM dCBL-CAT6 with iSO-CAT6, AQ Vodka + Diamond, Supra CAT8, WireWorld Silver Starlight CAT8) and while they can and do make a difference, even collectively, the difference has never been that great, certainly not enough to want to spend lots of effort or money on these things. At least that has been my experience and so this is a compliment to both the microRendu and the sMS-200, that they are that immune to what is upstream...or are they?

Like with many of you, things changed when I received my LPS-1 as this power supply was eye opening in how it transformed my microRendu. This should have come as no surprise as John Swenson had been telling us all along that the microRendu, as a low noise and low impedance device, benefits from a low noise and low impedance power supply. What I wasn't prepared to experience, however, was how a good low noise, low impedance power supply would also transform my upstream components including a simple NUC or Mac Mini even with the microRendu or sMS-200 in place (I own both of these units). It was surprising to find out that even my internet modem/router similarly benefited. It turns out that while ethernet is good for isolating noise, it cannot fix a signal already molested at the modem/router or music server level. In the same way that the LPS-1 improved both the macro and microdynamic capabilities of my microRendu, my Paul Hynes SR7 has also magically transformed my modified Mac Mini and internet modem/router and both the microRendu and sMS-200 fully reveal these benefits but truth be told, these benefits are much more fully realized if these endpoints themselves are powered by a low impedance PSU. This is not some mild transformation that you need to blind test to convince yourself is real, this is something a semi-deaf person can distinguish because the dynamic contrasts with the Paul Hynes SR7 driving both my Mac Mini and internet modem/router is that much more thunderous, enough so that I have had to literally turn my subwoofer down a notch. If you think about it, there's no good reason why this shouldn't be happening. The whole purpose of the microRendu or sMS-200 and devices like the USB Regen is to present a DAC with a signal of the highest integrity. Why wouldn't the microRendu or sMS-200 similarly benefit from being presented with high signal integrity by the components before it?

I have come to the conclusion that this impact has more to do with low impedance than the low noise characteristics of the power supply fronting these upstream devices because as you recall, ethernet is transformer coupled and so is inherently galvanically isolated and with the FMCs that I employ in my network (which are powered by my LPS-1), no RF noise or leakage current should be reaching my microRendu or sMS-200. What is the measured output impedance of the Paul Hynes SR7? According to Paul, his SR5 and SR7 measure ❤️ millohms from DC to 100kHz and so consider this number as a reference point for comparison. Having asked around, it seems no one else can provide these impedance measurements over what John Swenson describes to be his ideal frequency range either because they don't own the measuring equipment to do so or because they don't believe this spec is important. What I can tell you is that neither my HDPlex or Teradak are low impedance LPSUs because neither of these units are good enough to allow me to distinguish one source from another when fronted by either the microRendu or sMS-200 and both are soundly trounced by my LPS-1 and my SR7 when it comes to soundstage dimensionality. While I have not had the opportunity to compare the Sonore Signature Power Supply to either of these two units, based on what I am hearing from respected sources and conversations I have had with Barrows, I have no doubt this is an excellent and very low impedance PSU. Based on how good the LPS-1 is, logic would suggest Vinnie Rossi's ultracap-based supply is likely of similar caliber. The problem with these other supplies is that neither of them have enough juice to power a Mac Mini, Nuc or my TP-Link internet modem/router as each of these devices require at least 12V/3.5A.

Of course, this discovery led to quite a bit of curiosity about other areas. What would happen if I directly connected my Mac Mini to either my microRendu or sMS-200? Intuitively, I had a hard time believing this should make a difference. If so, why weren't the microRendu or sMS-200 designed by their wise creators to connect this way? I further had a difficult time believing my internet modem/router or my Paul Pang switch with TCXO clock should have any real detrimental impact on either of these endpoints since the modem/router was currently being powered by my Paul Hynes SR7 and my Paul Pang switch was being powered by my LPS-1 and moreover, I had optical isolation in place and yet Mark Jenkins, owner and developer of the Antipodes line of music servers, had this to say about his latest generation Roon Ready DX music server. This excerpt is taken from John Darko's review of this latest generation DX server:

"A third way to plumb Roon inside the DX is to have Roon Core talk to Roon Ready directly. Think of this scenario as Roon playing out the server-client model not on a LAN but inside a single computer.

Jenkins clarifies: "They [Roon Core and Roon Ready] talk using RAAT but when they are in the same device they do not need to use the not-so-good comms layers that sit underneath RAAT when the two apps talk across a network."

I'm not sure I know what Mark meant by this exactly but he details a greater clarity and immediacy to the sound of Roon using this method and so I felt compelled to try and create this direct connection between my Mac Mini and my microRendu/sMS-200. This wouldn't be so difficult if either device had the ability to assign itself a static IP. Unfortunately, this was never possible with the microRendu and this feature was taken away from the sMS-200 after firmware 1.9 and because each device must be assigned an IP address by a router for control purposes, it didn't appear as if there would be an easy way to accomplish this.

It turns out OSX can function as its own DHCP server and so I used El Capitan to assign an IP address to one of the two ethernet ports I have on my Mac Mini (the Mac Mini comes natively with only one ethernet port but my Thunderbolt hub comes with its own ethernet port thereby giving me two such ports). I connected my sMS-200 to one port and my router to the other port and it worked but there were problems. Because OSX insisted on connecting this second port on a separate subnet, my sMS-200 had no outlet to the internet (for Tidal streaming) nor could it be controlled remotely by my iPad and so this was a "no go." When I manually forced both ports to be on the same subnet, my Mac Mini would get confused as to which ethernet port had control and it would lock up. It then dawned on me that I could bridge the two ethernet ports and BINGO! This accomplished exactly what I wanted to accomplish. Both ethernet ports were now on the same subnet and with one port connected directly to my sMS-200 and the other port connected directly to my router, everything was running smoothly. I could now easily access the sMS-200 remotely from my iPad and other machines that were on the network and the sMS-200 could access the internet. While I have not yet tried my microRendu this way (it is presently on loan), I don't see why it wouldn't work the same way. What is interesting is with this bridged configuration, my internet modem/router is now responsible for assigning the sMS-200 an IP address and yet the sMS-200 is physically directly connected to my Mac Mini without the intermediary "not so good comm layers" that Mark Jenkins describes.

So how does this direct connection sound? Simply glorious! While a low impedance power supply brings depth and dynamics to my upstream components, this direct connection brings amazing clarity and immediacy. It's as if one very thick veil has been removed and that my seat has been upgraded from the balcony to the stalls. I would rate the impact of this as equivalent in magnitude to employing a low impedance PSU. Many of you are aware of the claims many are making on several threads here on CA but also on HeadFi of how RedNet and Dante provides this "you are there" clarity. I had a ReNet 3 in my home for evaluation for nearly a month and I agree, it provides this beguiling sense of clarity that has to be heard to be appreciated although the problem with RedNet, I believe, is its inferior switching PSU. These units sound flat and dimensionless compared to my described setup above and so this clarity that RedNet brings almost sounds sterile and lifeless in comparison. Regardless, proponents of RedNet have suggested the problem with USB endpoints like the microRendu and sMS-200 is with USB. What I am hearing suggests USB is not the problem but perhaps the Dante technology by Audinate that RedNet utilizes has figured out how to eliminate the impact of these "not so good comms" in the network signal path. I have now been listening to this arrangement for much of the past week and so the initial emotions that can cloud one's judgement have settled down and my opinion remains the same as the first moment I heard it. To borrow from Chris Connaker, after all of this, I can unequivocally say that my audio system has never sounded better than it has now. For me, there is no going back.

For those interested in reproducing what I have done, first of all, you will need a music server with 2 ethernet ports. Current Mac Pros already have 2 ethernet ports. Mac Minis do not but I can verify that you can add a Thunderbolt ethernet port and it works very well. Many Windows PCs have 2 ethernet ports and if not, if you have a spare PCI or PCIE slot, you could inexpensively add one. Will a USB ethernet connection work? I don't see why not but I haven't tried it and I don't know how it will sound. I do know that you can't bridge a wi-fi connection and an ethernet connection.

So how do you bridge 2 ethernet ports? If you are on Linux, I can't help you but I'm sure it's possible. If you are on a Mac, here are the fairly simple instructions that I followed. Feel free to use DHCP but you are also free to assign a static IP:

https://support.apple.com/kb/PH18510?locale=en_US

For Windows, @jelt2359 has confirmed for me that the following directions below worked on his Windows 10 Nuc although he had to manually configure the bridge's DNS and IP addresses.

How to create a Network Bridge in Windows 10/8/7

Obviously, if you decide to try this, please report back your findings here. If there is consensus that this improvement is universal, perhaps Sonore and SOtM can be convinced to allow their units to be configured to be directly accessed more easily.

=====================================================================================

Index of useful posts

Note:
- Some sections are lacking. If anyone can volunteer to supply me with posts for these sections, I will gladly add.
- If you would like to nominate a post to this index, just PM me.
Bridging/Direct Connection
Power Supplies
Clock Mods, reclocker chains, and sCLK-EX
ISO-Regen in the Mix
Master Reference Clocks
- @romaz stunned by Mutec Ref 10 at Munich
- @JohnSwenson's insights into clock oscillators
- @romaz returns with more insights on master reference clocks
- What exactly are reference clocks?
- @hols Cybershaft 10MHz reference clock driving tX-USBultra
- @hols Cybershaft update
- @Bamber First impression of Mutec Ref 10
- @austinpop Listening Impression with the Cybershaft OP-14 Reference Clock - Part 1 & Part 2
- @limniscate Listening impressions with Cybershaft OP-14
- @romaz explains phase noise comparisons
Comparisons with other endpoints
- @austinpop Listening impressions of dCS Network Bridge vs. SOtM trifecta with Cybershaft reference clock - Part 1
- @austinpop, @limniscate, and @Bruce Orr Initial listening impressions of UltraRendu vs SOtM Ultra and trifecta, LPS-1 vs. sPS-500
Comparisons with music servers
- @austinpop Review of Innuos Zenith SE vs his SOtM trifecta chain
- @austinpop Does the SR-7 PSU close the gap between the SOtM trifecta and the Zenith SE?
DACs
- An excellent perspective on DACs
- @romaz expounds on his DAVE with M-Scaler
Ethernet cables, isolators
- @romaz's experience with iSO-Cat6 and dCBL-Cat7
Ethernet Switches/SFPs
USB Cables
- @hols Update on ISO-R and liking the new Lush USB cable
- @romaz Experiences with USB cables
Computer mods - mobos, NICs, drives, etc
- Booting Win on Mac Mini and benefit of AO:
Adnaco fiber mods
- @romaz initial impressions with Adnaco
SATA mods

General
- Excellent summary of John Swenson thoughts on USB and leakage loops
- @Superdad talks about Uptone thoughts on future Ethernet upgrades
- From another thread: JS explanation of how asynchrony in USB actually works, and why the source clock still matters
- SSG 360 cable shielding scheme
- @austinpop Dummy DIY guide to JSSG 360. If I can do it, anyone can!
NUCs, in-memory OS, and AudioLinux
December 29, 2018
A novel way to massively improve the SQ of computer audio streaming
A novel way to massively improve the SQ of computer audio streaming

I have been asked to list the main features of audiolinux.

I would like to put in evidence that if you would want to configure an archlinux base installation so that is identical to audiolinux, it would take very much time…

• AL is using a realtime kernel with very low CPU latency. This custom compiled kernel is based on realtime BFQ kernel with some adjustments and some patches. The last version can be downloaded here: https://www.audio-linux.com/ftp/packages/kernel/last/linux-rt-bfq/ This is the last 4.19.x with more patches for audio. The performance of this type of kernels with a decent processor is impressive: http://www.audio-linux.com/#LATENCY

• AL tunes the realtime priorities of processes and interrupts using rtirq and rtapp (this last developed by myself) with the possibility of fine-tuning for your system, see http://www.audio-linux.com/html/realtime.html This has nothing to do with the “nice” parameter in linux (in this case is irrelevant) or the priority in non-realtime kernel or priority assignments in Windows. In realtime kernels if an audio application has some priority all other tasks will be executed after. This will decrease the impact on sound of other running applications but also of other equipment connected to your PC (this because of irq priority assignments). Also frequency of rtc0 and hpet is adjusted.

• AL implements the ramroot utility to allow RAM-resident OS for best sound quality. If the application allows it you can load also a song to RAM (see buffer parameter in squeezelite, for example). The ramsave script for saving the system in ram mode is original.

• AL preinstalls the most important audio services and applications like Roon and HQPlayer (and in lxqt version Logitech Media Server, Squeezelite, MPD, UpnP for MPD) so it works out of the box. These applications are already partially configured.

• In AL you can install easily the application you want and eventually compile it with your parameters. All necessary packages for compilation are already installed. This is an “open” system where you can decide what you want and how to configure it. The update of applications can be made from the inside with a simple command. You can update daily, if you want.

• In AL you can start (or enable at boot) audio services very easily with custom scripts. In headless version with the configuration menu, in lxqt version with shortcuts in the Desktop.

• Think to AL not as an image, but as a service. I have contributed to the fine-tune of many systems and if necessary I have made some special features on request. See for example the new how-to for big Roon database in ram mode: http://www.audio-linux.com/html/roon.html Recently I have also made a custom cover downloader and an HTTP server for accessing covers from mpd client. I am giving support not only to audiolinux but also for hqplayer, mpd, roon etc.

December 29, 2018
Linux setup
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:
    [Time]
    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.
- Set hostname
  - 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
  - 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:
    
    Edit /etc/systemd/journald.conf
    
    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
December 29, 2018
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.

December 29, 2018
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.

December 29, 2018
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.
December 29, 2018
rufos dd build
A novel way to massively improve the SQ of computer audio streaming
On 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:

Resources:

Steps

0. download the RUFUS and but the image from Piero.

Process A: Installation to an USB disk

1. LaunchRufus

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 ?
December 29, 2018
linux setup pt 2
A novel way to massively improve the SQ of computer audio streaming

AudioLinux Installation Guide 2:

Preparation:

** 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!

Note:

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.

December 29, 2018
SOTM Switch Intro over
A novel way to massively improve the SQ of computer audio streaming

23 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!

December 29, 2018
ram boot setup
A novel way to massively improve the SQ of computer audio streaming

AudioLinux Guide 4

RAMBoot

Environment: AudioLinux already launched in GUI mode

Steps:

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.

December 29, 2018

SE kreference
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.

Listening Impressions

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

Notes:

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.

Wrap 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...

December 29, 2018

General AL setup
AudioLinux and NUC Troubleshooting and Tuning

11 hours ago, BigAlMc said:

@ray-dude & @austinpop,

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:

Squeezelite endpoint

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! ?

Cheers,

Alan

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

Run: rtstatus

This will show you the real time priorities for various applications and IRQs (HW interfaces)

Run: rtcards

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

Edit: /etc/rtirq.conf

Change

RTIRQ_NAME_LIST="usb"   <--- All the USBs have high priority
RTIRQ_PRIO_HIGH=90

to

RTIRQ_NAME_LIST="xhci_hcd"   <---- Only the DAC interface has high priority
RTIRQ_PRIO_HIGH=95

If you like, you can also make your ethernet a high priority by having it be:

RTIRQ_NAME_LIST="xhci_hcd eno1"

(order matters)

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.

Edit: /etc/rtapp/rtapp.conf

APPLICATIONS="squeezelite RoonBridge jackd mpd hqplayer hqplayerd RoonAppliance mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity"

MAX_PRIORITY="93"

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;

Commentary:
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!

Steps:
> 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 squeezelite@audiolinux
> Type: systemctl status squeezelite@audiolinux
Should be shown as running
> Type: systemctl enable squeezelite@audiolinux
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.

Goal:

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)

Approach:

* 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).

January 3, 2019
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:

https://www.yoycart.com/Product/549337720006/

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.

January 3, 2019
Pink FAun
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:
1. 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.
2. 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

On Clocks

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 ??

@flkin

coming soon..

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.
January 3, 2019
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!
Conclusions

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!
January 3, 2019
Ramsave timer
Audiolinux Server configurations, Software, Hardware, and Listening Impressions

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

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

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

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

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

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

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

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

January 9, 2019
Updatiing roon.
A novel way to massively improve the SQ of computer audio streaming

1 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.

Enjoy,

Larry

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

January 22, 2019
Play with dsp
A novel way to massively improve the SQ of computer audio streaming

On 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.

EDIT:

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.

January 27, 2019
Network "isolation"
EtherREGEN: The long development thread. [Some Gen2 dev. pics and update starting on page 92.]

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.

Since:

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).

Thus:

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.

January 29, 2019
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.

The Endpoint

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.

The Server

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.

CPU

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.

Motherboards

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.

RAM

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.

March 24, 2019
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

lsmod

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

Default is

pcm.!default {
type plug
slave.pcm hw
}

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)

April 5, 2019
numa
Audiolinux Server configurations, Software, Hardware, and Listening Impressions

1 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:

[audiolinux@audiolinux ~]$ 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.

April 12, 2019
Shootout at the Linux Corral: AudioLinux vs Euphony
Shootout at the Linux Corral: AudioLinux vs Euphony

On 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.

May 28, 2019
Noise
Sonore opticalRendu

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.

John S.

June 5, 2019

Sign In

bobfa

Posts

Joined

Last visited

Country

11 Followers

About bobfa

Retained

Personal Information

Recent Profile Visitors

Mops911

hlkaye

mgbpuff

Crom

Ozeki

Bookmarks

Activity

Immersive

Subscriptions

My Details