extra lines in config.txt to lower memory and cpu clock speeds makes positive additions too. Running CPU at Realtime priority too.
more details please
which extra lines in config.txt ? how to run CPU in RT priority ?
Tweaking config.txt in MoOde 4.0 to reduce CPU and memory and running real time CPU
Add these lines to the config.txt file after what is already there to restrict speed:
arm_freq=800
sdram_freq=400
core_freq=400
gpu_freq=300
over_voltage=-4 or -2
over_voltage_sdram=-4 or -2 if showing problems
gpu_mem=16
setting process to realtime priority seems to sound better to do,
ssh to the pi then run these lines (I always just copy and paste):
sudo nano /lib/systemd/system/mpd.service
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=99
Nice=-20
exit and save then run these lines
sudo systemctl daemon-reload
sudo systemctl restart mpd
see how it sounds after that
more details please
which extra lines in config.txt ? how to run CPU in RT priority ?
Add these lines to the config.txt file after what is already there to restrict speed:
arm_freq=800
sdram_freq=400
core_freq=400
gpu_freq=300
over_voltage=-4 or -2
over_voltage_sdram=-4 or -2 if showing problems
gpu_mem=16
setting process to realtime priority seems to sound better to do,
ssh to the pi then run these lines (I always just copy and paste):
sudo nano /lib/systemd/system/mpd.service
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=99
Nice=-20
exit and save then run these lines
sudo systemctl daemon-reload
sudo systemctl restart mpd
see how it sounds after that
Hi, Rod.
I should have mentioned that early in the new era of building from script, I made a similar offer and then backed away from it when I was apprised of the potential consequences. We learn from our mistakes! Only after the fact did I start doing my homework. The entire FOSS ecosystem seems to be remarkably rickety when it comes to licenses. Compliance is in the eye of the license holder, not the licensee, and an aggrieved license holder can make life very difficult.
On the audio front, I'm sure others are following your tweaking adventures. These days with my ancient ears I'm lucky to be able to still enjoy the music, and moOde has made that dead easy
Regards,
Kent
@aep600
I'm not sure I'm following the sequence of events here. I'm going to make a wild stab that "when the configuration changes" refers to when you tell mosbuild.sh you want to use a WiFi connection during the build.
You can edit mosbuild.sh manually (using nano or vi/vim for example) before you execute it to change the default Country Code from "GB" to "US" (or whatever the appropriate County Code is for the build). Around line 464, you should find the following
Code:
echo "country=GB" > part1/wpa_supplicant.confRegards,
Kent
Last edited:
I forgot to mention that this Country Code business is a transitory problem. Tim is amending mosbuild.sh and moOde to deal with it.
Regards,
Kent
In my tests, the new 3B+, Stretch and Wifi country = GB resulted in not being able to see my 5GHz SSID. Switching to country = US and then 5GHz SSID shows up.
I don't know whether the reverse will happen outside the US. In other words if country code = US then will European 5GHz wifi band not show up?
At least 2.4 GHZ will be ok, and its better than the experience with stock Raspbian where the Wifi adapter is blocked completely until a country code is entered using raspy-config :-0
Add these lines to the config.txt file after what is already there to restrict speed:
arm_freq=800
sdram_freq=400
core_freq=400
gpu_freq=300
over_voltage=-4 or -2
over_voltage_sdram=-4 or -2 if showing problems
gpu_mem=16
setting process to realtime priority seems to sound better to do,
ssh to the pi then run these lines (I always just copy and paste):
sudo nano /lib/systemd/system/mpd.service
CPUSchedulingPolicy=fifo
CPUSchedulingPriority=99
Nice=-20
exit and save then run these lines
sudo systemctl daemon-reload
sudo systemctl restart mpd
see how it sounds after that
thx
i will try and report
There are different broadcast power levels allowed in different countries, this link is old-ish but probably still relevant.
Maximum wifi transmission power per country | Wolph
I think you should find "coverart.php" file in the var/www folder, and vi it in the "// image search priority" part. I changed priority to mode 0, and the "stoled cover art" disappered after reboot.
As far as I'm aware non of the config.txt tweaks offer under sampling they simply run the processor and memory at a reduced rate for lower noise, this is the logic. It seems to work on my system, the results are blacker gaps between notes (if you know what I mean) and more definition.
I suppose it's akin to running your engine at a reduced rate instead of flat out, someone will come up with a better analogy I'm sure. Give it a go and report your findings if you like.
Someone did the same approach on a RP2/3 and basically underclock the processor to get better music. Search the earlier posts.
Yep, where did you think I got the idea from, can't remember the guy who posted it, or even if it was on this forum, but he was right about slowing the Pi3 down gives better audio results I always use his tweaked config.txt settings now. It was all about noise in the pathways and reducing levels.
BTW I use max SOX oversampling rates into my Mojo - this seems to get best results and the Pi never misses a beat at the lower cpu setting of 800mhz. Trying the B+ now to see if it behaves as the B in this respect, so far it hasn't glitched or dropped out all day.
I'm looking forward to others trying the slowing down approach to see their results.
Note that the US power limit in the 2.4GHz band is ten times the GB limit ( a full 10dBm). On the other hand, the US limits 802.11g/n operation to WLAN channels 1-11.
I suspect but can't prove that it is differences like these between the world's regulatory domains which moved the Raspberry Pi Foundation explicitly to introduce Country Code setting in the lastest raspbian.
All that aside, the RPi3B+ wifi performance is very nice. See, for example, Raspberry Pi 3 Model B+ WiFi Performance - Phoronix and the article "Benchmarking the Pi 3B+" in MagPi issue 68, MagPi 68: an in-depth look at the new Raspberry Pi 3B+ - Raspberry Pi
I'm loving mine at 5GHz (thankfully the ISP-provided router/AP supports 5GHz decently).
Regards,
Kent
It probably came partly from here: Archimago's Musings: MEASUREMENTS: Raspberry Pi 3 as USB Audio Streamer (with recommended CRAAP config & TIDAL/MQA arrives)
Scroll down to 'Conclusions'
Spot on jonners, that's the article
This is the guy, knows what he is talking about from my experience. :wiz
Well worth a read to anyone wanting to get better performance.
It seems that the kernel driver for the DigiOne/WM8805 is packing the 24 bits of PCM into a 32 bit stream. This is quite common. If you want to query this, you will probably need to talk to Allo.
It is decoding to PCM because the WM8805 will not pass a native DSD stream over SPDIF (I'm not sure anything will but happy to be corrected), so MPD is falling back to converting the audio to PCM. MPD is doing this based on what the kernel driver says the DigiOne can accept.
As per the MPD page linked by Tim, the DSD stream is being packaged into a PCM stream (DoP=DSD over PCM). This allows the DSD to be smuggled over the SPDIF output of the DigiOne to a compatible DAC. I take it that your DAC is able to extract the DoP data? It must be if this is working.
These values are based on what the kernel driver reports to MPD as the capabilities of the device and how particular data streams need to be packaged. I'm not sure how to manually adjust these values without writing your own version of the driver.
I believe the values quoted are the formats that MPD is outputting to the DigiOne. The DigiOne should only be able to output what is compliant with the SPDIF specification: max 24 bit 192 kHz LPCM or surround streams such as DTS, Dolby Digital.
Cheers,
Richard