Although I am far from being an RT Linux expert, please keep in mind that there are many factors that affect latency.
Raspbian latency performance will be different comparing ArchlinuxARM etc. It depends on kernel configuration, OS configuration, how everything was built etc.
You can have a look at Soundcheck's findings here:
soundcheck's - audio@vise: RaspBerry PI - The Audio Engine - Part 7 - Realtime Kernel
and especially the benchmarking section..
Raspbian latency performance will be different comparing ArchlinuxARM etc. It depends on kernel configuration, OS configuration, how everything was built etc.
You can have a look at Soundcheck's findings here:
soundcheck's - audio@vise: RaspBerry PI - The Audio Engine - Part 7 - Realtime Kernel
and especially the benchmarking section..
Last edited:
Thanks Mike. I plan to experiment it on another microsd. If it doesn’t work out then heck it
Unfortunately those benchmarks don't say anything about the effects on the sound.
Julf I totally agree with you.
I just gave this link just to show that ArchlinuxARM kernel has a different configuration (almost every distro has a different configuration, different software versions etc - It's not that Arch is so special!) comparing to kernels of others distros and thus LL perormance will be different.
That's all I wanted to say.
I just gave this link just to show that ArchlinuxARM kernel has a different configuration (almost every distro has a different configuration, different software versions etc - It's not that Arch is so special!) comparing to kernels of others distros and thus LL perormance will be different.
That's all I wanted to say.
Last edited:
Julf, of course I don't want to get into this debate. Whenever I discuss about Archphile and RT kernel configuration I give this link:
Real-Time Scheduling
Again, I am not an expert, but what I know is what is stated at the end of the page:
There is almost no chance for the system to go under heavy load. Even the -16 MPD niceness set by me is an overkill nowadays and was set many years ago when the RPI was a piece of crap and only had one (weak) core.
Real-Time Scheduling
Again, I am not an expert, but what I know is what is stated at the end of the page:
Under standard Archphile configuration (not with the SACD fork etc..), the system is almost idle due to it's minimal design (no http servers apart from mongoose which is embedded in ympd, databases etc..).
There is almost no chance for the system to go under heavy load. Even the -16 MPD niceness set by me is an overkill nowadays and was set many years ago when the RPI was a piece of crap and only had one (weak) core.
Last edited:
New packages for ympd and upmpdcli are up for both the RPI and odroid:
Code:
pacman -Sy ympd-archphile upmpdcli-archphileFor ympd:
Code:
systemctl reenable ympd
systemctl restart ympdFor upmpdcli, if the service is enabled during boot:
Code:
systemctl reenable upmpdcli
systemctl restart upmpdliif not, then you don't have to do anything.
Hopefully this upmpdcli package solves the tidal issues.
Last but not least, for RPI users that want to use the tweaks that are going to be applied in next Archphile image, you can have a look at this script:
http://archphile.org/lab/update_scripts/rpi-update
All this script does is:
- it downloads a newer cmdline.txt which isolates core 0 that gets all interrupts and core 1. Core 1 will be used by MPD later.
- it downloads a newer archphile-optimize file and enables two commands for mpd and ympd that redirect them to specific cores.
IRQ affinity and isolated cores are being used for years in Archphile for Odroid C1+/C2 and even older boards like the Udoo Quad. Due to the design of the RPI, IRQ interrupts cannot be moved to other than core 0 (the first core). For this reason I decided to isolate core 0 to only deal with interrupts.
Regarding MPD, another aproach is to give it 2 isolated cores. Based on my experience and years of using this setting, one core is more than enough.
The reason I have been applying all these "tweaks" for years now, is not the sound quality but the system stability and performance. Especially for boards like the Odroid C2, moving ethernet and usb interupts to different cores was necessary while using 3.X kernels..
Please note that Archphile users that have the MPD SACD ISO fork should not isolate any cores!
Last edited:
Code:
There is a rumor that real-time scheduling improves audio quality. That is not true.One of these nonsense statements of people who havn't understood what's being talked about.
I think I made clear more then once that the goal is to lower any kind of
inefficiency on a computer.
Inefficiencies causing noise, (data-)jitter, load variations (CPU and PSU), additional EMI/RFI... ...you name it.
These "undeniable" flaws might impact perceived soundquality.
An rt-kernel can be used to improve that flawed situation.
Thus it can very well take part of a different sound-experience.
We had 3 kernels for Moode - stock Raspbian, low latency and rt. My idea was - "Why argue? Just provide all options!"
The feedback that's been received confirmed that there are this or that
reason to provide all of them.
***
My rt-benchmarks were taken on an already highly optimized and lowest load system.
I didn't feel to run high-load testcases. I don't run multiple apps - I'm running single purpose systems.
Perhaps I'll have a little closer look at the subject one day.
Just to mentioned it. The kernel efficiency improved substantially over recent years in multiple areas. On top of that the kernel scheduler folks try hard to make the rt-kernel obsolete one day. Let see how things are developping.
Enjoy.
OK, so the RT kernel might or might not lower inefficiency of the computer (whatever inefficiency is defined as). Those "inefficiencies" might (or might not) cause noise, (data-)jitter, load variations (CPU and PSU), additional EMI/RFI... ...you name it. Those effects might (or might not) in turn impact perceived sound quality.
I wouldn't be surprised if they indeed impact *perceived* sound quality. I would love to see evidence that they effect actual, measurable and objectively verifiable sound quality.
Look. The rt-kernel allows for higher effieciency.
Here is one benchmark.
These benchmarks simply show lower latencies = higher efficiency / less distraction.
Most of the measures I'm listing on my blog do this.
You'll see better networking performance, you'll see better binary performance,
you'll see lower CPU load, you see lower power usage. Many of them proven by benchmarks.
We also used AudioDiffmaker on my TouchToolbox - over at squeezebox forums. I had similar discussions over there. Some of you might recall it.
Audiodiffmaker compares real music tracks.
Basically you do a recording on a non tweaked environment and then you record from the tweaked environment.
AudioDiffmaker is the only way I'm aware off to make differences visible at a reasonable effort. Those who looked at the results were quite surprised.
Actually I didn't do it myself in the first place. It was mainly done to prove me wrong. And. It didn't!
Yep. I know. That's still not enough.
Usually what's being used as the counter argument. "Where are the measurements?"
Non of us low budget folks can afford the equipment required to do real world highest quality measurements. (On the other side, there are folks around who think to prove the "no-difference" theories by using ridiculous soundcards and highly questionable tools. If these doesn't show a difference there's none! - the usual conclusion you'll find!
You could also stick a wet finger in the air and would come up with the same conclusion.)
And even if you present test results, proving the storyline, you'll find the usual trolls arguing against it without ever showing anything from there side.
And all this is exactly the reason why there's no progress.
And all this is exactly the reason why you as OS provider/maintainer should offer all options to stop these more then counterproductive arguments!
My "quick and dirty" rt-benchmarks shouldn't excuse Tuxx from offering an rt-kernel! Give the crowd the options. Let them decide. That worked well on Moode, it works on piCorePlayer, it'll work for you.
And don't forget. An rt-kernel alone, not being properly integrated, can do more bad than good!
That's what you as system maintainer fear most!
And that's the main reason why most of them stay away from it.
I'd say. Just do it.
Enjoy.
PS: The SB Touch was also running a rt-kernel!
Here is one benchmark.
These benchmarks simply show lower latencies = higher efficiency / less distraction.
Most of the measures I'm listing on my blog do this.
You'll see better networking performance, you'll see better binary performance,
you'll see lower CPU load, you see lower power usage. Many of them proven by benchmarks.
We also used AudioDiffmaker on my TouchToolbox - over at squeezebox forums. I had similar discussions over there. Some of you might recall it.
Audiodiffmaker compares real music tracks.
Basically you do a recording on a non tweaked environment and then you record from the tweaked environment.
AudioDiffmaker is the only way I'm aware off to make differences visible at a reasonable effort. Those who looked at the results were quite surprised.
Actually I didn't do it myself in the first place. It was mainly done to prove me wrong. And. It didn't!
Yep. I know. That's still not enough.
Usually what's being used as the counter argument. "Where are the measurements?"
Non of us low budget folks can afford the equipment required to do real world highest quality measurements. (On the other side, there are folks around who think to prove the "no-difference" theories by using ridiculous soundcards and highly questionable tools. If these doesn't show a difference there's none! - the usual conclusion you'll find!
You could also stick a wet finger in the air and would come up with the same conclusion.)
And even if you present test results, proving the storyline, you'll find the usual trolls arguing against it without ever showing anything from there side.
And all this is exactly the reason why there's no progress.
And all this is exactly the reason why you as OS provider/maintainer should offer all options to stop these more then counterproductive arguments!
My "quick and dirty" rt-benchmarks shouldn't excuse Tuxx from offering an rt-kernel! Give the crowd the options. Let them decide. That worked well on Moode, it works on piCorePlayer, it'll work for you.
And don't forget. An rt-kernel alone, not being properly integrated, can do more bad than good!
That's what you as system maintainer fear most!
And that's the main reason why most of them stay away from it.
I'd say. Just do it.
Enjoy.
PS: The SB Touch was also running a rt-kernel!
Last edited:
I read this post and I feel like for some reason I am obliged to offer a RT kernel or I need to apologize for not offering it.
Just to make it clear: I am not afraid of anything and I don't have to offer all options for people to be able to choose.
The reason is simple: I don't care about RT kernels at the moment, I don't want to waste my time on it and as a result I don't offer such a solution.
If anyone believes that Archphile or any other project should implement a RT kernel solution and development team doesn't want to, feel free to fork and do whatever you want.
Just to make it clear: I am not afraid of anything and I don't have to offer all options for people to be able to choose.
The reason is simple: I don't care about RT kernels at the moment, I don't want to waste my time on it and as a result I don't offer such a solution.
If anyone believes that Archphile or any other project should implement a RT kernel solution and development team doesn't want to, feel free to fork and do whatever you want.
Last edited:
Please don't take it negatively. IMHO, the freedom to customize is what makes an open system like Archphile an attractive proposition for more advanced DIYers. Perhaps it can revive interest by gaining followers of RT kernel fans?
I do not understand the statement
No idea what distractions mean.
How do you define efficiency? Power consumption? CPU load?
Do you have any charts, measurements?
Because extraordinary claims require extraordinary support. And that claim with RT kernel IS very extraordinary.
RT kernel improves maximum latency. For badly designed audio systems (those requiring low latency to actually avoid xruns) it can make a difference between OK and no-way. Of course it does.
No idea how less delay in serving interrupts (soft RT) improves noise or jitter or power consumption or CPU load. Do you have any audio output spectrum measurements to compare RT - nonRT?
Please support your claims here.
No idea what distractions mean.
How do you define efficiency? Power consumption? CPU load?
Do you have any charts, measurements?
Because extraordinary claims require extraordinary support. And that claim with RT kernel IS very extraordinary.
RT kernel improves maximum latency. For badly designed audio systems (those requiring low latency to actually avoid xruns) it can make a difference between OK and no-way. Of course it does.
No idea how less delay in serving interrupts (soft RT) improves noise or jitter or power consumption or CPU load. Do you have any audio output spectrum measurements to compare RT - nonRT?
Please support your claims here.
Hi sinski,
what do you want to do?
Did you read the release instructions?:
Download Archphile from SourceForge.net
In general you can see this section:
Archphile - A Linux Audiophile Distribution - How To
unless different procedures or information is given in release_notes_and_instructions.txt.
what do you want to do?
Did you read the release instructions?:
Download Archphile from SourceForge.net
In general you can see this section:
Archphile - A Linux Audiophile Distribution - How To
unless different procedures or information is given in release_notes_and_instructions.txt.
Hi tuxx,
sorry i didn't noticed release_notes_and_instructions.txt.
yes, it is running and the sound is indeed very good (pi3-digi+pro-i2s-buffalo dac).
I will try some underclocking and will try to run mpd on two cpus instead of one, on another pi player software i had the best sonic results (always subjective) with underclokcing and mpd running on 2 cpus.
Thanks for Your work
sorry i didn't noticed release_notes_and_instructions.txt.
yes, it is running and the sound is indeed very good (pi3-digi+pro-i2s-buffalo dac).
I will try some underclocking and will try to run mpd on two cpus instead of one, on another pi player software i had the best sonic results (always subjective) with underclokcing and mpd running on 2 cpus.
Thanks for Your work