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:
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:
From 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
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:
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):
And here is my current list of B. topics which are audible as well, but a matter of your personal taste:
Thats is where my efforts stand at the moment...next on the list:
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.
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:
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.
Last edited:
FWIW, I have been all software based streaming/DSP for years now. I started out with the Pi platform. It's OK but not really great with lots of noise both electrical and emitted. These days it's not so "cheap" anymore, either. Instead I use fanless Intel Celeron class mini-PCs (e.g. N4100, J4125, N5105) and a USB-based pro-audio recording interface for ADC and DAC functions. These are very reliable under Linux and I can use the most recent version of the kernel and apps. There is absoutely no need to use fancy kernel scheduling or tweaked settings at all. Audio processing is just not all that demanding of even the Celeron class CPU, even at high sample rates. Even good old USB 2.0 can handle scores of channels without breaking a sweat. A generic install of Ubuntu gets me most everything I need, minus a couple of key apps. As you mentioned, some recent improvements to USB in the Linux kernel have been helpful. As far as clocking goes, nothing matters until you get to the DAC. The DAC the only clock that is doing any sort of playback timing. Everything else is buffered within the computer and its audio subsystems and the OS clock doesn't really do much of anything. By using a USB audio interface with its own power supply, there is no need to investigate the computer PS. There are a number of very good USB DACs these days, and it is not too hard to find them vetted online (e.g. for example audiosciencereview.com). With their own PS and USB isolation, they are quite noiseless.
I was once like you, thinking that lots of tweaks would hype up performance, make things sound "better", etc. Maybe 10 years ago that was the case. None of that is really necessary anymore.
I was once like you, thinking that lots of tweaks would hype up performance, make things sound "better", etc. Maybe 10 years ago that was the case. None of that is really necessary anymore.
Last edited:
@CharlieLaub , is your HW and SW setup described somewhere? I have recently bought a NUC inspired by one of your posts here. I have the Behringer UMC1820, that works in Linux and I made it also work with CamillaDSP running as a service after boot before login on an old HP thin client. I also had Mopidy installed and working there, in a Debian text only distro.
Sure, let's all trust some random guy's "ears". Give me a break. You don't want a "generic" discussion. What is more generic than "I heard the difference between...". Your brain can fool you a thousand ways. Show me some measurement(s) and you will have my attention.
In any case, what sort of specificity are you looking for? I am happy to tell you about my system/setup.
Charlie, you dont have to spend your time here. I dont understand guys like you, I dont have to prove you anything at all. I wont post doozens of tracing results of the Linux Kernel I did either.
You are simply in the wrong thread. This thread is about sharing my observations on variables we have and what they do on Osnoise and sound. I have no intention to claim that I found a holy grail here or anything. It is just to exchanged with PEOPLE WHO ARE INTERESTED IN THIS.
You are NOT interested. Which is totally fine.
Your hypothis is "it sounds out of the box just fine etc." ...is the claim of another random guy about sound...btw
Lets not waste your and my time and energy, please. As written above.
ps: These parameters are not my invention for better sound at all. It is the work of amyn other people from many, mayn websites...I just tried a lot and summarizes what worked for me in my system best..and started to measure those effects with RTLA.
...you will have a hard time to buy a better DAC than Andrea Moris. But I understand that with a normal system maybe you wont hear a big difference.
And I agree that Debian out of the box sounds surpringly really great already.
You are simply in the wrong thread. This thread is about sharing my observations on variables we have and what they do on Osnoise and sound. I have no intention to claim that I found a holy grail here or anything. It is just to exchanged with PEOPLE WHO ARE INTERESTED IN THIS.
You are NOT interested. Which is totally fine.
Your hypothis is "it sounds out of the box just fine etc." ...is the claim of another random guy about sound...btw
Lets not waste your and my time and energy, please. As written above.
ps: These parameters are not my invention for better sound at all. It is the work of amyn other people from many, mayn websites...I just tried a lot and summarizes what worked for me in my system best..and started to measure those effects with RTLA.
...you will have a hard time to buy a better DAC than Andrea Moris. But I understand that with a normal system maybe you wont hear a big difference.
And I agree that Debian out of the box sounds surpringly really great already.
Last edited:
HW is fluid, since many parts are interchangeable. This includes both the computer and audio interface (typically a multichannel USB one). For the latter I have used the Behringer UMC1820 you mentioned and still like it, but the audio quality is surpassed by a couple of other units. I am running one system with it still. On another system I have two MOTU M4 interfaces running on the same computer, and synchronized. I recently bought a MOTU Ultralite mk5 but I have yet to use it despite the very high level of performance. There seems to be a couple of other new USB interfaces that look to have good potential as well: the Audient EVO 16, and the Topping DM7 (with DAC capabilities only).
A couple of years back I was using ecasound for DSP processing. Currently I use some software I wrote that invokes Gstreamer to run all my audio processes. This includes local and synchronized streaming over my LAN to systems in my home. The software is basically just doing a lot of organization and interfacing of the info contained in a set of configuration files out of convenience. It makes it possible to have a facile notation for the system crossover filters, etc. that is then turned into Gstreamer pipelines. The app also launches and detaches from the Gstreamer pipeline that does the actual audio processing. When you want to shut down it comes back and kills the process via its PID. For volume control I use amixer or pulseaudio at the source. All the actual DSP processing is done on the client, which can be on the same computer as the source, or a remote computer on my LAN located at/in the speaker itself.
It's possible, but rather messy, to write Gstreamer pipelines directly. Gstreamer is a very capable platform for audio work. I have to resort to using LADSPA plugins to do the actual DSP processing under Gstreamer but since I had already developed these (my ACDf LADSPA plugins) for ecasound, this was no problem. I call Gstreamer using the command line version of the platform. More hardcore developers would write an application in Rust or C/C++ but that would be more involved and time demanding than I wanted. Gstreamer is free software. Free is good. But my app is not well documented. I had toyed with releasing it, but it seemed that there were not too many people who were interested. These days, CamillaDSP is probably the way to go, except it does not do the multi-endpoint synchronization that Gstreamer can do, so I have not been too motivated to make the switch. CDSP is very good, however, from what I can tell.
If you have more specific questions, just drop me a PM and we can chat about it.
I use Daphile. It's a linux based audio playback system, as you probably know. How do I begin to incorporate what your discussing with the OS internal bits? The best I can achieve re this thread's ideas is a physically separate, linear +5V powersupply for the USB to I2S converter, instead of just using the USB +5V...
Or is it a matter of scrapping Daphile and building my own "Daphile" equivalent from the ground up?
Or is it a matter of scrapping Daphile and building my own "Daphile" equivalent from the ground up?
I assume you know that audio is processed on the computer in chunks of hundreds to thousands of samples. The CPU processes these audio chunks much, much faster than samples are spooled out via the DAC. In between this "work" the CPU is off doing something else, and the audio data is just waiting for the next step. So your concerns about and solutions to "OS noise" have little to do with sound quality, and you do not provide any explanation of this relationship. The DAC is doing the SQ related work, not the computer or OS. So it would seem to me that you have spent 20 years working on a topic that has become a non-issue with current hardware and Linux kernels.
You made several nebulous claims about sound quality without any real data to show improvements. Such as (these are from your opening post):
I believe that these claims are only reports of your perception of sound quality, by your own ears, whatever it may be. I can only say that these reek of confirmation bias. Honestly, many of your tweaks are things I have tried before, years ago when I thought I had to optimize the kernel or whatever. They make no difference except perhaps on very old and outdated hardware and OSes, which you admitted you were using up until now.
Since you just make a bunch of outlandish claims with no real evidence to back them up, how can the reader not be extremely skeptical? Extraordinary claims require extraordinary evidence. You have provided none, just some anecdotal personal feelings. This is how audiofoolery is born (intentional or not) and promulgated. Please don't do that here. Perhaps you could make some high resolution measurements of your DAC output to show us how these claims are justified, showing the data before and after applying your tweaks?
Finally, you said:
You made several nebulous claims about sound quality without any real data to show improvements. Such as (these are from your opening post):
I believe that these claims are only reports of your perception of sound quality, by your own ears, whatever it may be. I can only say that these reek of confirmation bias. Honestly, many of your tweaks are things I have tried before, years ago when I thought I had to optimize the kernel or whatever. They make no difference except perhaps on very old and outdated hardware and OSes, which you admitted you were using up until now.
Since you just make a bunch of outlandish claims with no real evidence to back them up, how can the reader not be extremely skeptical? Extraordinary claims require extraordinary evidence. You have provided none, just some anecdotal personal feelings. This is how audiofoolery is born (intentional or not) and promulgated. Please don't do that here. Perhaps you could make some high resolution measurements of your DAC output to show us how these claims are justified, showing the data before and after applying your tweaks?
Finally, you said:
Well, I told you my findings, that virtually none of what you posted about matters for good sound quality. My advice: get yourself a decent but inexpensive Intel based mini-PC. Install Debian or Ubuntu and use the most recent kernel. Most importantly, buy a high-performance, vetted USB DAC (you seem to have a good one already). Plug and play. It's that simple. These are my findings, and at this point there is not much more I can add. Daumen drucken, mein Freund!
I used to think that network streamers made no difference to SQ, until I started to actually listen to them with a good quality DAC in a good sound system.
The most startling difference in SQ that I've heard is between a Windows machine (Foobar w/ WASAPI on pretty much any hardware) and an RPi with a very good linear power supply and an optimized OS.
The difference in SQ is obvious to even untrained ears. It is undeniable.
So yes, pretty much everything in audio effects SQ. Even different linux distributions on network streamers.
But measuring the differences in SQ is damned near impossible, at least with reasonably priced gear.
The most startling difference in SQ that I've heard is between a Windows machine (Foobar w/ WASAPI on pretty much any hardware) and an RPi with a very good linear power supply and an optimized OS.
The difference in SQ is obvious to even untrained ears. It is undeniable.
So yes, pretty much everything in audio effects SQ. Even different linux distributions on network streamers.
But measuring the differences in SQ is damned near impossible, at least with reasonably priced gear.
@ Charlie: I think we have simply different systems and different rooms...and maybe as well different ears, musics and brains.
For me it is normal to respect that. If someone tells me...this is sounding in my system like this or that...I believe him (most of the times) and maybe for curiousity I try it myself and see if I can reproduce it to learn something.
There is no point in discussing running in circles "its there"..."no its not"..."yes it is"...a waste of time...and not a sign of intelligence to continue with that.
If I would listen with Behringer equipment (which I had here once as well)...well, I would not hear a difference either, but lets not go there.
As it has nothing to do with Behringer. I have been at the Highend in Munich which is the largest fare on the subject in the world....hundreds of 100000+ $ chains and components...and seldomly a big aha. WIth this normal commerial stuff you wont get it. Happy when you are happy with it. But this thread is for people who went further. That is why this community exists. Going further.
We are adults. You define your way, I define mine, like many fellows here as well. But I find it offending that you dont know my system at all, never heard anything in my home but claim that you can judge what is happening here or not. As this implies that you and your system are the the reference, which you are clearly not (neither am I).
So, lets PLEASE stay on the subject and not go off-road.
@ Dimitris:
Yesterday I listened to a couple of jazz singer albums I know very well...and there has been all the time ultra-resolution, bu overall not enough warmth/tone/body, call it what you want...I changed the kernel from 1000HZ to 100HZ back. Now we are talking. The realismn is stunning.
Technically we could have a debate why this might sound more realistic...10 times less interrupts...higher throughput per interrupt...less EMI/EMF...whatever. I can understand if people are impressed by the finer grain of 1000HZ timer and the control of RT-Preemption etc. but it is fatigue, tiring to listen to
It is a bit like liking the sound of a very good transistor amp with global feedback vs. a maxed out SE-DHT-amp without any global feedback. Having build both: I prefer the SE-DHT.
So, for me it is interesting that the NONE Preemption with slowest timer is such a "special" combination as everybody else is pushing for lowest latencies...but those latencies come from high software overhead, magnitude higher interrupts etc. while we want an uninterrupted dataprocessing ideally in a noiseless environment.
Plus EMF/EMI...800Mhz on the N5100 sounds better than 1100Mhz...less stressed...but that is no news either (plus the GPU is running at lowest frequency of 200 Mhz anyhow).
Dimitris, can you compile your own Kernel ? I am working on Armbian at the moment where you can do that easily...
For me it is normal to respect that. If someone tells me...this is sounding in my system like this or that...I believe him (most of the times) and maybe for curiousity I try it myself and see if I can reproduce it to learn something.
There is no point in discussing running in circles "its there"..."no its not"..."yes it is"...a waste of time...and not a sign of intelligence to continue with that.
If I would listen with Behringer equipment (which I had here once as well)...well, I would not hear a difference either, but lets not go there.
As it has nothing to do with Behringer. I have been at the Highend in Munich which is the largest fare on the subject in the world....hundreds of 100000+ $ chains and components...and seldomly a big aha. WIth this normal commerial stuff you wont get it. Happy when you are happy with it. But this thread is for people who went further. That is why this community exists. Going further.
We are adults. You define your way, I define mine, like many fellows here as well. But I find it offending that you dont know my system at all, never heard anything in my home but claim that you can judge what is happening here or not. As this implies that you and your system are the the reference, which you are clearly not (neither am I).
So, lets PLEASE stay on the subject and not go off-road.
@ Dimitris:
Yesterday I listened to a couple of jazz singer albums I know very well...and there has been all the time ultra-resolution, bu overall not enough warmth/tone/body, call it what you want...I changed the kernel from 1000HZ to 100HZ back. Now we are talking. The realismn is stunning.
Technically we could have a debate why this might sound more realistic...10 times less interrupts...higher throughput per interrupt...less EMI/EMF...whatever. I can understand if people are impressed by the finer grain of 1000HZ timer and the control of RT-Preemption etc. but it is fatigue, tiring to listen to
It is a bit like liking the sound of a very good transistor amp with global feedback vs. a maxed out SE-DHT-amp without any global feedback. Having build both: I prefer the SE-DHT.
So, for me it is interesting that the NONE Preemption with slowest timer is such a "special" combination as everybody else is pushing for lowest latencies...but those latencies come from high software overhead, magnitude higher interrupts etc. while we want an uninterrupted dataprocessing ideally in a noiseless environment.
Plus EMF/EMI...800Mhz on the N5100 sounds better than 1100Mhz...less stressed...but that is no news either (plus the GPU is running at lowest frequency of 200 Mhz anyhow).
Dimitris, can you compile your own Kernel ? I am working on Armbian at the moment where you can do that easily...
Last edited:
I would suggest that, if you decide to test the i2s path, you try a Dante based board. It's not open source, but you can get them easily and you eliminate a lot of the crap that goes on an ARM board. And it's probably realtime by design. I have two boards from these guys https://www.monisms.com/en-us/ I'm not using for now. I'd be happy to lend them to you for some testing.
If not, look for an ARM board that doesn't use USB for the networking, and actually allows you to control the various frequencies. Another thing that would be interesting is if you get any improvements from disabling GPU, USB, and other subsystems, which is not something you can usually do on x86.
If not, look for an ARM board that doesn't use USB for the networking, and actually allows you to control the various frequencies. Another thing that would be interesting is if you get any improvements from disabling GPU, USB, and other subsystems, which is not something you can usually do on x86.
FYI: I have a Raspberry Pi 3B running an old version of Moode Audio on it (ver 3.8.4). It has a few kernel options, one being real-time (soundcheck/Klaus was responsible for developing this I think). I was curious about the tickless feature mentioned in this thread so I ran the following:
modprobe configs
zgrep ^CONFIG_NO_HZ_FULL /proc/config.gz
which gave:
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
So it would appear that the tickless option is enabled? If you need any further info let me know. Would love to see an equivalent version developed for the latest 64 bit DietPi release which I also use on a Raspberry Pi4.
modprobe configs
zgrep ^CONFIG_NO_HZ_FULL /proc/config.gz
which gave:
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ_FULL_ALL=y
So it would appear that the tickless option is enabled? If you need any further info let me know. Would love to see an equivalent version developed for the latest 64 bit DietPi release which I also use on a Raspberry Pi4.
Actually you can do this quiet well yourself...I just did this for the RP4...the guys from Raspberry have the easiest custom 64bit Kernel option as you just have to start their script...
https://www.raspberrypi.com/documentation/computers/linux_kernel.html#using-menuconfig
A branch is the Linux version..you find that in the left corner as a pulldown menu on git.
So, basically, you can select the latest 5.19.16 version when calling the script with branch= go knto menuconfig...and set the following
These are the most important setting to start with...than it will generate your own, custom kernel for you...
You have to do the work around Cpu isolation and irq isolation, which needs a bit work on the Raspberry as the USB is on the sam üe irq as a couple of other functions and cant be moved from core 0, so the other irq need to go to core 1, eth0 goes to 2 and mod as a RT-service to 3...
But the sound is now really very good on the raspberry I have to say...running with a Lt3045 PSU of course
https://www.raspberrypi.com/documentation/computers/linux_kernel.html#using-menuconfig
A branch is the Linux version..you find that in the left corner as a pulldown menu on git.
So, basically, you can select the latest 5.19.16 version when calling the script with branch= go knto menuconfig...and set the following
- tickless mode full (under general)
- preemptive mode low latency but with dynamic selection at boot
- timer frequency under kernel 100Hz
- Alsa HrTimer enabled
- Osnoise enables under tracers
- ...
These are the most important setting to start with...than it will generate your own, custom kernel for you...
You have to do the work around Cpu isolation and irq isolation, which needs a bit work on the Raspberry as the USB is on the sam üe irq as a couple of other functions and cant be moved from core 0, so the other irq need to go to core 1, eth0 goes to 2 and mod as a RT-service to 3...
But the sound is now really very good on the raspberry I have to say...running with a Lt3045 PSU of course
Just curious, isnt there a multitude of switching converters on the pi itself? To generate all those sub-5V value rails? On my pi 3B, the +5 comes from a switcher on the little amp Hat; there I can make +22 or so going into it linear all I want, but everything else is still "class D", versus A...
Has anyone taken multiple linear regulated voltages and supplied all the voltage values one of these things need? Getting the rail turn-on timing might be fun. Maybe that doesnt matter; she comes up when every voltage turns on at the same time.
Yes, this is the idea of the Allo usbbridge signature...or the Sotm USB card...or DimDims http://www.dimdim.gr/2019/04/an-audio-grade-raspberry-pi/
...actually it might be a major reason why things do sound different...so in order to give stuff the same playing field, I give any SoC a lt3045 based board and any 12V device as well a good LDO linear supply, to be upgraded to lt3045...as I give every SoC a similar modded Kernel, all tickless, isolated IRQs and Isolated Cores etc...
The Fifo and DAC got their own Salas shunt regs which are the best sounding regs I found sofar...but there is too much current fluctuation at startup time in these SoCs, so no shunt reg possible.
Right now I really like the sound of the RP4 over its Usb3.0 ports..which surpises me a lot...Initially I was not a big fan of it when it came out...and we are here still at USB out...actually I prefer it over z8350 currently and not sure about the N5100, sounds a bit technical, but potentially more resolving...all of those are above Odroid Xu4 or Nanpi with Rk3328...
It is interesting as the arm cores are basically most of the time the same...but the SoC chips are not...and the PSU on these boards neither...I thought I found a pattern of x86 rules...but than the Rp4 corrected this...unmodified, no big Ian Canada mod or anything. Only a little Lt3045 psu and a custom Kernel and some work on isolation etc.
The N5100 sounds like a turbo charged car feels...more pressure, very fast signal transmission...more energy. The Raspberry has the same transparency, without any grainines or greyness (like Nanopi an Xu4 added)...but its engine has not turbo but at least 2 liters more, so more warmth, relaxed presentation does the same job but more natural...maybe a bit less energy, less air...but more musical...a matter of taste.
...and still unmodified..still no I2S tried...
One hint...before you compare any sound...let them run at least 24h non stop...even a crytek 957 clock needs that time to stabilize...these little Soc as well.
The one thing I ask myself is how a high powered system like the new 13600K with 14 cores and those huge cache memory may sound if you heavily undervolt it and forced it to lowest power consumption and use a stellar expensive motherboard with good regs on board....so far as well all USB 3.0 outputs on any board I tested did sound better than their usb 2.0 colleagues on board as I huess they are designed hardware wise for much higher specs, less sloppy on the bandwidth we use...and those 20gbit Usb 3.2 ports would be interesting to try as well...I guess I try to convince myself to buy a new PC...
...actually it might be a major reason why things do sound different...so in order to give stuff the same playing field, I give any SoC a lt3045 based board and any 12V device as well a good LDO linear supply, to be upgraded to lt3045...as I give every SoC a similar modded Kernel, all tickless, isolated IRQs and Isolated Cores etc...
The Fifo and DAC got their own Salas shunt regs which are the best sounding regs I found sofar...but there is too much current fluctuation at startup time in these SoCs, so no shunt reg possible.
Right now I really like the sound of the RP4 over its Usb3.0 ports..which surpises me a lot...Initially I was not a big fan of it when it came out...and we are here still at USB out...actually I prefer it over z8350 currently and not sure about the N5100, sounds a bit technical, but potentially more resolving...all of those are above Odroid Xu4 or Nanpi with Rk3328...
It is interesting as the arm cores are basically most of the time the same...but the SoC chips are not...and the PSU on these boards neither...I thought I found a pattern of x86 rules...but than the Rp4 corrected this...unmodified, no big Ian Canada mod or anything. Only a little Lt3045 psu and a custom Kernel and some work on isolation etc.
The N5100 sounds like a turbo charged car feels...more pressure, very fast signal transmission...more energy. The Raspberry has the same transparency, without any grainines or greyness (like Nanopi an Xu4 added)...but its engine has not turbo but at least 2 liters more, so more warmth, relaxed presentation does the same job but more natural...maybe a bit less energy, less air...but more musical...a matter of taste.
...and still unmodified..still no I2S tried...
One hint...before you compare any sound...let them run at least 24h non stop...even a crytek 957 clock needs that time to stabilize...these little Soc as well.
The one thing I ask myself is how a high powered system like the new 13600K with 14 cores and those huge cache memory may sound if you heavily undervolt it and forced it to lowest power consumption and use a stellar expensive motherboard with good regs on board....so far as well all USB 3.0 outputs on any board I tested did sound better than their usb 2.0 colleagues on board as I huess they are designed hardware wise for much higher specs, less sloppy on the bandwidth we use...and those 20gbit Usb 3.2 ports would be interesting to try as well...I guess I try to convince myself to buy a new PC...
Last edited:
I got here half a dozen of other SoC boards which I will now try to use as challenger against the N5100/Rp4...all with the same Kernel, but different SoC Producers /Models...Odroid C2,C4,M1, Rp3, Allo Usbsign, Pine64, BBB etcetc...
And after that, I start with I2S and see who does what.
And after that, I start with I2S and see who does what.
Last edited: