Page 2 of 8

Re: Tweaking the audio performance Rpi3

PostPosted: 09 Jan 2017, 22:12
by Discovery
Hi Rune Frost,

I'd like to try your changes however there are a few questions I'd like to ask first.

1. SOX Resampler Changes
You suggest changes to the active source in /etc/mpd.conf. I couldn't see any 'active source' in this file. It appears to specify outputs only. Can you clarify this please, perhaps with an extract of your file to show how the changes are entered?

2. Changes to /boot/bootcfg.txt
This filename doesn't exist in this subdirectory. I do recognise some of these values as present in /boot/cmdline.txt. Is this the file you mean?

3. Changes to /var/www/command/orion_optimize.sh
For your text starting * Common startup * it's unclear if your content replaces or appends to the existing content in this file. Please explain.

For the second text panel, starting 'ifconfig eth0 mtu 9000', does this also go in orion_optimize.sh? If so, at the end of the file?

Thanks in advance for your clarifications.

Re: Tweaking the audio performance Rpi3

PostPosted: 09 Jan 2017, 22:53
by Frost_dk
Discovery wrote:Hi Rune Frost,

I'd like to try your changes however there are a few questions I'd like to ask first.

1. SOX Resampler Changes
You suggest changes to the active source in /etc/mpd.conf. I couldn't see any 'active source' in this file. It appears to specify outputs only. Can you clarify this please, perhaps with an extract of your file to show how the changes are entered?

2. Changes to /boot/bootcfg.txt
This filename doesn't exist in this subdirectory. I do recognise some of these values as present in /boot/cmdline.txt. Is this the file you mean?

3. Changes to /var/www/command/orion_optimize.sh
For your text starting * Common startup * it's unclear if your content replaces or appends to the existing content in this file. Please explain.

For the second text panel, starting 'ifconfig eth0 mtu 9000', does this also go in orion_optimize.sh? If so, at the end of the file?

Thanks in advance for your clarifications.


Hi Discovery.

1. Here is the bottom part of my mpd.conf: Notice that one of the output "devices" has a line : enabled "yes". That is the active output.

Code: Select all
audio_output {
        name            "bcm2835 ALSA_1"
        type            "alsa"
        device          "hw:1,0"
        dsd_usb         "yes"
        auto_resample   "no"
        auto_format     "no"
}

audio_output {
        name            "USB Audio DAC"
        type            "alsa"
        device          "hw:0,0"
        dsd_usb         "yes"
        auto_resample   "no"
        auto_format     "no"
        format          "192000:16:2"
        samplerate_converter "soxr very high"
        enabled         "yes"

}

audio_output {
        name            "bcm2835 ALSA_2"
        type            "alsa"
        device          "hw:1,0"
        dsd_usb         "yes"
        auto_resample   "no"
        auto_format     "no"


Please remember that it is not always better to upscale. it depends on your DAC

2. You are quite right.. It is indeed cmdline.txt that must be changed. :)

3. Yes all the changes go into Orion_optimize.

This is my complete #common startup# section :
Code: Select all
##################
# common startup #
##################
#if [ "$PID" != null  ]; then
#echo "Set priority for: cifsd"
#renice -20 $PID
#fi
cifsprio pid=$(pidof cifsd)
echo "Set normal priority for: rune_SY_wrk"
renice 20 $(pgrep rune_SY_wrk)
echo "Set normal priority for: rune_PL_wrk"
renice 20 $(pgrep rune_PL_wrk)
echo "Set normal priority for: smbd"
renice 19 $(pidof smbd)
echo "Set normal priority for: nmbd"
renice 19 $(pidof nmbd)
#runeFrost
renice -10 -p 3
renice -10 -p 12
renice -10 -p 16
renice -10 -p 20


and the second change goes into an existing kernel optimization setting. I will recommend to put into the section for Orion_V2 profile. It is called MOD3 in the file

Here is my complete section for Orion_V2.

