Path to noiseless Linux streamer...

Hello Blitz. Thank you for your insights regarding optimizing the linux Kernel. I am quite new regarding building my own kernels. I would have written to you in a PM, but as my user is under moderation, I can't. I hope that I am so fortunate that you have a RPI archlinux kernel with "tickless" enabled? I am using archphile with some of my own modifications also, and would really like to try the Tickless kernel.
I home you would take your time and answer me 🙂
Kind regards
Rune
 
Fedora on RPi requires a lot of tinkering. It runs Gnome by default.
That's helluva load on that tiny CPU and RAM.
A lot of stuff that is known from RPi OS is missing.
Doing any kind of changes and tweaks gets a lot more complex on Fedora.
All this U-Boot booting stuff is awful slow. And it is complex to improve.

Documentation and community support is almost not existing.
Without some extended Linux experience all this is no fun.
Ubuntu etc. is probably not much different though.

Yep Fedora boots on a PI. And yep, more and more RPi stuff
gets integrated into the Mainline kernel.
But that's about it I'd say. Don't waste your time on it - at least for now.
if fedora isnt ready yet, how about arch? (specially thinking about endeavourOS arm)

i kinda wanna give either one a go, just to see if i get the same performance i get on fedora on a untuned desktop computer
still really dissapointed that fedora beats the tweaked moode setup i had before... and i can just explain it that way: software can have potentially more of a effect than hardware...
it could be well possible that fedora`s newer kernels are the reason for that, tho im not sure..
 
im not entirely sure what os`s/hardware you guys are running, but wouldnt it be neat to put our juices together to make a distro (or atleast a setup script for a ready made distro) to make a music distro like moode/volumio "but better" ?
you dont really need a webinterface, tho a webinterface would be nice for options/settings (something like gentooplayer is doing) for the rest a mpd interface should be enough and i dont think moode/volume is actually much different from that

right now im thinking of either arch or fedora and putting just a few programs on it like MPD/Mopidy

i will probably try fedora the following days first, for me its the best distro because its nearly as uptodate as arch but better ootb security/more stable/other stuff
i also think the raspberry pi is enough supported at this point since its also included in the "base" of fedora since fedora 37, tho i will see
i have to see how huge the minimal fedora distro is but i cant imagine that its much heavier than other options

but yea, i will first replicate my desktop setup with pipewire/easyeffects and see if i get the same (or better/worse) performance
 
Are you still at it?

While I was gone...

(1) Updated the OP amps in the Burson Swing,
(2) Updated the Linn LP12 with a Radikal
(3) Got an F4
(4) Got a SissySIT
(5) Got a pair of Audio Note AN-K LX (used).. I needed the 90db efficiency for the the F4 and SissySIT.
(6) Got a Dell MFF, Win11, with an I7-12th gen to create a DAW with the RME (USB interface). Running with 2 TB of SSD.

Trust me, each one of those steps have significantly more impact on the sound of my main 2ch rig than tweaking the interrupts in a Raspbian application.
 
but yea, i will first replicate my desktop setup with pipewire/easyeffects and see if i get the same (or better/worse) performance
ok i just tried fedora server 38 + lxqt + pipewire + easyeffects, not exactly my desktop setup but it should be comparable

first... there is definitely a difference but im "kinda" unsure what is better... on the one side with the rapsberry pi it sounds "clearer" but bass is nearly completely gone, which is not the case on my desktop setup and i was loading the exact easyeffects profiles from my desktop
can anyone explain why this might be? sounds "noisier" bass "thicker/louder" ?

well, still very unsure if i should try the cm4 route again to be honest

the performance was really bad btw, desktop was laggy without anything running, even with just lxqt, so definitely not a longterm option
 
I am working on Debian using LMS for my music library, but don't know much about how to set up all that stuff talked about here in this thread. I would like to try it out, but I would need a GUI for all those settings in order to be able to switch between sets of settings and compare the differences in SQ, or at least a command line interface. Is there any chance of a step by step guide? Best would be a plugin for LMS with all the settings involved to make the PC noiseless!
 
those are great upgrades. Once you have all of that optimized, or your bank runs dry, you can still have fun tweaking Linux. Or just listen to the Linn.

