Indeed, i would try that but need as well a starting point and a manual or an iso.
.archphile was very nice, but drove me crazy when it didnt boot most of the time with rp4...so a more modern version of it with mpd and tweaks...nice...i am still on my old mpdpuppy
The image that I have is for my CM3-based "AudioPi" board, so it will not work out-of-the-box for the RPi4, but I have kept good notes so it should not be too difficult to replicate my work for the RPi4. In fact I am planning to do an RPi4 image (since I do own one) but it is a relatively low priority.
I might write a blog post about this, but since that would take a while here is an outline of what I had to do:
That's pretty much it..
So on the system level the only thing that I disabled was logging by journal.. Other than that, Arch Linux is pretty bare-bones to begin with.
With all of the above loaded, RAM use was about 70-75MB out of 1GB. Boot time using a very slow SD card was something like 10 seconds.
When MPD got done indexing my entire library of over 90.000 songs, memory usage went up to about 110MB and that's it.
I might write a blog post about this, but since that would take a while here is an outline of what I had to do:
- Follow these instructions to create the initial Arch Linux Arm image (ARMv7 Installation): https://archlinuxarm.org/platforms/armv8/broadcom/raspberry-pi-3
- Log in to the system, change default passwords, hostname, timezone etc.
- Enable SSH access for root
- Set up pacman and do a full update of the system
- Install some tools that I find useful (htop, usbutils, wget)
- Disable logging by journal (nano /etc/systemd/journald.conf and put Storage=none)
- Create and mount my Samba shares
- Install and configure mpd and mpc (pacman), create symlinks to samba shares for music, etc.
- Get and install MyMpd: https://jcorporation.github.io/myMPD/installation/compiling It is not available through pacman.. you will need to compile it.
- Edit /boot/config.txt in order to disable a bunch of useless stuff and enable your HAT overlay (if applicable). I have used Archphile's config.txt with a few slight alterations.
- (optional) install spotifyd
That's pretty much it..
So on the system level the only thing that I disabled was logging by journal.. Other than that, Arch Linux is pretty bare-bones to begin with.
With all of the above loaded, RAM use was about 70-75MB out of 1GB. Boot time using a very slow SD card was something like 10 seconds.
When MPD got done indexing my entire library of over 90.000 songs, memory usage went up to about 110MB and that's it.
Many thanks for this. Apparently it will not work with my board, but perhaps assembling something despite my old age's aversion towards learning new things may be more fun
For some reason the vast majority of Rpi users have very different requirements to mine anyway. They want displays, VU meters, GUIs, cataloguing and indexing, samba shares, music players, USB, radio, streaming. My requirements are more modest. Ethernet, UpnP renderer, i2s output. Already have a software player on a PC that can see renderers over the network.
Why only a renderer? A few years ago went through all the popular distributions set in the normal way, hated them all, but Archphile clearly sounded better. And even better as a DLNA renderer. Which perhaps makes sense.
For some reason, probably senility, instead of buying another 3B i decided that my next Pi should be a 4B.
No luck getting sound comparable to the 3B so far. Tried an R-Audio (Rune spinoff, Archlinux based) renderer which had some interesting sonic qualities but could not really match the Archphile on 3B and also a dietPi minimal installation with only a renderer which sounded even worse but took much longer to install.
Could it be it's the 4B hardware signature that is different and not to my liking? Anyone wants to upgrade their high mileage 3B to a brand spanking new 4B?
Have you tried verifying your perceptions in any objective, controllable way?Could it be it's the 4B hardware signature that is different and not to my liking? Anyone wants to upgrade their high mileage 3B to a brand spanking new 4B?
I did not compare 3b with 4b...but I tried 4b...with Archphile sounded good if it boots which it rarely does without a reason. I use MPD.
Therefore i went to dietpi as an alternative even though not quiet as well sounding. And went to a 3B derivate https://allo.com/sparky/usbridge-signature-pcb.html which indeed sounded better than the 4b, but hey, they changed there a lot...
Interesting enough, I did not find the i2s to my Soekris Dam1941 sounding beeter than usb input into the same dac.
So, in the end my very old mpdpuppy Alix1D board made the race...which may make sense as there was a time when we have been avoiding high powered and power solutions...this old board is really slow and has 256mb Ram ? So maybe the muscles of the RP4 are the problem here ? I think DimDim had on his blog similar observations...
I am not afraid to confiure my own linux, but it costs time as i have as well a learning curve...but than i would create a small mpd puppy version as I know the old version sounded sofar best of all linux versions..
Original version here...61MB... https://oldforum.puppylinux.com/viewtopic.php?t=81984&sid=5d01754ccd2a8d9c9b930708ad729dd5
I believe it was debian based if I read the forum right...but lots of twealüks and tunes, and maybe it üs as well the olf hardware which makes this very free, musical sound (sotm card, USB -Out)
Therefore i went to dietpi as an alternative even though not quiet as well sounding. And went to a 3B derivate https://allo.com/sparky/usbridge-signature-pcb.html which indeed sounded better than the 4b, but hey, they changed there a lot...
Interesting enough, I did not find the i2s to my Soekris Dam1941 sounding beeter than usb input into the same dac.
So, in the end my very old mpdpuppy Alix1D board made the race...which may make sense as there was a time when we have been avoiding high powered and power solutions...this old board is really slow and has 256mb Ram ? So maybe the muscles of the RP4 are the problem here ? I think DimDim had on his blog similar observations...
I am not afraid to confiure my own linux, but it costs time as i have as well a learning curve...but than i would create a small mpd puppy version as I know the old version sounded sofar best of all linux versions..
Original version here...61MB... https://oldforum.puppylinux.com/viewtopic.php?t=81984&sid=5d01754ccd2a8d9c9b930708ad729dd5
I believe it was debian based if I read the forum right...but lots of twealüks and tunes, and maybe it üs as well the olf hardware which makes this very free, musical sound (sotm card, USB -Out)
Last edited:
Entry point today i gUess: https://puppylinux-woof-ce.github.io/
I like this one from their web-page:
I like this one from their web-page:
Puppy Linux advantage
- Ready to use → all tools for common daily computing usage already included.
- Ease of use → grandpa-friendly certified ™
- Relatively small size → 300 MB or less.
- Fast and versatile.
- Customisable within minutes → remasters.
I use Ian's fifo along the way too.
Speak for yourself young man
Not sure i understand what is important for sound. Small size and grampa friendliness might not suffice.
I got Ian's fifo (and battery supply) in the setup as well...with RP4, with "RP3-Allo SignUSBbridge" etc...
No, this was not the list of arguments why it sounds better. I dont argue. I dont even know if a new setup will sound better. I just know, the old MPD-Puppy setup does sound better than RP3 or Rp4 (with fifo...and battery) and Archphile or any other like DIetpi etc...tried many and listenend. And I am not happy about this. I want new hard and software which allow me more to do like streaming etc.
In the end I bought a Bluesound Nt130, changed its PSU as a streaming solution which gives me even Amazon Music HD or and other HD streaming (...and for serious PCM-listening the old Alix-Board)...the bluesound (latest version) is actually quiet nice, maybe at the same level as a RPx solution, but with lots better software regarding streaming...still not the ultimate for your own PCM, but surprisingly good...a perfect candidate for your magical tuning skills, Peter...
No, this was not the list of arguments why it sounds better. I dont argue. I dont even know if a new setup will sound better. I just know, the old MPD-Puppy setup does sound better than RP3 or Rp4 (with fifo...and battery) and Archphile or any other like DIetpi etc...tried many and listenend. And I am not happy about this. I want new hard and software which allow me more to do like streaming etc.
In the end I bought a Bluesound Nt130, changed its PSU as a streaming solution which gives me even Amazon Music HD or and other HD streaming (...and for serious PCM-listening the old Alix-Board)...the bluesound (latest version) is actually quiet nice, maybe at the same level as a RPx solution, but with lots better software regarding streaming...still not the ultimate for your own PCM, but surprisingly good...a perfect candidate for your magical tuning skills, Peter...
I am back now looking into the source as Andrea Moris Fifo and Dac are so transparent that you litterally can hear each change...So i will evaluate SoCs (have now 12 up and running C2,C4...Rp3/4...Beaglebone etcetc), but as well software.
The golden standard is still mpdpup and Archphile, but both are no longer maintaine dor the pages are down....
So, I need a Working Archphile C2 image...could someone share this with me ?
I can open a google drive shared folder for upload...
The purpose is to compare it to DietPi/Debian with some tunings I will apply over time. DietPi is a Debian Bullseye which runs with MPD and lighttpd at 80-100MB Ram. Cpu 3-4%...It is easy and fast to configure through menus for Non Linux People...and sounded nearly as good as Archphile out of the box, so a good starting point and available for most arm and x86
I will try to back-engineer some of the principles of Archphile (when I got a working copy), ideally on the C2, but as well for Rasberry and others...and some of the principle of Dynobots and MPDpuppy...
I will do this step by step and always verify by listening
What was a nice start:
Next to try:
So, if anyone joins this effort building up a new audiophile Archphile-Replacement...you are welcome.
The idea is to make this a bit more distribution independent. Everything i just described can be done in Debian, Puppy, Arclinux, what ever your cup of tea is. Arm, x86...as it is about principles what works for good sound...so a transparent cookbook everyone can try to apply.
The golden standard is still mpdpup and Archphile, but both are no longer maintaine dor the pages are down....
So, I need a Working Archphile C2 image...could someone share this with me ?
I can open a google drive shared folder for upload...
The purpose is to compare it to DietPi/Debian with some tunings I will apply over time. DietPi is a Debian Bullseye which runs with MPD and lighttpd at 80-100MB Ram. Cpu 3-4%...It is easy and fast to configure through menus for Non Linux People...and sounded nearly as good as Archphile out of the box, so a good starting point and available for most arm and x86
I will try to back-engineer some of the principles of Archphile (when I got a working copy), ideally on the C2, but as well for Rasberry and others...and some of the principle of Dynobots and MPDpuppy...
I will do this step by step and always verify by listening
What was a nice start:
- Use Dietpi-Config and set governor=userspace and try the lowest CPU frequency as fixed frequency between 250-500mhz. MPD need no CPU power and everything is at lower frequency less stressful sounding
- the governor userspace sounds much better than any other, like the famous curtain you take away
- some MPD tweaks on buffers
Next to try:
- Diet allows to give individual service individual CPU-Cores...which has been one of the things Archphile did as well, so following and see what this does sound wise, so MPD gets his own exclusive core, Networking its own, USB...
- Underclocking any GPU if it could not be switched off completely (which Archphile did as well, that was a feature not a bug)
- Samba vs NFS vs local storage: Any differences in Sound ?
- USB-Interrupts: Separate CPU Core, chekcing the buffers etc, once optimized:
- USB sound vs. I2S direct
- Upnp Renderer vs. MPD-Direct sound (like Peter suggested)
- Realtime Kernel vs. Realtime Prioritization for selected Services (lowest latencies dont have to sound best in playback settings)
So, if anyone joins this effort building up a new audiophile Archphile-Replacement...you are welcome.
The idea is to make this a bit more distribution independent. Everything i just described can be done in Debian, Puppy, Arclinux, what ever your cup of tea is. Arm, x86...as it is about principles what works for good sound...so a transparent cookbook everyone can try to apply.
Last edited:
Well, as a software engineer myself I can only verify if the computer does what I tell him to do. That I will check with the tools we have in Linux...Yes and I do benchmarks but when you now give USB an exclusive core and you can measure a higher bandwith(which other people already did): So what ? Does this automatically sound better ? Maybe, maybe not.
Can I come up with theories about reducing interrupts on dedicated CPU-Audio-Cores sound better ? I could. But as long as I cant hear it...only a theory.
But I wont try now to measure jitter behavior or Emf/EMI behavior on the motherboard and trying to find variable we can measure with equipment which costs xxxxx$...and which in the end still cant explain fully what we hear.
So, it depends how you want to look at it. My method is simple: I listen. I take time and move slow before I conclude on a step as your perception can be the next day different...and only when I consistently can recognize something as an improvement i go forward with this setting. One by one.
And what I like does not have to be something you like. That is not so important. It is more interesting to see what makes changes in sound. And you can decide yourself if and how you want to tweak it to your preference. Knowing todays Linux variables and tools to make it happen is the point.
That is why a sript like Dynobot did is for me too static as my experience on my hardware and my system is different from some of his choices (nrpacks as an example...some people love it to be 1 for low latency, others like me prefer 20...unfortunately the buffer optimization for USB has been now hardcoded and this nice parameter is gone...but many people witnessed its effect).
On the hardware side, other people made extensive effort to explain (and measure) why the RP has so much trouble generating a clean I2S and how to improve maybe or why the USB/Ethernet have been fighting against each other on it for resources etc...and I guess those kind of not so helpful design decisions for audio are baked into other SoC as well more or less...so giving them the same software and listen is the only way.
Can I come up with theories about reducing interrupts on dedicated CPU-Audio-Cores sound better ? I could. But as long as I cant hear it...only a theory.
But I wont try now to measure jitter behavior or Emf/EMI behavior on the motherboard and trying to find variable we can measure with equipment which costs xxxxx$...and which in the end still cant explain fully what we hear.
So, it depends how you want to look at it. My method is simple: I listen. I take time and move slow before I conclude on a step as your perception can be the next day different...and only when I consistently can recognize something as an improvement i go forward with this setting. One by one.
And what I like does not have to be something you like. That is not so important. It is more interesting to see what makes changes in sound. And you can decide yourself if and how you want to tweak it to your preference. Knowing todays Linux variables and tools to make it happen is the point.
That is why a sript like Dynobot did is for me too static as my experience on my hardware and my system is different from some of his choices (nrpacks as an example...some people love it to be 1 for low latency, others like me prefer 20...unfortunately the buffer optimization for USB has been now hardcoded and this nice parameter is gone...but many people witnessed its effect).
On the hardware side, other people made extensive effort to explain (and measure) why the RP has so much trouble generating a clean I2S and how to improve maybe or why the USB/Ethernet have been fighting against each other on it for resources etc...and I guess those kind of not so helpful design decisions for audio are baked into other SoC as well more or less...so giving them the same software and listen is the only way.
Last edited:
Nothing wrong with listening, as long as it is controlled double blind. With tweaks, double blind is especially important, because we all want to believe the tweaks work.
On the other hand, noise and jitter can be measured pretty well with a decent (not expensive) ADC and free software - even easier, if you measure a digital source and expect improvements in the digital output.
On the other hand, noise and jitter can be measured pretty well with a decent (not expensive) ADC and free software - even easier, if you measure a digital source and expect improvements in the digital output.
Well, in German there is a saying: "Wer misst, misst Mist"...meaning you can make a lot of mistakes when trying to objectively measure. Clearly, I would not trust my capabilities...and to be honest I am interested more in the end result. I could give you a long list of examles where we today agree the audible difference (like caps, rectifiers etcetc)...and measurements cant explain it...nor does they show a difference in THD or Frequency amplitude. Or you even develop something and finally have desired mearuement outcome ....and it sounds like sh...
So, in order not to fool myself: I believe in methodology and structured testing which I learned this as a software engineer.
And an important part of this methodolgy is to share findings, so that others can see if they can repoduce them. So, you have your sceptics build into the approach....that way we found in the old days (when tuning first Windows...later Linux yourself vs. today just installing Roon oder volumio) often consensus on findings...which then is just plain fun..to explore something together.
BTW...I love Dietpi for the nice tuning menus: So while you listen to music, you can change the governor or frequency setting in a parallel SSH session. This is just a 1 sec operation...(no nano of *conf needed)which helps a lot to immediately realize what has changed. Maybe at some day I learn how to write those menus in Linux-scripts so I have a toggle switch to A/B-Settings what ever the parameter are I want to change like deeper IRQ-tunings etc.
So, in order not to fool myself: I believe in methodology and structured testing which I learned this as a software engineer.
And an important part of this methodolgy is to share findings, so that others can see if they can repoduce them. So, you have your sceptics build into the approach....that way we found in the old days (when tuning first Windows...later Linux yourself vs. today just installing Roon oder volumio) often consensus on findings...which then is just plain fun..to explore something together.
BTW...I love Dietpi for the nice tuning menus: So while you listen to music, you can change the governor or frequency setting in a parallel SSH session. This is just a 1 sec operation...(no nano of *conf needed)which helps a lot to immediately realize what has changed. Maybe at some day I learn how to write those menus in Linux-scripts so I have a toggle switch to A/B-Settings what ever the parameter are I want to change like deeper IRQ-tunings etc.
Last edited:
I would love to see examples where there are verified (by double-blind test) audible differences that can't be measured.
You can make a lot of mistakes when trying to measure, but you can make even more mistakes if you rely on your ears (or rather what is between the ears).
Software engineering does teach you about structured testing - so apply it! Be aware of psychology, and confirmation/expectation bias.
BTW, by "Linux-scripts", do you mean shell scripts?
You can make a lot of mistakes when trying to measure, but you can make even more mistakes if you rely on your ears (or rather what is between the ears).
Software engineering does teach you about structured testing - so apply it! Be aware of psychology, and confirmation/expectation bias.
BTW, by "Linux-scripts", do you mean shell scripts?
I meant shell scripts in combination with the excutable scripts ...so basically a menu to select parameters and than scripts applying them like those: https://github.com/brianlight/Linux-Audio-Adjustments/blob/master/README.md
And I think we can stop the discussion about "I only trust my ears when my eyes saw the measurements supporting what I hear". We are adults. Each of us can select his own methodolgy how to get the best result. And I dont claim to know anthing more than anyone else here. It is about all about an approach how to make currently available Linux-versions tuned in a way as we already had it before and no longer available.
I agree with PEter in his assement that Archphile was better than what was available (except MPDuppy). But its no longer there. That is the problem to solve.
And I think we can stop the discussion about "I only trust my ears when my eyes saw the measurements supporting what I hear". We are adults. Each of us can select his own methodolgy how to get the best result. And I dont claim to know anthing more than anyone else here. It is about all about an approach how to make currently available Linux-versions tuned in a way as we already had it before and no longer available.
I agree with PEter in his assement that Archphile was better than what was available (except MPDuppy). But its no longer there. That is the problem to solve.
Last edited:
Shell scripts are executable - do you mean something else? That link just shows normal shell commands.
I ment something similar like this:
https://dietpi.com/docs/assets/images/dietpi-services_2.png
https://dietpi.com/docs/assets/images/dietpi-services_2.png
I am digging deeper into stuff ...and if you simply google jitter and Linux...you have a huge load of articles with the desired measurements...I wont post now all of them, but its interesting to see that the bestpractises Archphile used like defining isolcpus and thread affinities / dedicated cores for MPD, Network and USB makes a ton of sense:
http://blog.vanillajava.blog/2013/07/micro-jitter-busy-waiting-and-binding.html
https://obihoernchen.net/1416/odroid-xu4-tune-network-and-usb-speed/
http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/
Systematic process to decrease OS Jitter in Linux: https://groups.google.com/g/mechanical-sympathy/c/DWlziVmyW-w
So, lots to learn..which is fun...nothing is black magic, but well researched already...
http://blog.vanillajava.blog/2013/07/micro-jitter-busy-waiting-and-binding.html
https://obihoernchen.net/1416/odroid-xu4-tune-network-and-usb-speed/
http://btorpey.github.io/blog/2014/02/18/clock-sources-in-linux/
Systematic process to decrease OS Jitter in Linux: https://groups.google.com/g/mechanical-sympathy/c/DWlziVmyW-w
So, lots to learn..which is fun...nothing is black magic, but well researched already...