![]() |
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 - Tim Curtis - 07-21-2020 In moodeutl -m you might see RAM_USED% increase a bit as song files in the Playlist are added to the cache by the MPD algorithm. It will be interesting to see how it works in practice. RE: Sound Tweak Rpi4 - DRONE7 - 07-21-2020 I have created and used a ramdisk for playback in the past but abandoned it as being too clunky (had to load files via cli) and of little audible improvement. However, the input cache option for MPD appears far more friendly and given how little ram a Pi4 uses then a useful amount could be allocated to cache :-) I have to agree that MPD 0.22 is a winner and I'm looking forward to see if the cache option will be noticeable with it. Bob. RE: Sound Tweak Rpi4 - Tim Curtis - 07-21-2020 You can try it out yourself with 0.22~git (wait till it rebuilds the database after switching to it) sudo nano /etc/mpd.conf add this input block input_cache { size "1 GB" } then sudo systemctl restart mpd RE: Sound Tweak Rpi4 - efung - 07-21-2020 (07-20-2020, 11:01 PM)hifinet Wrote: I probably understated the improvement with MPD 0.22. It's massive. I've also been listening with the Linux Audio Adjustments added to MPD 0.22, and it's very similar to too much feedback in an amplifier. Less distortion, but the soundstage is severely reduced and overly compressed. I think it could use a bit more of the feedback effect (whatever might be responsible), but it's better without it for most music. It would be very beneficial if there were a way to dial in that effect, like you can with feedback. Another possibility is that one or more audio amplifiers in the chain have too much feedback, and reducing distortion in the DAC process exposes it. Yes, I agree that MPD v0.22 improves the resolution on the treble. But, it is not massive on my PCM5122 + onboard DC coupled headphone amp. FYI, the sonic signature of my headphone amp matches that of TEAC HA-501. I always set the output of the PCM5122 to -6dB gain to avoid clipping due to aggressive recording. This is the known issue of the DAC chip. Nevertheless, I am happy to use SoX upsampling to 32bit/352.8Ksamples/s. There is no timing issue without the Linux Audio Adjustments. My RPi4B-1G is hooked up to Ethernet because WiFi signals is weak here. I am using Beyerdynamic T1 2nd generation headphone for this audition. The stock headphone cable is 3m long 7N OCC copper cable. RE: Sound Tweak Rpi4 - swizzle - 07-21-2020 (07-20-2020, 11:27 PM)Tim Curtis Wrote:(07-20-2020, 07:01 PM)swizzle Wrote:(07-19-2020, 09:16 PM)Tim Curtis Wrote: Not "advanced tweaks" but "reasonable set of options". There's some things already in moOde for "tuning and experimenting" including the cpu governor, 32/64 bit kernel and mpd git compiles. Maybe thats enough but it would be interesting to hear what people think would be useful and most importantly why. Ideally latency would be zero but unlike the kernel we don’t know how much of a difference the tweaks actually make. Of course audiophiles chase the last 1% like it owes them money so tweaks act as a bit of a busy box to poke at as @TheOldPresbyope said. I do think the 64-bit kernel and .22 mpd sound better though. :p The @bitlab patches were the even multiples resampling? That sounded cool and is more audiophile catnip. Maybe roll them into the experimental mpd version so there’s a stable vanilla version people can fall back to in case an edge case rears its ugly head. RE: Sound Tweak Rpi4 - Tim Curtis - 07-21-2020 lol, ideally there would need to be proof that there is some sort of "latency" issue to begin with that affects audio in the OS b4 we get to remedies otherwise its just mythological stuff. Anyway, the @bitlab enhancements evolved into a set of really cool auto-resampling ideas for example (1) resample 44.1K to the selected rate but leave all higher bitrate files as-is, (2) resample files to their respective integer or fractional rate that is <= to the selected rate, (3) resample fractional rate files to a selected fractional rate and resample integer rate files to a selected integer rate. Doing this requires patches to stock MPD that @bitlab would need to maintain on behalf of the moOde project unless the MPD maintainer accepted the patches into the MPD source tree and so far attempts at getting any enhanced resampling options accepted have been rejected :-( RE: Sound Tweak Rpi4 - hifinet - 07-21-2020 efung wrote: Quote: Nevertheless, I am happy to use SoX upsampling to 32bit/352.8Ksamples/s. You should try 32/384 VHQ multithread. Much better. Disables 5122 resampling. RE: Sound Tweak Rpi4 - DRONE7 - 07-21-2020 (07-21-2020, 01:35 AM)Tim Curtis Wrote: You can try it out yourself with 0.22~git (wait till it rebuilds the database after switching to it) I've been using 0.22~git as default anyway so no regen needed. Currently I'm using XMOS USB to i2s to hardware resampler (everything is resampled to DSD256) and an ES9028 DAC and I've just replaced the pwr xformer to the XMOS with a USB battery bank (Major xformer death causing this) so I have many variables to assimilate and compare. RE: Sound Tweak Rpi4 - philrandal - 07-21-2020 I've just fixed the typos in my version of the Linux-Audio_adjustments basic-install.sh. It helps if you escape $ signs! My bad! https://github.com/philrandal/Linux-Audio-Adjustments/ Finding it difficult to objectively test any differences, though. RE: Sound Tweak Rpi4 - TheOldPresbyope - 07-21-2020 (07-21-2020, 11:40 AM)philrandal Wrote: ... Our ear/brain combo is as subjective as anything can get. This isn't like the LinuxCNC and machinekit projects I participated in. You could objectively test that a finished part didn't meet spec. Fortunately for me, I've already reached my personal sweet spot with moOde. I may tease about tweaks but I understand the desire. Always looking forward to the next post. Regards, Kent |