I confirm your observations with one or two exception:
If you look into MPD, it actually creates as a parent 4-5 child threads like io, player, usb-snd-output, sometimes flac, etc. If Ou give MPD like five isolated cores, it gives each of them its own core, more CPU cache etc. For tickless anyhow the precondition is one taküsk/threat per core...so ideally no discruption of a threat as there is only one active threat per core.
On my AMD 5700x running at 550mhz this made a nice refinement.
The USB output...well...its an interface and so we have output and input i guess. With the i2soverusb card and Andreas Fifo coming next, USB sounds equally good to I2S, even a bit clearer and crisper maybe.
A N5100 has the USB conrüteoller baked into the chip SOC...system on a chip...so many issue we had in the old days like signal needs to go through pci busses, usb controller etc...its all backed in.
Actually i am pretty surprised how well even the USB ports of the Asus crosshair vii board with the Amd 5700x sound. Running with Corsair PSUs, so nothing fancy on the PSU side yet. The crosshair though has finemet chokes and a very sophisticated PSU side itself on board, one of the reason its so expensive I guess.
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.
Well see what this does.
I will play around with RT-patch and different timer frequencies next...as well as Linux versions.
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...
If you look into MPD, it actually creates as a parent 4-5 child threads like io, player, usb-snd-output, sometimes flac, etc. If Ou give MPD like five isolated cores, it gives each of them its own core, more CPU cache etc. For tickless anyhow the precondition is one taküsk/threat per core...so ideally no discruption of a threat as there is only one active threat per core.
On my AMD 5700x running at 550mhz this made a nice refinement.
The USB output...well...its an interface and so we have output and input i guess. With the i2soverusb card and Andreas Fifo coming next, USB sounds equally good to I2S, even a bit clearer and crisper maybe.
A N5100 has the USB conrüteoller baked into the chip SOC...system on a chip...so many issue we had in the old days like signal needs to go through pci busses, usb controller etc...its all backed in.
Actually i am pretty surprised how well even the USB ports of the Asus crosshair vii board with the Amd 5700x sound. Running with Corsair PSUs, so nothing fancy on the PSU side yet. The crosshair though has finemet chokes and a very sophisticated PSU side itself on board, one of the reason its so expensive I guess.
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.
Well see what this does.
I will play around with RT-patch and different timer frequencies next...as well as Linux versions.
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...
There are at least tens of threads/processes running on every linux, even the most off-loaded one. The kernel itself has lots of tasks.
Why should one MPD thread per core be the precondition for the tickless scheduling of tasks in the kernel? Please explain your reasoning.
those run on cpu0, if you isolate cores nothing runs on them unless you pin specific tasks to them but from my understanding you can just easly pin the main mpd task to specific cores with systemd, if you pin this main task lets say to cpu1 - cpu5 linux will decide which child task runs on each (and they will switch around different cores unless you pin each child task to its own core)
is there a way to pin on demand created tasks to specific cores? i didnt found a way myself unless you pin them manually -after- they are created (maybe with a script that checks for created tasks and pins them?) if i start creating my new cm4 streamer i would like to give mpd one core and camilladsp another core, mpd is easy through systemd, camilladsp not so much since moode will start camilladsp itself on demand
maybe i was just a bit unlucky with usb, on my normal pc it sounded noticably worse than a raspberry pi with moode but i also have a very noisy 1070ti installed, once i heared that, my windows pc died for me for serious listening since i felt its not going to help to try to optimize my pc if the raspberry pi is out of the box noticably better and i think the minimalistic approach is the way to go (atleast for me)
another test i have planned with the new cm4 streamer since i still use my usb dac is to have it hook up to the raspberry pi otg (usb c) port and compare it against the usb A ports that go through the usb hub (the usb c port is directly connected to the SoC with dedicated usb 2.0 lines) my guess is that this will improve things but i could be wrong, you need to power the pi4 through the gpio pins if you wanna use the usb c port for data
oh no i didnt know powertop, seems like a good tool but im unsure if it runs for arm cpus, i will try
one tool i found quite helpful was "tuned" it sets different settings for you for minimal jitter, there is alot to tweak if you go into kernelsettings and such stuff but tuned already helps to set some/most important settings with ease
I am starting most of the time with Dietpi which is Debian 5.10 bullseye at the moment. Reason is that dietpi is very small and has some nice universal tools to setup it up quickly including cpu affinity of services or startup scripts for your favorite settings. You dont have to study Linux in order to get it to work.
AND: NO matter if you use now x86 PC or a small Raspberry or Odroid...your setup procedures are very similar AND you can easily upgrade/generate your own kernel...especially x86 and Raspberyy are very easy.
As Ghostknight already rightfully explained: No, when I am done with the system setup nothing runs on my isolated cores. Not even timer ticks. No IRQs. no threads. No Osnoise at all, measured with RTLA/Osnoise.
The Isolation of cores takes care of no tasks getting onto one core. the startup-kernel parameter irqaffinity=0 tells all hardware irqs to run on core 0. Kernel Cinfig parameter NOHZ_FULL=Y (not NOHZ_idle=Y) takes care of full dynamic tickless mode / no timer ticks.
So, from this baseline you start to give now IRQs for USB which are used for your DAC a new, clean core (a command in the dietpi-startup script). MPD you give with dietpi-services a realtime-priority and the cores you have available.
The condition of one task/ one thread per core is documented well in many manuals/threads about how tickless full as a timer subsystem works (NOHZ_FULL=Y) as the other preconditions to make a full tickless system work (as a starting point of your kernel boot parameter: "nohz=on isolcpus=nohz,domain,1-3 nohz_full=1-3 rcu_nocbs=1-3 no_balance_cores=1-3")
To describe it simple: The idea is that there is absolutely no need to interrupt a thread or a task by any timer tick as nothing else that this one task/thread is running on that particular core. This is the "ideal" for a realtime-system as aboslutely no delay or other duties of other task hold your thread/task back. As well no overhead / osnoise as presented in my first post.
This is clearly nothing I come up with, no need to discuss this...it is all documented well by the guys who invented this originally for multi-core-system like 32 cores and more to run real-time-systems with lowest interrupts and lowests noise...like in trading systems etc.
I read many of those articles and thought...lets try that for audio. And Ghostknight seemed to have found that equally satisfying.
@Ghostknight:
The child threads are not jumping in my setup. they stay isolated on those cores they have been started on.
Yes, you can use task affinity commands to precisely bind the children taks to individual cores but I did not have the need to do that. dietpi-services takes care for me of that. Easy setup.
The one thing which I did not yet debugged in detail was: I feel that the OSnoise is still higher than expceted, even when you give each children thread its own core...I am not sure why that really is the case and if this is something we can influence or if this comes simply by the nature of the beast (data processing).
It is interesting to see how OSNOise is dramatically raising when you:
- play Hires 192k instead of 44k1
- play with software nmixer not at 100%
- use any form of format conversion
- use flac instead of wave
Last edited:
Well..I run the crosshair/5700x setup headless...so no graphics card installed, all hardware chips not needed disabled in the bios etc...in energy saving mode (and the 5700x is already the b2 stepping, so very low energy 8 core)...maybe i was just a bit unlucky with usb, on my normal pc it sounded noticably worse than a raspberry pi with moode but i also have a very noisy 1070ti
one tool i found quite helpful was "tuned" it sets different settings for you for minimal jitter, there is alot to tweak if you go into kernelsettings and such stuff but tuned already helps to set some/most important settings with ease
I tried tuned as well but it had too many assumptions per profile for me embedded. I like to have control of my governance models, energy profiles etc myself...anything tuned does, you can do as well indivually yourself with not so much extra work.
And how does it all improve the jitter at the DAC clock? Please be specific, show the path, the details, how the OS timing translates to the DAC clock timing.
Maybe later...its all work in progress at the moment. And I have archlinux as well on my list to try...I am happy to share any customization detail on tweaks which you can try yourself, so its open source...no secrets...and happy if those doing those longer than me sharing their latest findings as well...
Yes, i am a member, but i was not yet able to listen to it as my plan was/is to customize myself as much as possible out of debian to learn something, find my own mix of stuff i prefer and than finally compare against those solutions out there...i got audio-linux as well here etc...but no time yet to compare...but its interesting to see the solution components of others like how well there isolation is setup or which kernel compilation parameter they prefer.
Puppy is as well on this list, but i found a script to be tried to load debian completely into ram (not only the logs), which seem to make a puppy like solution with any dietpi (no matter which hardware)...so much stuff to try...but lots of fun.
6.1 brings the new improved AMD Cpu driver for better power management. It already nice how much control the current amd driver gave (better than the intel driver which let my n5100 only move between 800 and 1100mhz)...but the new one shall by much better as some beta tester reported.
Puppy is as well on this list, but i found a script to be tried to load debian completely into ram (not only the logs), which seem to make a puppy like solution with any dietpi (no matter which hardware)...so much stuff to try...but lots of fun.
6.1 brings the new improved AMD Cpu driver for better power management. It already nice how much control the current amd driver gave (better than the intel driver which let my n5100 only move between 800 and 1100mhz)...but the new one shall by much better as some beta tester reported.
Don Quijote aiming at the windmills?
This reminds me of the scene where Indiana Jones is faced with the Ninja. After the Ninja displays his mighty skills, as a prelude to mortal combat, Indy just shoots him with a revolver.
At this point, are you after good sound or just playing around with the thing? A good USB DAC will bypass everything you're playing with... I suppose one of these days I ought to plug in one of my DACs into the Pi-4 under my monitor and see, currently I used Android (USB OTG) or plain Windoze.
You could try to clean up the sound of a DAC on a Pi's hat all you want, but ultimately, for under 200 bucks you can do much better, off the shelf, with a USB DAC.
I had a friend here today...did not tell him what is playing, just switched two streamers...into same dac/fifo...it was the AMD 5700x machine vs. Raspb. 4 with q7 and purepi.
He is not an IT guy at all, but was shocked how significant the difference is actually. There was not a clear winner, they play just quiet different, its in the magnitude of rolling a Telefunken tube vs. a valvo tube...so very audible and a matter of taste rather than one was completely right or wrong...both with the exactly same configured and tuned Linux Systems Kernel versions etc.
So, I will dig deeper into this...I live next the netherlands border...we have beautiful windmills here.
He is not an IT guy at all, but was shocked how significant the difference is actually. There was not a clear winner, they play just quiet different, its in the magnitude of rolling a Telefunken tube vs. a valvo tube...so very audible and a matter of taste rather than one was completely right or wrong...both with the exactly same configured and tuned Linux Systems Kernel versions etc.
So, I will dig deeper into this...I live next the netherlands border...we have beautiful windmills here.
You don't need a 100K DAC. Currently in use I got an RME AD/DAC, Burson (the mid priced one) and Nuforce. I also got an M-Audio firewire AC/DAC that will soon be replaced by the RME.
I've done multimedia firmware development as well, getting paid for it. Android is OK, but it's in the kernel, and the DAC will be its own, heavily cached and with different clocks. Even then, using an external USB OTG DAC will beat it in terms of noise. No real changes in "timing" if the device drivers are written correctly - meaning no one in his right mind would drive a polling driver or something done in Python.
The Pi hat is a noisy environment, sorry. OK for driving stuff like motors, switches and so on -I got the kit for making things with it and they are easy to program with simple Python scripts. The Pi-4 USB-2 is also good for making a personal NAS.
All you guys are doing is playing with configuration files for applications, not really addressing the issue. Sure applications will operate differently, but the real solution is always in the driver and hardware. The old "fix it in the software" sometimes is a truism. For example, I can write a version of a device driver that will cache a significant amount of data in order to dejitter the input... it's really a no brainer... or better yet, I can make it so it will allow the hardware to cache the data in its own DDR and then DMA across.. using a scatter-gather algorithm.
What you guys are doing is a fun thing to do with the user community, but when it comes to this kind of thing, short of going bare metal with a Pi-2, developing your own hardware and software, you ain't gonna do as good as just buying a nice external USB DAC. OK, a Firewire DAC will work great too. You guys are limited as to what the OS and the hardware can do.
My own testing.... let me tell you... you know the company that makes the chips for the Pi? I used to work there, making SoC chips, testing them in bare metal and writing device drivers. I was very well paid to be there and I've spent MANY hours testing.
BTW, let me give an analog (pun!)... there are people in these forums that design and build awesome analog amplifiers and pretty much they do it from scratch. In the digital world this would be like designing your own hardware and software. That is what would be required to do what you have set to do, not just messing around with the configuration of some applications. That would be like limiting your amplifier design to selecting the capacitors in the power supply. And interesting endeavor for sure, but sort of Quixotic. get it?
But, by all means, go have fun.
Last edited:
My impression ist: As Ian suggested, it needs more time to burn in before evaluating. I need as well to understand how the battery supply part works meaning how the clocks can be kept on continously vs. the suggested way of connecting it.
Initially I would say it plays softer, give a more warm, rounded analog like presentation. Not as clear as the AMD/Asus Crosshair ("Pink Faun replica"), The Crosshair is snappier, crisper, clearer....but I have big hopes that the Q7/Purepi develops further...lets see...I have time...
Initially I would say it plays softer, give a more warm, rounded analog like presentation. Not as clear as the AMD/Asus Crosshair ("Pink Faun replica"), The Crosshair is snappier, crisper, clearer....but I have big hopes that the Q7/Purepi develops further...lets see...I have time...