![]() |
Sound Tweak Rpi4 - Printable Version +- Moode Forum (https://moodeaudio.org/forum) +-- Forum: Audiophile (https://moodeaudio.org/forum/forumdisplay.php?fid=32) +--- Forum: Sound quality (https://moodeaudio.org/forum/forumdisplay.php?fid=34) +--- Thread: Sound Tweak Rpi4 (/showthread.php?tid=2774) |
RE: Sound Tweak Rpi4 - philrandal - 07-15-2020 (07-15-2020, 06:30 PM)hifinet Wrote: https://github.com/philrandal/Linux-Audio-Adjustments Oops, I'd forgotten to apply those changes to my own two Moode players which I'd rebuilt for 6.6. Phil RE: Sound Tweak Rpi4 - grasshopper - 07-16-2020 (07-15-2020, 07:20 AM)largo Wrote:(07-15-2020, 12:12 AM)hifinet Wrote:(07-14-2020, 04:14 PM)largo Wrote: Hello, More clarity & detail from using the 64bit kernel? I admit I have never tried the 64bit kernel in moOde on the basis that even with that kernel, the userland remains 32bit, so I am surprised there is any change to the sound. Can you expand on what you mean by clarity & details please? RE: Sound Tweak Rpi4 - swizzle - 07-16-2020 My two cents... The 64-bit kernel allows kernel tasks to be preempted which allows for much lower latency. This is basically what the 3.x “real time” kernel options did. Note that mpd is still a little squirrelly with the 64-bit kernel but switching over once your setup is finished should be fine. The other tweaks... I used to be a believer but haven’t bothered lately. If you feel like it makes a positive difference then that’s what matters. RE: Sound Tweak Rpi4 - Tim Curtis - 07-17-2020 The cmds below print which preempt options were selected to build the kernel Code: sudo modprobe configs This article explains the options https://www.codeblueprint.co.uk/2019/12/23/linux-preemption-latency-throughput.html RE: Sound Tweak Rpi4 - TheOldPresbyope - 07-17-2020 And my three cents... 1/ The TCP and UDP throughput experiments in the referenced article are a poor proxy for what we really want to know: are the data samples delivered in sufficient time for the DAC to process without introducing additional audible artifacts? I say additional because a DAC always introduces artifacts. That's why some of us dote on the curves posted, for example, in audiosciencereview.com. Delivering individual samples in sufficient time is different from sample throughput. Think of cars on a highway: asking how many cars pass a checkpoint in an hour is different from asking how uniformly spaced the cars are when they pass. The working definition of "real time" in the software industry. is: can the required function be completed within the required time interval? The MPD docs contain an interesting comment regarding this point: Quote:Note There is a rumor that real-time scheduling improves audio quality. That is not true. All it does is reduce the probability of skipping (audio buffer xruns) when the computer is under heavy load. 2/ The referenced article explored the effect of a set of kernel-build parameters, not the difference between a 32-bit kernel and a 64-bit kernel. Where's the data comparing the two kernels as well as the three parameters? Where's the data comparing the 5.4.x kernel against the 4.19.x kernel? (That was my life as an experimental physicist/engineer. There's always another experiment to be done.) For that matter, where's the counterpart data for the PREEMPT_RT parameter setting? The article promises it in the comments but the answer is MIA. As well, If setting CONFIG_PREEMPT is an unalloyed good, then one has to wonder why the "official" 32-bit Raspbian kernel isn't built with it set? I suspect the maintainers themselves are in disagreement over the choices. 3/ There's a reason the 64-bit kernel is still not part of the Raspberry Pi OS release and hence is still a testing option in moOde. Look at the relevant github repos and forums. Subtle gotchas are still being worked out in the kernel modules, the drivers, the interface between kernel space and userland. Tim's code is hostage to the entire userland and kernel space stack. I suspect it will be some time yet before the dust has settled on the kernel space code. Then's there's the coming conversion of the userland code in Raspberry Pi OS to 64-bit. That'll be exciting! Bottom line on the 64-bit kernel: Try it. It's free. You might like it. You might not. You might even not notice you switched. Just don't hit Tim over the head with it! Regards, Kent RE: Sound Tweak Rpi4 - Tim Curtis - 07-17-2020 What would be nice is to see a time stamped trace of sample frames within the OS showing some that sort of timing issue, frame loss, etc actually exists. Then it could be analyzed to see what's causing the problem. Anyway, my point in posting about latency is to provide info from an engineers point of view which leans heavily on testing and analysis :-) The 32 bit kernels are compiled with CONFIG_PREEMPT_VOLUNTARY=y Code: pi@rp3:~ $ uname -a The 64-bit kernels are compiled with CONFIG_PREEMPT=y Code: pi@rp3:~ $ uname -a RE: Sound Tweak Rpi4 - hestehandler - 07-17-2020 To get anywhere on this topic there would need to be ABX testing performed of two similar Raspberries, both feeding a DAC that can cater two inputs, then double-blind and randomised audition one unmodified Pi against the other Pi with modified parameters. Anything else is confirmation bias, wishful thinking, and placebo. RE: Sound Tweak Rpi4 - Tim Curtis - 07-17-2020 Sure you could do listening tests but that not going to tell you whether the audio sample frames traveling within the OS are undergoing some sort of timing or data corruption, and if they are then what's causing it. RE: Sound Tweak Rpi4 - TheOldPresbyope - 07-17-2020 (07-17-2020, 12:59 PM)hestehandler Wrote: To get anywhere on this topic there would need to be ABX testing performed of two similar Raspberries, both feeding a DAC that can cater two inputs, then double-blind and randomised audition one unmodified Pi against the other Pi with modified parameters. Anything else is confirmation bias, wishful thinking, and placebo. I used to believe that. More accurately, I still believe it but I no longer believe that publishing the results of such work will automatically convince others. Sometimes even the people who participated in the trial disagree vehemently with the conclusions drawn from it. We're all human. Still, the numbers have to come first for me. Tim Curtis Wrote:What would be nice is to see a time stamped trace of sample frames within the OS showing some that sort of timing issue, frame loss, etc actually exists. Then it could be analyzed to see what's causing the problem. Should be obvious I agree. Regards, Kent RE: Sound Tweak Rpi4 - hestehandler - 07-17-2020 (07-17-2020, 01:14 PM)TheOldPresbyope Wrote: I used to believe that. More accurately, I still believe it but I no longer believe that publishing the results of such work will automatically convince others. Sometimes even the people who participated in the trial disagree vehemently with the conclusions drawn from it. We're all human.I know the type. These people can not be helped by reason, so there is no sense in trying. However there are those of up that are audiophiles, but not audiofools. |