Code: Select all
# mod3
if [ "$1" == "OrionV2" ]; then
ifconfig eth0 mtu 9000
ifconfig wlan0 mtu 9000
ifconfig eth0 txqueuelen 4000
ifconfig wlan0 txqueuelen 4000
echo 0 > /proc/sys/vm/swappiness
modKschedLatency hw=$2 s01=120000 s02=2000000 s03=2000000 s04=2000000 s05=2000000 s06=2000000 s07=2000000 s08=2000000 s09=2000000 s10=2000000 u01=2 u02=2 u03=2 u04=2 u05=2 u06=2 u07=2 u08=2 u09=2 u10=2
#runeFrost
echo -n performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo -n performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
echo -n performance > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor
echo 1000000 > /proc/sys/kernel/sched_latency_ns
echo 100000 > /proc/sys/kernel/sched_min_granularity_ns
echo 25000 > /proc/sys/kernel/sched_wakeup_granularity_ns
echo 1 > /proc/sys/kernel/hung_task_check_count
echo 20 > /proc/sys/vm/stat_interval
echo -1 > /proc/sys/kernel/sched_rt_runtime_us
echo 5 > /proc/sys/vm/dirty_background_ratio

sleep 2
mpdprio_nice
echo "(OrionV2) sound signature profile"
fi


Please remember to activate the Orion_V2 kernel profile under the settings page.


Here is a link to how to isolate a single core :
http://www.runeaudio.com/forum/the-new-4-core-raspberry-pi-t862-40.html

and this is how to enable nightly builds:
http://www.runeaudio.com/documentation/troubleshooting/updating/
As mentioned before.. The nightly builds has to be enabled and updated to enable the kernel optimizations.

I hope this clarifies it a bit :)..Im not used to write "guides" and especially not in English :lol:

Kind regards,
Rune Frost

Re: Tweaking the audio performance Rpi3

PostPosted: 09 Jan 2017, 22:56
by Frost_dk
s.k. wrote:Hi ,
Thanks for sharing !

Are those tweaks suitable for the raspberry 2 ?
If yes, is it possible to describe them in a more simple/detail (noobproof :shock: ) way ?

regards


Hi s.k
This is done on a Rpi3, but perhaps it can make the rpi2 "sing" as well, IF you skip the parts about isolating a core and bind MPD to it.
I think that the underclocking / under voltages should work with a Rpi2 as well.

If you try, then please report back if it works :D

Kind regards ,
Rune Frost

Re: Tweaking the audio performance Rpi3

PostPosted: 09 Jan 2017, 23:43
by hondagx35
Hi Frost,

IF you skip the parts about isolating a core and bind MPD to it.

Why? It is also a quad core processor.

Frank

Re: Tweaking the audio performance Rpi3

PostPosted: 10 Jan 2017, 00:55
by Discovery
Hi Rune Frost,

Finally completed the changes...

Just before I tell you the results, many thanks for the clarifications. The only thing that held me up was the Chattr commands - there needs to be a space after the -i and +i parameter for it to work and I didn't see it at first, i.e. 'chattr -i /etc/mpd.conf'. I'm so new to Linux I can only just spell it but it just didn't look right to me. However, a bit of experimenting sorted it. Many thanks for your efforts, especially in English. :-)

I have an RPi2 that is set up for RuneAudio so I tested the modified RPi3 against this as a standard reference. The RPi2 has a HifiBerry Digi card outputting to my DAC on an optical link. This was changed to the 'Orion V2' profile so all parameters were exactly matched. The RPi3 is using the DAC's USB port on my DAC. My RPi3 (as you probably know) has fboe's voltage mods so already sounded better.

So, the results...

Playing the same track on both Pis and flipping between them the change is now so much more evident. I didn't need to play more than a few seconds of each player to hear the difference - on any track. The sound is much more open and detailed. Or, to put it another way, it's like the difference between hearing a hifi system from outside the room, then stepping into the room and sitting down in front of the speakers. This is the best value change I've implemented so far! :-)

