yup thats why i choose it too, its a good compromise between up to date (arch) and stable packages (debian) and it also worked best for me in general
and its backed up by a big company, not some home-made distro
How about DietPi ? it seems like a optimized RaspberryPI OS
interesting, then we had opposite expierences, while i tested the only thing i heared was audio getting more calm with slower clockrates and with higher ones it gets some kind of "digital/hashy" sound to it
yes overclocking helps getting the least OS/CPU Jitter but it doesnt sound best imo
take a look at this board, it actually uses the exact same usb controller : https://www.waveshare.com/cm4-to-pi4-adapter.htm
also using the usb-c port seems like a valid option as dac output, its not connected to the usb controller but directly to the cpu
hmm i have not heared of these problems so farE.g. RPi eeprom-firmware is still under development and that needs to get updated regularly.
That'll be your first CM4 hurdle.And there's more. EEProm backups!?!? So. Better stay away.
I was talking about the NVME Waveshare board. Sorry for the confusion.
Working with NVMEs is IMO the best option.
The NVME Waveshare board uses PCI for NVME. Therefore there's nothing left for USB3.
It's correct that Waveshare also offers an IO Board with 4xUSB3.
My tests have shown though that all media (eMMC, SD, USB-SSD) sounded worse than NVME ssd.
That Waveshare 4xUSB3 board can in fact be a good option for folks who do not want to go the NVME route.
Regarding overclocking.
I was one of the first - if not the first who - who came up with underclocking for audio a couple of years back.
I had the same impression like you in the beginning. During those days I got and supported Paul from pCP to introduce this
or that "audiophile" feature. Once again, my position on underclocking changed over time.
Regarding OS:
I haven't seen many OSes focussing 100% on audio quality. First all it's usually marketing
if these folks talk about audiophile qualities.
Fact is. Most of them need to attract a wide user base, which turns into numerous compromises
these folks have to accept. Because you simply do not spend hundreds of hours on a OS platform that
just a couple of audiophile DIY nerds appreciate. The main issue. If you start such an open-source project,
you are forced to deliver new features and you need to keep it alive.
If you don't, somebody else takes over. Some well known RPi audio OSes started this way - by taking over.
Working with NVMEs is IMO the best option.
The NVME Waveshare board uses PCI for NVME. Therefore there's nothing left for USB3.
It's correct that Waveshare also offers an IO Board with 4xUSB3.
My tests have shown though that all media (eMMC, SD, USB-SSD) sounded worse than NVME ssd.
That Waveshare 4xUSB3 board can in fact be a good option for folks who do not want to go the NVME route.
Regarding overclocking.
I was one of the first - if not the first who - who came up with underclocking for audio a couple of years back.
I had the same impression like you in the beginning. During those days I got and supported Paul from pCP to introduce this
or that "audiophile" feature. Once again, my position on underclocking changed over time.
Regarding OS:
I haven't seen many OSes focussing 100% on audio quality. First all it's usually marketing
if these folks talk about audiophile qualities.
Fact is. Most of them need to attract a wide user base, which turns into numerous compromises
these folks have to accept. Because you simply do not spend hundreds of hours on a OS platform that
just a couple of audiophile DIY nerds appreciate. The main issue. If you start such an open-source project,
you are forced to deliver new features and you need to keep it alive.
If you don't, somebody else takes over. Some well known RPi audio OSes started this way - by taking over.
Last edited:
i will double check next time i play around, some things are kinda so subtle that its easy to mess up while you do own testing, specially since you cant fast A/B with some of this
what are the ones you found that come kinda close?
yes i agree, the audiophile os`s i found so far are very niche (AudioLinux, GentooPlayer for example), kinda ugly, slow updates
also many devs just dont care because its stated that "objectively" stuff like this shouldnt matter
i kinda dont wanna do it but the only good solution i see is taking a good base (DietPi for example) and installing stuff on your own
i iwhs there would be a good out of the box audiophile solution... but i havent found it either
One tweak that is right today, may be wrong tomorrow. That happens all the time.
It simply depends on each and every system at a certain point in time.
Since everything matters, all systems are different. Therefore we see so many
different views and experiences about the same thing.
For people who want an LMS/squeezelite setup, piCorePlayer + sKit IMO still is the best.
You'll have a hard time to better that with any of the RPiOS based setups I've seen.
DietPi is just a basic OS. You'll get basic Debian packages. It'll work. And that's about it.
It simply depends on each and every system at a certain point in time.
Since everything matters, all systems are different. Therefore we see so many
different views and experiences about the same thing.
For people who want an LMS/squeezelite setup, piCorePlayer + sKit IMO still is the best.
You'll have a hard time to better that with any of the RPiOS based setups I've seen.
DietPi is just a basic OS. You'll get basic Debian packages. It'll work. And that's about it.
are the packages that different?
my guess would be that debian packages are just older, but that doesnt mean (always) they are "worse" or?
If you go for LMS Debian/RPiOS packages you should at least go for the Betas.
These are up-to-date.
However. Even these Beta packages and related binaries are build on a different platform.
As the Gentoo folks realized a long time ago: It's always best to build the packages
on your own SW and HW platform.
Beside that even the Beta LMS comes with pretty dusted flac/sox etc. binaries.
And these binaries are in some cases the "engine" for a stream.
Bottom line. There's lot more tweak potential.
People who simply think it's just a server - WTF - do not realize that the
server plays quite a role in all this.
Gotta run. Talking too much. Good luck folks.
These are up-to-date.
However. Even these Beta packages and related binaries are build on a different platform.
As the Gentoo folks realized a long time ago: It's always best to build the packages
on your own SW and HW platform.
Beside that even the Beta LMS comes with pretty dusted flac/sox etc. binaries.
And these binaries are in some cases the "engine" for a stream.
Bottom line. There's lot more tweak potential.
People who simply think it's just a server - WTF - do not realize that the
server plays quite a role in all this.
Gotta run. Talking too much. Good luck folks.
hmm yea its always better to have more uptodate (stable) packages
since i had such a good expierence with fedora im really curious how it would run on a raspberrypi, fedora 37 supports arm fully now
arch seems like not a good option since stuff breaks frequently but fedora seems like the next best thing/compromise
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.
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.
I have a simple question...when people say fedora is it ...or debian...or arch...etc:
What are you looking at ?
I mean this completely neutral...no loaded question at all.
I mean, they all use a kernel from kernel.org, no ?
You can customize yOur kernel to your liking and make it real lean on either one, no ?
When we want to know what is going on, we look all at the same monitoring tools like
etc.
So, what other tools do you use to judge which linux dialect is doimg something different from the other system /OS level ?
What are you looking at ?
I mean this completely neutral...no loaded question at all.
I mean, they all use a kernel from kernel.org, no ?
You can customize yOur kernel to your liking and make it real lean on either one, no ?
When we want to know what is going on, we look all at the same monitoring tools like
- Htop in terms of processes and apps running
- osnoise on interrupt noise etc
- /proc on hardware interrupts running
etc.
So, what other tools do you use to judge which linux dialect is doimg something different from the other system /OS level ?
1. The newer the SW the more efficient it gets. >> higher performance >> less flaws
2. The more the SW gets tailored to your platform the more efficient it gets. >> higher performance >> less flaws
3. The less SW you run on a platform >> higher performance >> less flaws
It's all about efficiency when it comes to SW. The audio stream should flow as smooth as possible from a2b.
And the whole computer is a pretty complex animal. That's why HW drivers and firmware also play a role.
You don't have to measure that a Web Server, that's actively working the network interface, impacts an audio data stream.
You don't have to measure that playing a track 100% from a rambuffer has less impact an audio data stream then doing realtime streaming.
Asf. Asf.
Bottom line. Yes, you could spent numerous more hours proving it all. Or you just follow that efficiency logic and listen what it does.
That doesn't mean that I am not looking at CPU loads etc. If you want more - we'd be entering the scientific research zone.
Bottom line. How much it all impacts your sound experience - depends.
2. The more the SW gets tailored to your platform the more efficient it gets. >> higher performance >> less flaws
3. The less SW you run on a platform >> higher performance >> less flaws
It's all about efficiency when it comes to SW. The audio stream should flow as smooth as possible from a2b.
And the whole computer is a pretty complex animal. That's why HW drivers and firmware also play a role.
You don't have to measure that a Web Server, that's actively working the network interface, impacts an audio data stream.
You don't have to measure that playing a track 100% from a rambuffer has less impact an audio data stream then doing realtime streaming.
Asf. Asf.
Bottom line. Yes, you could spent numerous more hours proving it all. Or you just follow that efficiency logic and listen what it does.
That doesn't mean that I am not looking at CPU loads etc. If you want more - we'd be entering the scientific research zone.
Bottom line. How much it all impacts your sound experience - depends.
Running the server and the player on the same machine IMO can be the best of
all solutions, if we talk basic streaming.
Separating server and player on two machines adds more complexity - HW and SW.
However.
Having both tasks running concurrently on one machine will cause a new local impact.
The main challenge is to keep that impact as low as possible.
Goal: The impact of the concurrent server/player operation on a single machine needs to be lower than
the impact you'd face by adding a seperate server.
As a matter of fact, depending on your setup the balance can shift in either direction. Your HW and SW
setup plays a big role here.
All I can say. It's possible to run just one Pi4 with LMS/squeezelite at great audiophile performance.
It would require a lean server setup and a bit of tweaking. I am doing it for quite some time (years) now.
And for me the single machine approach is simply more convenient, cheaper and also saves quite some
energy.
My sKit for pCP doesn't support it. Time is money.
all solutions, if we talk basic streaming.
Separating server and player on two machines adds more complexity - HW and SW.
However.
Having both tasks running concurrently on one machine will cause a new local impact.
The main challenge is to keep that impact as low as possible.
Goal: The impact of the concurrent server/player operation on a single machine needs to be lower than
the impact you'd face by adding a seperate server.
As a matter of fact, depending on your setup the balance can shift in either direction. Your HW and SW
setup plays a big role here.
All I can say. It's possible to run just one Pi4 with LMS/squeezelite at great audiophile performance.
It would require a lean server setup and a bit of tweaking. I am doing it for quite some time (years) now.
And for me the single machine approach is simply more convenient, cheaper and also saves quite some
energy.
My sKit for pCP doesn't support it. Time is money.
Thank you for your point of view,
I respect your analysis,But I find it hard to believe that a server and player on the same machine be more efficient that a server on a Raspi/pCP and the player on another Raspi/pCP side by side with a Cat8 cable.
"It would require a lean server setup and a bit of tweaking. I am doing it for quite some time (years) now"
pCP It is not already a lean server,what are the tweak you applied.
I respect your analysis,But I find it hard to believe that a server and player on the same machine be more efficient that a server on a Raspi/pCP and the player on another Raspi/pCP side by side with a Cat8 cable.
"It would require a lean server setup and a bit of tweaking. I am doing it for quite some time (years) now"
pCP It is not already a lean server,what are the tweak you applied.
There's nothing to believe here.
Over here at DIYA we usually talk about experiences and findings. That's not some theoretical hocus pocus.
People have been doing and trying it. And spent long hours and quite some money on it. A few people
even share some of the work with the community. Most problems over here at DIY-A start when
certain people start hijacking great opportunities by asking for explanations and measurements.
These people know very well that nobody can and would be willing to afford a scientific lab to
prove the point.
That's why it is so important to run the empirical approach. The more inmates confirm
a certain result or behaviour, the more you can rely on the validity of a subject.
Bottom line. It's up to every single inmate to follow a certain hint or strategy.
Now.
pCP is a lean system in terms of the operating system it is based on. It's called TinyCore linux.
TinyCore keeps the resource utilization as low as possible to be able to run 100% from
RAM on small machines. That approach comes with a lot of compromises on the software side though. And it
requires a lot of maintenance efforts for developers to keep it all going.
If things becoming bigger - e.g. if you start a lms server - 100% RAM operation will no longer
be the winning argument. However. If you lack in-depth computer skills pCP is IMO still a
good choice to get going rather quickly.
I btw share the stuff that I am willing to share through my blog and on github.
Enjoy.
Over here at DIYA we usually talk about experiences and findings. That's not some theoretical hocus pocus.
People have been doing and trying it. And spent long hours and quite some money on it. A few people
even share some of the work with the community. Most problems over here at DIY-A start when
certain people start hijacking great opportunities by asking for explanations and measurements.
These people know very well that nobody can and would be willing to afford a scientific lab to
prove the point.
That's why it is so important to run the empirical approach. The more inmates confirm
a certain result or behaviour, the more you can rely on the validity of a subject.
Bottom line. It's up to every single inmate to follow a certain hint or strategy.
Now.
pCP is a lean system in terms of the operating system it is based on. It's called TinyCore linux.
TinyCore keeps the resource utilization as low as possible to be able to run 100% from
RAM on small machines. That approach comes with a lot of compromises on the software side though. And it
requires a lot of maintenance efforts for developers to keep it all going.
If things becoming bigger - e.g. if you start a lms server - 100% RAM operation will no longer
be the winning argument. However. If you lack in-depth computer skills pCP is IMO still a
good choice to get going rather quickly.
I btw share the stuff that I am willing to share through my blog and on github.
Enjoy.
I use moOde on a Rpi 3+b 1gb. I had not bothered with OS parameters since days of MPDPup. So thanks Bliz and Ghoostknight for catching my interest. As a Linux dummy it took a while to relearn how to navigate and make simple changes. I agree with the assertion that OS noise still impacts sound quality.
First discovery... I have been running 32 bit version of moOde. Switched to 64 bit. Substantial improvement in sound. Duh?
Next implemented Ghoostknight's suggested mods to /boot/cmdline.txt. No issues. Then set CPUAffinity=3 in /lib/systemd/system/mpd.service. These 2 simple changes improved sound. As always, just a little better transparency and separation around instruments. Fuller? Words fail. So I'll be following this thread with interest.
With decent headphones (Grado) on my laptop, I can get a sense of it even on a Youtube post recorded with phone. First track recorded today with CPUAffinity set to one core. Its a reasonably well recorded track from Chesky.
Soundcheck and all, I am a late comer here. I am setting up my Raspberry Pi4 and Digione that is going to be hooked up to a Benchmark Dac. I am only interested in audio. Please give me your recommendation on what apps may be adequate for my purpose. I am reading that piCorePlayer, Moode, and Runeaudio may be good options. Thank you
The other day I ran the Alsa command-line tool aplay fed with a .wav file on a isolated CPU.
Jee. I asked myself what I've been doing all these years - since 2007.
Beside that - the stuff you quoted stands - somewhat.
I nowadays prefer a single RPi4 combined server/player setup though.
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.
Over @ audiophonics you find a nice one nowadays at 23€ (Power Supply Filter Module for Raspberry Pi 5976µF)
or you'll also find that IMO overpriced IANcanada stuff also over there. He's asking for his
Shield Pro - 75€ and for his UCPI 85€. Keep in mind that HATs won't allow for proper cooling.
Good luck on your journey.
Jee. I asked myself what I've been doing all these years - since 2007.
Beside that - the stuff you quoted stands - somewhat.
I nowadays prefer a single RPi4 combined server/player setup though.
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.
Over @ audiophonics you find a nice one nowadays at 23€ (Power Supply Filter Module for Raspberry Pi 5976µF)
or you'll also find that IMO overpriced IANcanada stuff also over there. He's asking for his
Shield Pro - 75€ and for his UCPI 85€. Keep in mind that HATs won't allow for proper cooling.
Good luck on your journey.