Sound Tweak Rpi4

[Tim Curtis]

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.

[DRONE7]

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.

[Tim Curtis]

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

[efung]

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.

[swizzle]

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.

Most of the tweaks were essentially to reduce latency but the 64-bit kernel already does that to a greater degree. They might still have some merit especially on 32-bit.

Kind of related (tweaks is tweaks, right?) if mpd ever implements Sox recipes that could be a cool addition but it’s a really old entry so don’t hold your breath. 

https://archimago.blogspot.com/2018/01/m...s.html?m=1

https://github.com/MusicPlayerDaemon/MPD/issues/122

ETA with the play from ram talk that reminds me of the new input_cache directive.

https://www.musicpd.org/doc/html/user.ht...nput-cache

Is there really a latency issue ;-)

@bitlab has some nice patches for MPD that improve the sample rate options that could be offered in moOde. I normally stick with stock MPD and don't do any patches but these could be very useful and so on the TODO list :-)

Ya, the input_cache option works well in 0.22-git. I'll definitely include it for robustness.

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.

[Tim Curtis]

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 :-(

[hifinet]

efung wrote:

 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.

[DRONE7]

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

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.

[philrandal]

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.

[TheOldPresbyope]

...

Finding it difficult to objectively test any differences, though.

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