After the positive experiences with ArchLinux today I played around a little bit with raspian latest:
2014-01-07-wheezy-raspbian.img
Don’t know, why they don’t deliver linux-headers for their kernel. So I installed this one:
uname -a
Linux raspberrypi 3.10-3-rpi #1 Debian 3.10.11-1+rpi3 (2014-01-01) armv6l GNU/Linux
Then I compiled the module for HiFace1. And:
No pops etc. until 96/24. 192/24 - sometimes clean, somtimes a few glitches…
A few more tweaks:
/etc/fstab:
tmpfs /var/log tmpfs defaults,noatime 0 0
removed a few services:
I tried also RT with PI, but this doesn’t help at all… It worsened a lot the things for me.
The real deal is finding the correct wsize and rsize for your very own network. Plus correclty setting the hardware mixer.
With the Raspberry PI the real weak point is the USB ethernet BUS, so disabling services has a relatively small impact on glitches. What you can do is avoid to overstress the usage of USB and Ethernet.
I advise you also to tinker a little with niceness, what youre looking for is alsa process, mpd and cifs. Find the right combination for you, but avoid giving mpd RT priority, try to give higher priority to CIFS service instead.
Let me know
USB and Ethernet are shared, so it is the same if you use USB and USB with DAC.
Yeah the problem is relevant especially with Async-DACs at hi-res.
I also think that reducing SD writes is a step forward, what did you manage? I also implemented logging to RAM, but got to recreate the files everytime… Did you came up with something more sensible?
I don’t save the logs. Relevant things I can see within one session. And informations while booting are shown with dmesg.
Pehaps I’m wrong: But my opinion is at the moment, that indeed reducing operations on the USB-BUS (Network, HDs, DACs) is a good thing. A simple ssh-connection may increase the chance for pops etc. And unfortunately a Webserver (rpi) + Browser (client) may produce more network-traffic than a client like gmpc, who talks direktly with mpd. Which network-tool can check this? At this moment I hear for hours 192/24 with only a very few clicks - no ssh, no Web-GUI, only gmpc.
I do absolutely agree with you. Reducing SD writings and network activity is a good way to follow. I’m going also in this direction. Using nginx instead of Apache is a choice made with that in mind. But we need webserver, so I’m going to enlight the web part even more…
Do you have something specific to share about that?
My ArchLinux: Play music and do pacman -S apache. Music is playing nearly clean.
Raspian: apt-get install lighttpd: Horrible. Forget the music.
Don’t know, what’s the difference with the two Linux-Distributions.
nginx I have never tested.
And an idea:
Is there a tool which can reduce the priority of webservers ports? And increases the priority of smb/nfs-ports? Ok, that would be no solution for USB-Devices.
After the struggle with nginx/php/log/tmpfs and the reduction of writes on the SD.Card now HiRes (88-192/24) is playing (nearly) clean. A great step forward.
And the little next step:
Put the mpd-database files etc. (state, sticker.sql, tag_cache, playlists-dir) into tmpfs (don’t forget to edit /etc/mpd.conf). Save/restore these files in /etc/init.d/mpd (start/stop-sections). You’ll get less writes on SD-Card while listening music.
and edit:
a) the file /var/www/command/orion_optimize.sh
#killall -9 atd
b) the file /var/www/_OS_SETTINGS/etc/rc.local
/bin/echo '/usr/local/bin/restart-volumio-gui' | /usr/bin/at now + 2min
exit 0
Make executable /usr/local/bin/restart-volumio-gui (chmod +x).
The Web-ui should be accessible after 2 minutes after reboot.
Disable the whole php-log: edit /var/www/_OS_SETTINGS/etc/php5/cli/php.ini
;error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
error_reporting = off
Or try this: php-errors-t244.html#p2030
That’s what I did in volumio. But that may be not enough and is not very elegant. Unfortunately my other mpd-installations (plain raspian and arch linux) are running much better and are playing without clicks etc. Volumio and runeaudio are playing the one day without any clicks, the next day it can be horrible. I don’t know why … Let’s wait for the next version of volumio.
I have also been getting short, random and occasional pops using a raspyfi running volumio beta and tried to implement the changes posted by Melomane. Unfortunately I seem unable to get the GUI to start at all. Are there any mistakes or omissions in the changes as described?