Pink Faun 2.16

[k27R]

On 8/7/2019 at 8:21 AM, EliteDJ said:

Here's a link to the SPDIF Bridge https://www.pinkfaun.com/shop/bridge/45-2880-spdif-bridge.html, my dac's best sound quality is provided by its SPDIF inputs, usb is almost as good.  I know if I spent the $12,000 on a 2.16x another household energency would occur right after I received the unit, things always seem to work that way.   I have an easier time justifying $4,000 in parts.  

 

 

I have the SPDIF bridge on my 2.16, as my DAC only has SPDIF RCA/XLR inputs.  With this setup, it's a relief to no longer need two very expensive USB cables, a USB conditioner, Mutec MC-3+ usb reclocker, 10M external clock.  I don't miss those items at all! 

[k27R]

Also, 3 weeks in and the 2.16 is sounding better every week.  No tweaking of AL from me yet, but that will be fun to play around with once I'm ready ...but I won't even know where to start!

[EliteDJ]

Nice!  What clock do you have on the SPDIF bridge?

[EliteDJ]

General question to 2.16 owners.

 

I'm wondering if it would be smarter to go with putting my $ towards upgrading the I/O, Chipset and SPDIF clocks to OCXO on my build or just upgrading the SPDIF card to the Ultra OCXO Clock and leave the motherboard clocks stock, I'm basing my build on the one used in the 2.16? 

 

Let me know your thoughts about which clock upgrades will provide the best audio quality. 

 

Just for reference, the system it will be connected to has a Wadia321 DAC, Bryston 9BSST and Martin Logan Aerius speakers.  A possible speaker upgrade will be next year due to Aerius age and panel wear. (Original Panels)

 

Thanks for your time and input. DK

[k27R]

I opted to upgrade the mobo clocks to OCXO first since it offers an easier upgrade path.  The bridge card clocks can easily be swapped out by yourself, but upgrading the mobo clocks need to be sent back to Jord if you don’t upgrade it to either OCXO or ultra initially.  

 

I currently have OCXO mobo clocks and standard bridge clock.  With this set up I plan to eventually upgrade the bridge and mobo clocks to ultras, and I wouldn’t need to send the unit back to Jord to do so.  So I guess it depends on what your end goal is.

[EliteDJ]

Thanks K27R.  I think I'll contact Jord to discuss what I'm doing and create the best plan for upgrading but the motherboard clocks make sense due to the fact that I'll need to ship the motherboard to complete that part of the process.  Thanks again for your response.

[lpost]

The system and MB clocks are a quick solder job if you have even rudimentary skills (on the ASrock X370 MB used by Pink Faun).  The clock on the I/O will most likely have the most impact/benefit for the $.  I would spend it there as first priority but talk to Jord if you plan to send him parts regardless.

[flkin]

Had a chance to install the latest menu/system and 5.1 kernel. Went smoothly for me executed from the old menu update page.

 

I want to discuss the new option Expert option "ENABLE/DISABLE realtime manual assignment"

 

On questioning Piero in detail about what this was all about it's to do with IRQ and audio application priorities - very important things actually! AudoLinux is already pretty compact as it's a built-up OS rather than a cut down from a large OS. But unless the assignment of priorities of what is going on internally is set correctly, the computer won't rank important priorities like "play back" over say less important priorities like "displaying/searching lists of music" correctly. 

 

I believe that is what the Extreme modes and Normal modes are already doing when AL allows one to select them. But you can get much finer control over the settings.

 

What follows are specific to the Pink Faun 2.16x and my particular set up but it might be useful for general computers as well. 

 

There are 2 files being controlled by the realtime manual assignment switch. When it is on, the rtirq.conf and rtapp.conf priorities for IRQ and audio applications respectively are in place and active. Both seem to affect the sound.

 

 

1. rtirq.conf (IRQ priority)

 

I used File Editor as Root and went to /etc/rtirq.conf

 

From suggestions on this link https://www.audio-linux.com/html/realtime.html I did the checked rtstatus and rtcards to figure out which IRQ item referred to my connected DAC. For my computer it turned out to be xhci_hcd. The original IRQ priority was simply any connected usb. If I had other USB devices connected, my PF would have given the same priority to any connected USB device - clearly not want I want. The connected DAC should be first. So

 

Original  RTIRQ_NAME_LIST=“usb”

To           RTIRQ_NAME_LIST="xhci_hcd"

 

 

2. rtapp.conf (audio app priority)

 

