Posts: 6,022
Threads: 176
Joined: Apr 2018
Reputation:
235
I'm not opposed to making them more accessible, whether they're called tweaks, options, tuning parameters, whatever. It's just *cough* more coding on *cough* someone's part
If anything can be changed, it will be changed. For sure, the Forum conversation will get "interesting".
Regards,
Kent
Posts: 397
Threads: 11
Joined: Sep 2018
Reputation:
31
After hearing the change in sound quality with 'Linux Audio Adjustments', I'm interested in exploring more.
Posts: 14
Threads: 0
Joined: Mar 2019
Reputation:
2
It would be very interesting the possibility of further adjustments to improve the performance of moode, as it happens in the players used in windows.
I use an RPi 3B + and also made the "Linux Audio Adjustments" in addition to changing the kernel to 64bit, processor priority and audio buffer to 8192kb, these are small changes that alone may not make a difference in the audio, but together I have obtained a great result in the sound , I am very satisfied.
I am hoping to receive an RPi4 (2GB) and I expect these changes to be more significant in this model.
I don't know if it is possible, but if the latency adjustment is affordable it will help to get a better result.
Posts: 397
Threads: 11
Joined: Sep 2018
Reputation:
31
07-20-2020, 04:27 AM
(This post was last modified: 07-20-2020, 06:20 AM by hifinet.)
IMO, FWIW, MPD 0.22~git (test) is brilliant. Wonderful sound. Reduction in distortion and proper image.
Addendum: Next logical step: add 'Linux Audio Adjustments'. This is probably better. Very resolving. Need to test with aggressive Mercury LP and large choral. Getting too late. Some occasional light tics, which were not there since the USB tweak. Maybe need to remove the network tweaks that aren't needed.
Posts: 75
Threads: 10
Joined: Jul 2020
Reputation:
6
(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.
You already have all the reasonable tweaks implemented. Output is bitperfect out of the box. I’m currently trying out these additional settings:
Code: /boot/cmdline.txt
isolcpus=2,3
/lib/systemd/system/mpd.service
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=70
Nice=-18
ExecStart=/usr/bin/taskset -c 2,3 /usr/local/bin/mpd --no-daemon $MPDCONF
/boot/config.txt
arm_freq=1000
sdram_freq=2000
core_freq=500
gpu_freq=500
over_voltage=-5
over_voltage_sdram=-5
gpu_mem=16
max_usb_current=1
force_turbo=1
initial_turbo=60
avoid_pwm_pll=1
There is some reason to the isolated cores, but the /boot/config.txt tweaks are really esoteric, and without test equipment to examine noise and timing on the output there is no way to ever find optimal values since there are simply too many variables and permutations to audition by ear.
I would not venture down this path on mere anecdotes from users. Users interested in this kind of tweaking will probably not be satisfied in a simple ‘Tweaks: On/Off’ button anyway.
What might in the future yield better sound could be the MPD memory play that they are working on, but then again maybe not.
Posts: 156
Threads: 6
Joined: Apr 2018
Reputation:
11
(07-20-2020, 04:27 AM)hifinet Wrote: IMO, FWIW, MPD 0.22~git (test) is brilliant. Wonderful sound. Reduction in distortion and proper image.
Addendum: Next logical step: add 'Linux Audio Adjustments'. This is probably better. Very resolving. Need to test with aggressive Mercury LP and large choral. Getting too late. Some occasional light tics, which were not there since the USB tweak. Maybe need to remove the network tweaks that aren't needed.
What distortion please?
I get no distortion through mo0de whatsoever using known well recorded sources I am very familiar with, no audible (to me) noise through the speakers when music is not playing & I crank the pre-amp up high, the SQ is absolutely crystal clear on the standard setup using 32bit kernel, default MPD.
I listen to music at low / moderate volumes.
I also listen to music away from moOde using a DAP & quite sensitive IEM's & the only "distortion" is usually as a result of clipping in badly recorded music. This is more obvious using the IEM's, in moOde on a speaker setup listening to the same source file it is less obvious (although I can still hear it) but is a problem with the source music not something a tweak can remedy, I am happy to be corrected though.
I am intrigued what you mean by distortion though.
Posts: 13,417
Threads: 304
Joined: Mar 2018
Reputation:
544
(07-20-2020, 11:19 AM)hestehandler 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.
You already have all the reasonable tweaks implemented. Output is bitperfect out of the box. I’m currently trying out these additional settings:
Code: /boot/cmdline.txt
isolcpus=2,3
/lib/systemd/system/mpd.service
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=70
Nice=-18
ExecStart=/usr/bin/taskset -c 2,3 /usr/local/bin/mpd --no-daemon $MPDCONF
/boot/config.txt
arm_freq=1000
sdram_freq=2000
core_freq=500
gpu_freq=500
over_voltage=-5
over_voltage_sdram=-5
gpu_mem=16
max_usb_current=1
force_turbo=1
initial_turbo=60
avoid_pwm_pll=1
There is some reason to the isolated cores, but the /boot/config.txt tweaks are really esoteric, and without test equipment to examine noise and timing on the output there is no way to ever find optimal values since there are simply too many variables and permutations to audition by ear.
I would not venture down this path on mere anecdotes from users. Users interested in this kind of tweaking will probably not be satisfied in a simple ‘Tweaks: On/Off’ button anyway.
What might in the future yield better sound could be the MPD memory play that they are working on, but then again maybe not.
Audio data is queued in memory buffers for play and so you are already enjoying "RAM play". Furthermore, Linux caches the entire file in RAM as part of its internal disk caching mechanism. If the file is played again and hasn't been expired out of the cache there is no disk I-O and the data is simply transferred to the audio player memory buffers.
The only bad thing that can happen is a buffer under run which if they occur indicates that something upstream is malfunctioning and not able to deliver the data in a timely manner.
For sure there has to be a good case made for including an option but let's see what comes up.
Posts: 75
Threads: 10
Joined: Jul 2020
Reputation:
6
07-20-2020, 12:45 PM
(This post was last modified: 07-20-2020, 12:46 PM by hestehandler.)
(07-20-2020, 11:57 AM)Tim Curtis Wrote: Audio data is queued in memory buffers for play and so you are already enjoying "RAM play". Furthermore, Linux caches the entire file in RAM as part of its internal disk caching mechanism. If the file is played again and hasn't been expired out of the cache there is no disk I-O and the data is simply transferred to the audio player memory buffers.
The only bad thing that can happen is a buffer under run which if they occur indicates that something upstream is malfunctioning and not able to deliver the data in a timely manner.
For sure there has to be a good case made for including an option but let's see what comes up.
I think the purpose is to load (and possibly decode) the entire encoded audio file into RAM before playback begins. That way network/disk activity can be inactive during playback, and that might yield better sounding playback.
Posts: 13,417
Threads: 304
Joined: Mar 2018
Reputation:
544
Yes I think "reduction of computer activity" is part of the thinking behind "RAM play". Reducing network activity though is at odds with players like LMS/Squeezelite, Roon HQPlayer and UPnP that are based on separating the Media Server/Decoder and Playback renderer by a network. In these cases there is always network I-O. moOde is same when the UI is being used over a network, radio is playing, any of the renderers being used, etc.
Posts: 397
Threads: 11
Joined: Sep 2018
Reputation:
31
grasshopper wrote:
Quote:What distortion please?
I get no distortion through mo0de whatsoever using known well recorded sources I am very familiar with, no audible (to me) noise through the speakers when music is not playing & I crank the pre-amp up high, the SQ is absolutely crystal clear on the standard setup using 32bit kernel, default MPD.
I listen to music at low / moderate volumes.
I also listen to music away from moOde using a DAP & quite sensitive IEM's & the only "distortion" is usually as a result of clipping in badly recorded music. This is more obvious using the IEM's, in moOde on a speaker setup listening to the same source file it is less obvious (although I can still hear it) but is a problem with the source music not something a tweak can remedy, I am happy to be corrected though.
I am intrigued what you mean by distortion though.
I understand what you are saying. Before changing to MPD 0.22, I described the sound as "excellent". But there were problems with certain recordings, specifically aggressive Mercury Living Presence (e.g. Bloch, Prokofiev Scythian Suite). These recordings are much better now. The best that I have heard them. I thought they were "bad recordings". They are very challenging recordings. Switching to another MPD is a bit of a chore, especially if you have a large library (due to rescan), but the result was very eye opening and rewarding for me. Why does MPD 0.22 sound so much better?
|