It's late here (as you're an hour ahead I expect you've already gone to bed) so I'll listen more tomorrow night but it is a great improvement! Well done - keep the ideas coming! :lol:

Kind regards,

Trevor

Re: Tweaking the audio performance Rpi3

PostPosted: 10 Jan 2017, 01:03
by Discovery
Rune Frost,

With your greater Linux skills, I have another challenge for you... ;-)

There is mention in another thread of brutefir, which has been enabled on a Pi and allows room equalisation changes to be implemented. If you can work out how to get that configured, I'd be very grateful! :-)

The thread that mentions it is here: rune-audio-and-brutefir-convolver-for-roomcorrection-t1094.html#p6418

I already have a MiniDSP UMIK-1 microphone, needed to make the room measurements in REW or similar. If you can get brutefir working, I'd be happy to lend you my microphone so you can build your own room configuration files.

Regards,

Trevor

Re: Tweaking the audio performance Rpi3

PostPosted: 10 Jan 2017, 13:00
by Frost_dk
hondagx35 wrote:Hi Frost,

IF you skip the parts about isolating a core and bind MPD to it.

Why? It is also a quad core processor.

Frank


Haha you are quite right.. I was a bit too fast when I responded.

The only thing I can think of, that could be a problem is if the Rpi2 ARM cant handle the low voltage settings with this frequency setting.

Re: Tweaking the audio performance Rpi3

PostPosted: 10 Jan 2017, 13:33
by Discovery
Hi Frank,

I hope you are well. You continue to do a great job supporting us all here and it's only appropriate to remind you from time to time. :-)

I notice your involvement in this thread, and I feel that you are also interested in the endless pursuit of ultimate sound quality so may have even tried this for yourself.

If you were to agree that this was a positive and worthwhile improvement, could it be packaged up as an 'alternative' build, perhaps? This might be an easier way to share the benefits with a wider audience who don't want to learn about SSH, Nano, and the stringent demands of unforgiving syntax...!

My only caveat is that I am unaware what the changes sound like without fboe's voltage mods so I can't comment on exactly what it would sound like on a standard RPi3. However, I know it increased the improvement on mine so I have no doubt that there is benefit of its own.

For those interested in fboe's first modification (3x-powersupply-for-rpi-t4141.html) - to feed the 5v power to GPIO pins 2 and 6 instead of using the standard micro-USB port - this is very easy to achieve with a suitable cheap cable, e.g. https://www.modmypi.com/raspberry-pi/gp ... spberry-pi and a suitable USB adapter, e.g. http://www.dx.com/p/usb-female-to-micro ... HTWe1OLRhE. This resulted in an immediate improvement in sound quality.

Kind regards,

Trevor

Re: Tweaking the audio performance Rpi3

PostPosted: 10 Jan 2017, 14:10
by Yatsushiro
Discovery wrote:For those interested in fboe's first modification (3x-powersupply-for-rpi-t4141.html) - to feed the 5v power to GPIO pins 2 and 6 instead of using the standard micro-USB port - this is very easy to achieve ...


Less easy to achieve, but not impossible, if you're using a HAT DAC which doesn't 'relay' the GPIO pins.

If you use a KALI reclocker, with the option to power the Pi via the appropriate jumper setting, you will get a similar benefit, as well as jitter reduction.

Re: Tweaking the audio performance Rpi3

PostPosted: 10 Jan 2017, 14:41
by Discovery
There you go - the Kali reclocker sounds like a great approach if you are using an I2S approach. For value for money, this looks a great way to go. :-)

I use an external DAC so take a different route. My connection to the DAC is an asynchronous USB connection. This approach uses the high-quality DAC clock as the master to control and regulate the interface from the Pi as the slave device (topping up the DAC's FIFO buffer as required), so jitter is much less of a concern.