I found the following on a French discussion board http://forum-hifi.fr/archive/index.php?thread-4783-14.html where someone asked and RoonLab support replied to define the Roon apps being used during playback. Seems that RoonAppliance engages in both foreground and background processes in different threads, and adjusting process-level priority would unduly elevate background work. So perhaps it shouldn't have a higher priority as an audio app.

 

After some back and forth with Piero and some analysis of what is running in the computer when playing music, we came to the following few options for listening tests: 

 

I again used File Editor as Root and went to /etc/rtapp/rtapp.conf

 

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

 

This lists priority of apps with names in the order of the priority. So HQplayer has higher priority than RoonAppliance and RoonBridge etc.Technically you can remove all names of apps not being used. But leaving them there should make no difference ... or does it...?!

• Option 1 - Disable rtapp
  • Disabling rtapp by command: systemctl disable rtapp.timer then rebooting means no priority for applications but continue to have priority for irq makes my system duller, treble is affected.
• Option 2 - Disable both rtapp and rtirq
  • Disabling realtime manual assignment makes my system much less clear, imaging far softer. I prefer it on
• Option 3 - Using rtapp APPLICATIONS="RoonAppliance"
  • Makes the image fatter and less separated. 
• Option 4 - Using rtapp APPLICATIONS="RoonBridgeHelper RAATServer”
  • Nice. Clear but not bright, engaging and good imaging. But slightly too forward imaging.

For flexibility, it should be possible to add back the other unused apps in the rtapp file but for some unknown reason, it doesn't sound as good to me! Perhaps I am imagining it.. If added back it would then be:

 

APPLICATIONS="jackd mpd hqplayer hqplayerd RoonBridgeHelper RAATServer RoonBridge mediacenter24 networkaudiod deadbeef a2jmidid ardour-5.12.0 rosegarden audacity”

 

 

 

Summary

 

This sounds really good - but might need some speaker adjustments as the image is slightly more forward than before.

 

rtirq.conf (IRQ priority)

RTIRQ_NAME_LIST="xhci_hcd"

 

rtapp.conf (audio app priority)

APPLICATIONS="RoonBridgeHelper RAATServer”

[lpost]

I've been using rtirq.conf and rtapp.conf to tune my 2.16 for the past year.  I thought you knew about them.  They've been detailed on Piero's website since the beginning.

[flkin]

Nope! Wish I had! 😄

 

Did you manage to find better rtapp apps? I'm not sure if listing the RoonBridgeHelper actually helps ..

[lpost]

I use HQPe so it's the only app listed.  It makes no difference if you list apps that aren't loaded or not installed, you're imaging it.

 

RTIRQ makes more difference I'm my system, my I2S is set to top priority followed by fiber NIC.  I found no difference by adding the NIC but no harm either so I left it.  It just ensure it gets attention when it needs it without waiting and I2S board waits for no one.

 

You might want to either check after updates, as I've seen both conf files be reset to defaults, or mark them as read-only and set the chattr +i immutable attribute so even root can't change the file.  Issue chattr -i to reenable edit.  Unless you change hw or sw, there's no reason to need to change it.

 

Verify the priority in top, see PR column.

 

[lpost]

Hello all,

 

I forgot to add, when I was running Roon straight, I gave priority to RAATServer and that I liked more than having RoonAppliance first.

 

I also find not enough sonic difference to use isolated cores for Roon as I find it just slows Roon way down.  I like all 8 cores to be able to thread.  I feel the rtapp priority has more impact for me. However, Roon isn't handling the stream to the DAC, HQPe is.  I also prefer Ramroot mode, it's easier, less strident, though it takes me a few hours of listening to fully realize it.

 

I added a 1Gbps PCIe multimode fiber nic and disabled interfaces on main board.  Nice gain for zero cost.  I had two from a server about 10 years ago.  Same for a Cisco 2960G from 2007 I think.  It has an SFP port and linear supply (or at least a decent weight transformer inside).

 

I've tweaked the BIOS a fair bit by reading guides from HP/AMD to reduce latency.  It was for realtime transactional systems where nanoseconds really count, as I believe it does for music reproduction.  Primary changes were to reduce CPU voltage just a nick or two and set load line calibration to level 1 to cause the VRM to keep voltages dips from occurring as much as it can. Makes the rails stiffer.  Reduced CPU speed to a fixed value 2.6Ghz.  2.4GGhz became a bit sluggish feeling in Roon, otherwise they sounded the same to me.  Less than 3.4Ghz sounds incrementally better as I went down, then reducing CPU V and stiffening with Level 1.  I don't want to encourage anyone to tweak the bios settings without fully understanding what the settings do and their impact on the hardware.  Over voltage and over temp are the destroyers of hardware.  Tweak with caution and prudently.  Use the save/recover bios function so you can easily revert if things go sideways.

 

