Followed your directions. Tried to be clever and do too many things at once and finally just did this before anything else and just this. Now all good.
Thank you Dynobot.
Just FYI, on the kernel adjustments you suggested I found that the system would hang after 10 minutes. I commented the lines out for the first core, but left the other lines alone, and so far so good.
After I got the static wireless up, I uncommented the line on removing the power management off wifi but the other lines I left alone.
I also tried increasing the audio buffer and I actually think it did not sound as good, so I went the other way and took it down to 2048.
Thanks for the help on the wireless issue - much appreciated.
Dynobot,
I followed the advise on your website and installed Dietpi with MPD...just did some minor tweaks....YES...this is it for me. Much more cohorent and vibrant. As I want to respect the forum rules, and my path is now no longer with archphile, I will ask my questions in the fifopi thread where a few dietpi users seem to be around (did not find a dietpi thread):
IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...
I followed the advise on your website and installed Dietpi with MPD...just did some minor tweaks....YES...this is it for me. Much more cohorent and vibrant. As I want to respect the forum rules, and my path is now no longer with archphile, I will ask my questions in the fifopi thread where a few dietpi users seem to be around (did not find a dietpi thread):
IanCanada's Latest RPi GB Goodies Impressions... and your tweaks, mods and hints...
Hi Jose
Great you got the wifi working.
As far as the sound, go into the archphile-optimize file located in /usr/bin
nano /usr/bin/archphile-optimize
comment out the link that gives MPD [or what ever player you are using] affinity to a single core. This is not needed on a Rpi.
#taskset -c -a -p 1 $(pidof mpd)
Also you can go into the archphile-network.conf file to give it a little better network latency settings
nano /etc/sysctl.d/archphile-network.conf
replace the 8-digit values for rmem and wmem with these 8-digits. you should see a total of 4 lines at the top [2 each]
rmem_max=16777216
wmem_max=16777216
While you're at it, might as well add values to the limits.conf file. Add at the bottom before the 'End of file' line
nano /etc/security/limits.conf
@audio - rtprio 99
@audio - memlock 512000
# End of file
Okay I think I have Archphile all tuned up.
only thing is for some reason this directory contains different info on different Rpi's
/sys/block/mmcblk0/queue/iosched
I made a script that updates everything and moves the original files to 'backup' which can be restored to their original place when the tunings are removed.
If anyone wants to try it just let me know...first I will have to know what your 'iosched' directory has in it so I can tell you what to replace that value with in the script.
Either way, worse come to worse just uninstall and you're back to stock.
only thing is for some reason this directory contains different info on different Rpi's
/sys/block/mmcblk0/queue/iosched
I made a script that updates everything and moves the original files to 'backup' which can be restored to their original place when the tunings are removed.
If anyone wants to try it just let me know...first I will have to know what your 'iosched' directory has in it so I can tell you what to replace that value with in the script.
Either way, worse come to worse just uninstall and you're back to stock.
Hi Blitz
Here is the link for dietpi
GitHub - dynobot/Linux-Audio-Adjustments: Audio Tweaks for Debian Based RPi
Here is the link for Archphile
NOTE: you will need to post the result of that iosched file I mentioned so you can update the archphile-optimize file after you run the script
It should have either fifo_batch or low_latency in the directory. Just go into the archphile-optimize file and replace the value with what your RPi has...
# Tuning I/O scheduler
echo 1 > /sys/block/mmcblk0/queue/iosched/low_latency <-----replace that last part with what your RPi is showing
GitHub - dynobot/Arch-Linux-Audio-RPi at archphile-alpha
Last edited:
I know it is a radical idea, but there is actually something called double blind tests. They are a pretty good way to eliminate bias...
Here goes...for my set up only...fully sighted...
I was intrigued by the hypothesis that taking out core affinity would improve the sound. I found and commented out the line you refer to, and rebooted
#taskset -c -a -p 1 $(pidof mpd)
listened using a simple guitar track, Cavatina from the album "Portrait of John Williams" only because I know it well and I can stand repeats of it.
result? sound took on a more "rounded" character...possibly less leading edge, and fuller tone, tad less ambient information
went back into archphile and took out the # to activate the line again
result? more leading edge, possibly better microdynamics, possibly better definition of what was going on, and possibly clearer delineation of acoustic space of recording...but a tad more glare. I thought gee this might lead to a different reaction over the the long term
repeat 2x over the course of the day...seems to be repeatable
Then did something silly to confuse me and everyone...looked at your website and looped the dc cable of my keces PS cable around a ferrite core and did the above again.
result...less glare now but the configuration with core affinity assignment still seemed to be better for the same reasons, except it was a bit less leading edge and glary
please take all this for what it is, not DBT, simply my personal findings of a few repeats over a day
My set up:
rpi3b+ with pi2design 502DAC HAT used as an AES/EBU transport
powering the stack via the HAT with a keces PS
2TB USB HDD powered via 5V battery supply to the pi
simple ratshack dc cable
using MALP on android
then to AES input of minidsp etc etc to lxmini
archphile settings deviation from standard are:
mpd-archphile-minimal
mixer_type = "software"
audio_buffer_size = "2048"
iwconfig wlan0 power off
took out avahifi and took out mympd
my latency settings below because my set up kept on dropping out if i left latency tweak on core 0
#Reduce Audio thread latency
#chrt -f -p 54 $(pgrep ksoftirqd/0)
chrt -f -p 54 $(pgrep ksoftirqd/1)
chrt -f -p 54 $(pgrep ksoftirqd/2)
chrt -f -p 54 $(pgrep ksoftirqd/3)
might try other tweaks through the week. if this causes grief to those who are mortally wounded by subjective impressions, I can PM Dynobot for further feedback - if that's OK with him
GREAT!
Thank you that's what I needed to know.....
Yes PM me if you like.
BTW, if you are curious as to the "theory" behind all of this look up and read white papers from RedHat, IBM, Oracle, and Linux Pro Audio.....its all there. PS...it took me years.
Even that silly thing with the ferrite core....you can Google 'how does a ferrite core reduce noise' you will get tons of answers.
Ferrite Core Education YouTube Video
Last edited:
I would love a pointer to a white paper by Oracle or IBM about how operating system level latency affects the actual audio.
Bias is natural, I like bias....
When a 60yr old man looks at his wife of 40years and smiles....its 40yrs of bias thats causing this.
As long as my bias makes me happy I'm cool with it, I know I have it and I admit it.
Another example of normal bias.
John goes to a Soccer game to watch his kid play, after the game
John: You did great Jimmy, now lets go have some ice cream! <----- Bias
John: You know, you kinda suck Jimmy....maybe you should walk home <----- Truth
Last edited:
You know, the easiest thing in the world to do is to be a critic.
Even the lazy bum who sits on the corner all day with his hand out can criticize all day and doubt.
In my 2 seconds of search via Google I found a few, you have your hand out begging for something.
Here I will give you a crumb, but you must work for the rest.
Low-latency audio processing using off-the-shelf systems
Linux on Power - low latency tuning - Power developer portal
Did you watch the video on the silly ferrite core ? You act like you want to know the truth, move towards it...first step watch the video and do a Google search about Ferrite cores, learn why they exist and why they are used. Or, you can sit, do nothing and hold your hand out.
We were just asking you to validate your claim about the existence of white papers from IBM and Oracle about changing digital audio quality by tuning latency. That is a purely objective issue.
Nobody is questioning the fact that ferrites reduce noise. Physics tells us that they should work, and when applied in the right places the effect is easily measured.