The Linn is simply awesome.... this upgrade has me thinking of getting a Lingo 4..... the Keel is still a LOT of money but I guess I'd need that before I splurge to an Ekos. There are no used Lingo 4 and Keels. But I have seen some used Ekos.

Yes, I did splurge but most of that was either used or DIY... so the cost was quite reasonable. The Karousel was new but it was done by an indepent installer and he's taking care of me. The hard part was hiding it all from the wife.... Anything under 600 bucks and she sort of shrugs it off, so some of those expenses had to be done in tranches.

The speakers, at almost $2K, for that I had to get prior approval. But the burled finish looks very nice. ;-)
 
  • Like
Reactions: wlowes
@Blitz still around ? how was your "final" expierence with ian canada hats/modules?

i played around a bit and have now a dietpi setup with camilladsp and the rpi4 running as a usb device (so i can hook it up over usb to my pc)
sound quality is very good for a normal pc output, its a bit better then direct pc output from my last setup (fedora+pipewire) i would say, specially if you tweak dietpi with isolated cores and fifo priority for camilladsp

i wanna get a ddc in some form and thats why i ask for the ian canada hats, my current setup + a digital output hat could make for a good cheap ddc, but im wondering how it compares to ready made usb bridges/ddc`s directly connected to the pc

im kinda looking for a galvanic isolator + transportpi digi setup + improved clocks
im also hoping that improved clocks over spdif could improve on the integrated clocks in my aune x8 dac
 
Hello, mi first post on diyAudio ;-)

I've just bought a RPI4 and about to order Ian Canada PurePi & TransportPi Digi to build an audiophile SPDIF coax streamer into my Aune X8 XVIII dac aswell. My intention is to stream music and movies locally from usb or wirelessly by DLNA from the router's USB port. So far I'm using the tv as a media player from usb (and also by DLNA) into the Aune dac by either usb or optical.

The problem with my tv (it's a Samsung Oled from last year) is that it has lots of jitter. So much that my Aune gets microdropouts by toslink, and also by a HDMI-ARC to coax converter. With a previous Onkyo A-9010 stereo amp toslink input sounds fine, but Aune X8 and a SMSL SU-8 that I know works well from optical get dropouts from this tv, using two different toslink cables. So my Aune is not the only dac to be sensitive to jitter. Actually the Tv sounds better through the Aune by Toslink with dropouts than by usb that doesn't. Usb sounds drier, and I'm using a good Supra usb cable. The advantage of usb is that the tv controls volume through the remote and is more convenient to me, as I'm using the Aune dac as a preamp to a Audiophonics Hypex NC122MP power amp to Elac DBR62 speakers. The Samsung TV also resamples 44.1 to 48KHz, its Tizen OS running PulseAudio to my knowledge.

So I'm hoping I'll get better sound with a PI streamer, also for tv broadcast, since I'll use a tv hat.

Onto linux and sound quality: I wonder about the convenience of a real-time kernel (or tickless as I've read from @Blitz), since real-time kernels are in principle geared to recording and latencies. Everything goes through a buffer eventually so is it actually convenient?

I plan on running a light distro like a headless DietPi, RoopieXL or Raspberry PiOS Lite with UPnpcli+MPD or a ReadyMedia Server for efficient use and on the other hand a LibreElec Kodi multimedia server for video and tv. I'm not very familiar with Debian or Ubuntu, since I manage Fedora Linux for some time now as a side O.S. from Windows, but wonder about using fixed clock CPU governors to avoid throttling and energy-saving states to get a system as stable as possible for playback.

I haven't read much yet from the thread, but what is your experience with linux as an audiophile streamer?

P.S. I run an affordable Asus Xonar DX PCI sound card on a Windows PC in a well-treated small room to a venerable cheap Logitech X-540 5.1 system that sounds amazing and love to bits. I don't hear any jitter and in some ways it sounds better than my main Aune X8+Hypex power amp + Elacs from my TV in a non-treated 16m2 room. Such hard is reality 🙂
 
Last edited:
Make sure you got the power supplies right. Keep in mind. It won't help much to hook the PI
up to a high quality supply. The 5V rails will still look awful. Either your attach some
buffer caps and filters to the 5V GPIO or you buy some of these buffer/filter HATS.
Why do you say so? I'm considering an ifi IPower X for a RPI4 and Ian's TransportPI Digi + PurePI setup so I can save The ShieldPro or FilterPro hats.
the PurePi has ultracapacitors for RPI power, so I guess even a stock official PI4 supply could do with its 120mV ripple. I've emailed Ian but I'm not sure he understands me.

I am running @2GHz+. That sounds best to me. If you underclock you might even catch network errors - been there done that - seen that.
how do you set the clock speed config, like this?:
  • echo 2048 > /sys/class/rtc/rtc0/max_user_freq
  • echo 2048 > /proc/sys/dev/hpet/max-user-freq
May this be combined with governors and dvfs?
https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#using-dvfs
yup it looks very good tho i wished it had a RT kernel option (to try it out)
[..]
for example MPD and upmpdcli for DLNA

About RT kernels: I'm not expert, but following RT-Kernels once they said normal kernels work pretty well if you set up threaded irqs (rtirq) by installing a distro package,such as rtirq-init. I wonder though, (haven't tried yet) about the convenience of using a RT-kernel for music playback using a separate SPDIF transport, such as PiDigi: it must have a buffer somewhere (PI2AES has one) so latency shouldn't matter. Maybe using RPI USB output it is more relevant. I'd like to point this out to know your opinion, depending on your interface it might or not be relevant, although it may be a good idea to set up for the sake of performance. MPD can use RT-scheduling from the kernel (https://mpd.readthedocs.io/en/stable/user.html#real-time-scheduling), but its docs states:

This works only if the Linux kernel was compiled with CONFIG_RT_GROUP_SCHED disabled.

Note:There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load.

I think a Spdif transport is better than usb because the formers has its own (better) clocks and doesn't have the power bus to need galvanic isolation in the first place. Even using asynchronous USB it depends on the implementation, the source USB clocks accuracy, you may need good cables, isolators that do their own reclocking of data, silencers.. Wikipedia says asynchronous might not be the best method per se, it depends on the implementation. XMOS usb controllers adds complexity to usb, and in my opinion, unless use a separate audiophile USB card with its own clocks and clean supply, SPDIF is the way to go.

I also intend to use MPD and upnpdcli for DLNA. It seems a very nice piece of software, well documented and efficient.

So, my impression is that smaller units like the Raspberry are more dependant on a very lownoise linear PSU. I got now Ians Q7 and PurePi (battery/ultracap) in the house and will compare. But initially it sounded a bit disappointing until I changed even the linear reg infront of the pure pi...as the ultracap for the 5V is only in parallel, not working as a battery, but a filter.

Any I confirm your observation: Lower CPU frequency gives better sound, even when osnoise goes up as cpu capacity is limited...did you use powertop ? Pretty fascinating...if the numbers are right, a 5700x consumes that in 550/near idle like 1-2W..ethernet 0.5W...
So you think ultracaps of PurePi are not enough to assure good RPI processing to feed data to Q7? Q7 is fed by PurePi's Life4PO batteries, right? So in principle we don't depend much on RPI power as it only does the data processing, not the output interface..

Regarding EMI and RPI with wifi enabled (wifi is a must for DLNA, and I can't run ethernet cables): can the RPI activity and antenna leak EMI into transport hats, so you may need a Shield hat? I saw this:

Sorry for so much cross-reference, I still have to learn to benefit from this thread. Thanks for the help.
 
Last edited:
After now 20 years of building different DACs and playing with different streamer, I finally ended up with Andrea Mori's Clocks/ FIfo and DAC...which brought a level of realimns and transparency to my system which called for reviewing the source. Until today the reference has been an Alix 1D, Sotm Usb-Card, linear PSU and MPDpup, a very lightweight Puppy derivate where many good people fine-tuned this to the best...second best distro I heard until today has been Archphile.

Unfortunately, my hardware is old and none of these distros are maintained any longer, so I started a new approach:

  • "Universal recipe": ARM, x86, Raspberry, NeoPi: Should serve any platform and any Linux "dialect"
  • Target to play PCM-files, so no real-time application like for a musician, this is about
  • Lowest Noise primarily and lowest jitter secondaraly, Lowest latency in itself is not a reqirement at all.

The Linux Kernel brought with 5.15 a new tracer (RTLA)to trace OS-Noise and Latency in a white box approach, so you can easily make your Kernel configurations or system modifications visible....this is a HUGE help to see what does what...and we can now truely measure OS-Noise, so it is not a philosophical believe question.

Have a look just as an example on the osnoise effects of binding tasks to CPU-core vs. isolating the core vs. true tickless operation:

View attachment 1099657From H. Akkan, M. Lang, L.M. Liebrock, Stepping towards noiseless Linux environment)

The RTLA-Osnoise tool is very powerful, it shows you the noise effect of anything you try per CPU-core be it threadning IRQs, isolating core, assigning and priotizing task or running a tickless Kernel. I invite anyone to try it.

Sofar there is a very strong correlation in my experiments between lowering OS-Noise and better, more direct, more transparent SQ with richer tone at the same time, some people would call it "analog" sound...you can measure as well the effects on OS-Noise of

  • isolating cores for your player
  • Using flac vs. wave
  • hardware vs software volume mixer
  • resolution of your files
  • network vs. direct stored files

and many more.

Additionally, I found that in Linux Core 5.15 (and versions after), some very interesting topics have been added for the audiophile:
  • Rewritten USB-driver for lower latency
  • Dynamic switchable PremptionModel (none/voluntary/full) at runtime
  • ALSA using HR_TImer as default

For my experiments, I started with Debian Bullseye as I can easily generate my own kernels for nearly any platform using DIetpi or Armbian as a starting point. It is really very easy and I am happy to share the how to if there is interest.

There are two different categories of settings:

A. Those which are difficult to negelect or argue about their positive efffects, any Linux streamer would benefit from them
B. Those where it is a matter of personal taste, your way of listening

Lets start with A.
These are setting which not only from a theoretical and OS-Noise-Measurement PoV make a difference, but which I found easily audible (in my system suing a N5100 fanless MiniPC):
  • usage of a linear PSU is a a prerequisite for anything.
  • usage of log2Ram or equivalent recommended
  • use the USB-Port which comes from your SOC-Cpu and goes not through an extra third-part Controller (e.g. many MiniPC which a Z8350 have the one USB3.0 port from the Z8350 and some more USB2.0 from an external chip)
  • Isolation of CPUs giving Ethernet to one core, USB to another and MPD on the third, any other IRQ or App runs on CPU 0.
  • DIsable frequency scaling of the CPU, use userspace as governor with fixed frequency
  • 1000 Hz timer frequency (which is normally only use with the Realtime PAtch, but here we use it without the overhead of the RT-Patch)
  • nohz_full (full tickless mode)
  • ALSA using HR_TImer as default
  • echo 2048 > /sys/class/rtc/rtc0/max_user_freq
  • echo 2048 > /proc/sys/dev/hpet/max-user-freq
  • MPD running as a service with FIFO-RT scheduling Prio higher than 51 and higher IO-Prio (brings OSnoise down by 30%)
  • If you can, avoid using a network. HIgh OS-Noise and directly streaming from an SSD sounds much more direct.

And here is my current list of B. topics which are audible as well, but a matter of your personal taste:
  • Preemption Model: I prefer None to Premption voluntary or Full. None Sounds more direct more resolved, but a bit dirty. Full sound a bit damped and controlled, not as spontanious, in transients but very clean and warm.
  • TSC vs HPET clocksource: Difficult. HPET is more musical, more rounded but less resolved sounding. I prefer TSC and set the KErnel option tsc=perfect to avoid any overhead.
  • These two Prememtion Model and clocksource are interesting to combine in different ways as the crystalline sound of TSC goes nicely as well with a stronger preemption model...but I like it as resolved as possible,

Thats is where my efforts stand at the moment...next on the list:
  • Compare x86 with many ARM-devices with the same Kernel-Settings
  • Start to look into I2S directly like NanopiNEo3 seems to be supported directly by the Kernel, but each I2S implementation is board specific...there might be reasons why one boards sound better over USB than I2S and on another its the opposite.
  • Compare Audio-Linux and Archphile at some point of time to this generic Debian-based solution...to see where we stand.

I am happy to share any level of detail how I did what if there is interest. I am very eager to learn from others and their findings I could try myself in my setup additionally. I am not interested at all in generic discussion about "All Sources sound the same" or "A fifo will make any source sound the same" etcetc... that is a waste of time and energy.

So, the purpose of this thread is really to get to a modern alternative to archphile or MPDpup for any platform and for any Linux-version usable. And sharing knowledge, saving you time.
The above is deserving of another viewing.

Blitz has graciously showed me how this is done - and it is not a quick and easy process so it took considerable amounts of his time.

All I can say is there is not a single word of hyperbole in this opening statement.

In fact, I had not read it in a month or so and now that I am experiencing this system all I could do was smile to myself about how his description is the same as my perception.

Using his notes and his guidance I am compiling his instructions along with some pointers for folks like me, who do not have the understanding of what is being done here, to make it easier to do. There is nothing one can do to make it quick though it will not take hours to do this - I think Blitz fed it to me in courses so one could hear the evolution of the sound.

The only thing I would add to his statement is the sound has a wholeness to is - like a class A amplifier - it is plain that the sound is not being chopped up into pieces and then put back together again like Humpty Dumpty, Excuse my fanciful conception of what is going on but there is some truth to it. My conception that is; there is great truth in how this system reproduces music.

One of my first comments to Blitz, after hearing the finished product, is how completely different the presentation is from anything I have ever used whether digital or analog. It reminded my of a recent article by Herb Reichert who was talking about some piece of gear whose presentation was so different he wondered if he was listening to a different version of a familiar recording. I dismissed that comment when I read it as engaging audiophile hyperbole but now that I have experienced something similar I guess I should have known better than to doubt Mr. Reichert's reliable reporting.

Blitz recommends a fancier MB than I have ever used. It is quite large. It uses an AMD CPU, something else I have never used. He says that one can use lesser components if one must compromise. Obviously he settled on X86 as the best way to go, though not the only.

The board he chose uses amorphous core chokes for the CPU power supply filtering which is quite exotic and I could not resist.

Using this board with WTF, my previous beloved player, I had never heard WTF sound so good so there is something to what this MB brings to the project.

This is a project for those seeking perfection (all the while knowing they will never achieve it) and not some cheap DIY solution "that works". There are plenty of decent players that work and those who do not need something better have no need in being involved in this.

Blitz brings real knowledge and understanding to the project. He is not like me, someone who knows enough about the basics of computer audio to be dangerous. He KNOWS how computers work. In addition, he has assembled, and I mean that literally since he is a DIY guy who has built his amplifiers with the most premium of parts, a high resolution system . This player has been refined on a system of extreme resolution based upon measurements that he has correlated with what he is hearing. The way it should be done.

Luckily for us he is willing to share this formula.

In a week or so we will post the instructions and welcome those with ears to ear to give it a try.

The inevitable ones who never try anything but know all there is to know are welcome to make the expected comments but please understand they will be ignored. Without hearing something for oneself it is impossible to judge and comments are meaningless. As someone over at AUDIO ASYLUM used to post a line about "writing about music is like dancing about architecture" - I would guess this would be especially poignant when writing about music you have never heard ...
 
Rick, it was my pleasure...

I have become quiet for some time in diyaudio as I was simply tired to have meaning less discussions of therotical nature with people trying to educate me what am I allowed to do or to hear. My wife got cancer and I have more important things to do than trying to convince anyone. I am not a missionary.

I am happy to help to make stuff work for those who want to try.

But now its Rick to compile the manual and maybe folks add their findings. I am not claiming at all that not someelse have found similar things before...here is no Nobel prize to win or patent to claim.

I implemented this on many platforms Rpi, Odroid, z83, N5100, on most of the small platforms dietpi has on their webpage...as I want to find the winning formular for me personally. The system sounds on all of them very, very good.

But if you want the extra level of resolution, air, holography, its for me x86. You could start with a small 45 $ atomicpi board, cheaper than a Rp with a nice linear supply. And yes, I got Rp3, Rp4, Allo Usbbridge sign...i got Ian'battery supply, Reclockers even in latest versions, Supercappsu etcetc...X86 rules...for me. your mileage and taste may vary...there is no point in discussing this.

The idea of the project is to give you for a budget the big PinkFaun 2.16 sound without havin to pay 15000-25000 for your machine...use the money saved to spend some great vacations with your beloved ones as I do now.

So, making such a no compromise solution available to anyone...open source, completely transparent what has been done and why...it will be all in the manual as Rick committed this as his contribution to the community (based on my notes and advises we exchanged ober many, many emails privately)
 
This is one of the most interesting threads for me. I had already noticed about Blitz "silence" and feel so sorry about what I have just read. Blitz, my best wishes for your wife. Really hope a fast recovering and you all find the strength to face this situation.
 
to let you guys know, im planning to build a easy to setup dietpi os with many tweaks from here, mainly for the RPI4, it will not be convenient wise on par with moode/volumio but if you tweak stuff yourself anyway you probably wont have a problem with it

are some maybe interested to help building this with me?

https://www.diyaudio.com/community/...-os-for-raspberry-pi-4-audio-streamer.400185/

use case will be mainly as endpoint (hqplayer/roon... maybe dlna/airplay later on) and to use the rpi as "usb gadget" which lets you connect it to your pc for audio/ethernet, my goal here is to make the pc where music comes from as transparent as possible without needing to build a 10,000€ music server

the data itself is fine, i dont think the tweaks we do here have any effect on the data, but on noise, with this setup i currently use you can basicly use any audio output from your PC like you would if you connect your dac directly to your PC over usb
 
you can use Rick's manual 1:1...i did this as well for Rpi 3+4...the only difference is the bootloader / command-line. And the very easy to use Raspberry Kernel Update procedure...

We can let the manual grow with subchapters outside of x86...i think i still have my notes flying around on how to do stuff on Rp or ordroid etc.

The tweaks are always the same, but the platforms have different ways how to get there (like a tickless 100hz Kernel with its mods...menuconfig settings are always the same, but until you got to menuconfig the steps are different).
 
you can use Rick's manual 1:1
this is still in the works right?


i found this one https://forums.raspberrypi.com/viewtopic.php?t=343387
i still need to try it but it looks promising and i think it doesnt get easier then this for custom kernel options (atleast for the rpi4)

still really curious what tickless mode can do, tho you dont have much cores on the rpi4 to really utilize it, but it might help anyway
 
For those that are anxious I will post as it is in a few minutes - want to give it one more look.

This will not be after Blitz has seen it and I hope that is OK with him.

I was thinking it should have its own thread but then it would probably be better to keep all of this together in one place.

I have added text trying to make it easier for people like me to do this - but for those further up the line of continuum it is probably all you need to know.

I do see it as an evolving work, too.

I have been wondering about the folks who are returning to CD players instead of computer based players and wondered if the interrupts of computer players are what people are enjoying NOT hearing when they go back to a CD player?
 
For those that are anxious I will post where it is right now.

I am trying to make it easier for people like me to do this - but those further up the line of continuum it is probably all you need to know.

I do see it as an evolving work, too.

My instructions are based on my install - X86 with music storage attached.

I am using the Blitz recommended ASUS Crosshair VII Hero MB - mine does not have WIFI, I use a LAN to WIFI adapter.

The CPU is the AMD Ryzen 5700X.

I will eventually include the initial steps of setting up DIETPI . I do not have those pages with me so I will assume those who are anxious know how to do this. It is quite simple.

Only things to remember is to install ONLY mpd and to mount your music storage in Dietpi-Drive_manager AND within Dietpi-config - AUDIO OPTIONS - Soundcard - choose your sound card.

The complete version will go into all of this.

I have named this BLITZklang with affection. I hope Blitz will approve and, if not, I will take the name away.

Already seeing spelling errors - a better version will be posted Monday at the latest.
 

Attachments