I still prefer HQPe over Roon straight, enough to deal with the license fingerprint regeneration 'kwirk' that occurs ~3 reboot.  It takes a couple of reboots to get it calculate the fingerprint for the license file and then it's perfectly, 100% stable up to the 40 days I've gone between reboots.

 

I frequently run for 2-3 weeks without the need to fuss or tweak on it anymore.  I listen between 8-12 hours a day, 4-5 days of 7.  I do like to keep the menu and system up to date, but I'm more cautious with kernels.  Too many years of managing systems for a living.  Motto:  only update kernel if you need the new feature desperately or it fixes issues experienced by your system.  This assumes the machine is not subject to traffic from the open internet or other security concerns.  IPTables can be configured to allow only the IP and PORT but the 2.16 focus is music and not needing to protect itself or other hosts.

 

It's hard to believe I've had my 2.16 for 14 months already.  I keep wondering how I slow this thing we call time down.  Anyway, back to the machine. It's a fabulous build level!  Mine is hidden in a closet with HVAC out of sight so I'm the only one that truly appreciates the aesthetic and weight.  I use two low speed large USB powered fans hanging 1/4" above the left and right sides, helping convection do its job.  Reduces CPU temp by 5C to 41C nominal.  We have good climate control and insulation.  The temp varies little.

 

I believe I'm at the point I am free to simply use it to play amazing, lovely, exciting and fun music for many years to come. 

 

@k27R  How are you enjoying the magic of yours?!

[lpost]

Wouldn't you know it, an hour after I posted this I began to experience dropouts, repeatable.  Through the process of elimination, I found taking HQPe out of the mix, no dropouts.  I had -4 headroom configured and perhaps needed a bit more but now my license is not working and I'm tired of fussing with it so it's back to Roon straight for me and it sounds just fine.

 

I started with rebooting the DAC as the dropouts didn't occur in my other Roon zones (without HQPe).  Cables checked out, restarting 2.16 was the last step...lame fingerprint issue got me.  I may go back to HQPe in the future but for now, I just want to listen to music.

[k27R]

@lpost

 

Yes, my 2.16 is sounding amazing right now with minimal setting tweaks! The resolution, micro dynamics, and macro dynamics are the stand outs for me.  It really brings you into a performance.    The only tweak I've done so far (as you suggested) is enabling ramroot with Roon alone, and it definitely brings in a little bit of ease and organics to the sound.  Imaging is very sharp and 3D, but the soundstage is a tad bit forward for my taste.  I'm hoping other tweaks can widen the soundstage and make it little more laid back, which has always been my preference.

 

Since HQplayer and ramroot aren't friendly with each other just yet, next I will try ramroot disabled and HQplayer enabled.  I'm guessing you've tried this and prefer ramroot with Roon alone?    

[gdpr]

17 hours ago, k27R said:

@lpost

 

Yes, my 2.16 is sounding amazing right now with minimal setting tweaks! The resolution, micro dynamics, and macro dynamics are the stand outs for me.  It really brings you into a performance.    The only tweak I've done so far (as you suggested) is enabling ramroot with Roon alone, and it definitely brings in a little bit of ease and organics to the sound.  Imaging is very sharp and 3D, but the soundstage is a tad bit forward for my taste.  I'm hoping other tweaks can widen the soundstage and make it little more laid back, which has always been my preference.

 

Since HQplayer and ramroot aren't friendly with each other just yet, next I will try ramroot disabled and HQplayer enabled.  I'm guessing you've tried this and prefer ramroot with Roon alone?    

 

I am trying to follow the different topics about Audiolinux, HQPlayerEmbedded, ramroot, .... but you lost me here.

Would you please be so kind to ellaborate (or refer to specific topics) about HQplayer and ramroot not being friendly with each other just yet?

Thanks

Dirk

[k27R]

lpost explains in his previous posts.  Might just be a pink faun thing?

[lpost]

On 8/26/2019 at 4:16 PM, k27R said:

Since HQplayer and ramroot aren't friendly with each other just yet, next I will try ramroot disabled and HQplayer enabled.  I'm guessing you've tried this and prefer ramroot with Roon alone?    

 

That's a combination I've not tried.  I've been Roon straight for 8 days and don't miss HQPe but I'll give it a try the next time I have the patience to make a change.  Sometimes I believe the quote is spot on, 'comparison is the thief of joy' - Roosevelt

 

@ddetaey The licensing mechanism in HQPe isn't 100% compatible with ramroot on Audio-Linux and likely any other variant of Arch Linux.  The code detects a change significant enough to regenerate the fingerprint for the license code.  I've been through 5 license codes from Jussi and the last time i told him I wouldn't bother him again if/when it occurred.  For me, I don't upsample, only pass-through Roon to HQPe to DAC so I don't gain but a slight variation, sometimes it's better sometimes it's not - but then it could be how I'm feeling that day vs. another, mood, etc.

 

I'll try HQPe again in non-ramroot mode for fun and see.  

[gdpr]

27 minutes ago, lpost said:

 

That's a combination I've not tried.  I've been Roon straight for 8 days and don't miss HQPe but I'll give it a try the next time I have the patience to make a change.  Sometimes I believe the quote is spot on, 'comparison is the thief of joy' - Roosevelt

 

@ddetaey The licensing mechanism in HQPe isn't 100% compatible with ramroot on Audio-Linux and likely any other variant of Arch Linux.  The code detects a change significant enough to regenerate the fingerprint for the license code.  I've been through 5 license codes from Jussi and the last time i told him I wouldn't bother him again if/when it occurred.  For me, I don't upsample, only pass-through Roon to HQPe to DAC so I don't gain but a slight variation, sometimes it's better sometimes it's not - but then it could be how I'm feeling that day vs. another, mood, etc.

 

I'll try HQPe again in non-ramroot mode for fun and see.  

Thanks for your feedback. Much appreciated as I was going to test the latest pinkfaun audiolinux upgrade using ramroot.

will need to verify with Jord first

Dirk

[k27R]

On 9/2/2019 at 12:12 PM, lpost said:

 

That's a combination I've not tried.  I've been Roon straight for 8 days and don't miss HQPe but I'll give it a try the next time I have the patience to make a change.  Sometimes I believe the quote is spot on, 'comparison is the thief of joy' - Roosevelt

 

@ddetaey The licensing mechanism in HQPe isn't 100% compatible with ramroot on Audio-Linux and likely any other variant of Arch Linux.  The code detects a change significant enough to regenerate the fingerprint for the license code.  I've been through 5 license codes from Jussi and the last time i told him I wouldn't bother him again if/when it occurred.  For me, I don't upsample, only pass-through Roon to HQPe to DAC so I don't gain but a slight variation, sometimes it's better sometimes it's not - but then it could be how I'm feeling that day vs. another, mood, etc.

 

I'll try HQPe again in non-ramroot mode for fun and see.  

 

I’ve been comparing the two configurations over the past week, and I prefer Roon on its own with ramroot.  In my system it offers a more delicate (better micro dynamics?), airier, and more natural sound.  With HQplayer, I haven’t tried every filter yet, but with the ones I’ve tried,  everything sounds tighter and more focused, but less natural and a bit more aggressive.  

 

On to the next tweak for me!  

[flkin]

I'm having difficulty with the latest kernel. I'm preferring the older v4.7 to the current v5+.

 

I'm finding the sound a little too forward for my taste 

[lpost]

3 hours ago, flkin said:

I'm having difficulty with the latest kernel. I'm preferring the older v4.7 to the current v5+.

 

I'm finding the sound a little too forward for my taste 

 

I'm glad I stuck with 4.7.  Thanks for the comment.

[flkin]

I think it might also have to do with the new Realtime Manual Assignment function also. I'm finding it better without at this time. Which means that rtapp and rtirq isn't being adjusted manually. But setting extreme priority is still essential.

[matthias]

@Pink Faun

@flkin

Why is Pink Faun not on the exhibitor list of X-FI Show this year?

Thanks

 

Matt

[flkin]

Hi Matt, I wouldn't know for sure but I guess they have to select shows to attend due the effort involved?

[k27R]

Been playing around with core isolation.  Some thoughts of how these sound in my current setup:

 

1 core isolated: Very nice 3D effect and resolution, but lacks some musicality and emotion.

No core isolation: a smidge less resolution than the other two, a little digital sounding and less spatial, but more musical than 1 core isolated.   

Half (4  7) cores isolated: Most natural sounding of the three.  As much resolution and more musical than 1 core isolated, but not as 3D sounding. This configuration works the best with my setup which is:

 

Hardware:

2.16

OCXO's on mobo and processor

SPDIF bridge with the standard TCXO (haven't upgraded this yet!)

 JCAT Net card

 

Config:

Roon only (not using HQP)

Ramroot enabled

Half core isolation

 

Haven't dived into any of the other "more advanced" settings yet.