Raspyfi: Audiophile ;-} Linux Lösung

[Melomane]

Hallo Frank,

auf diese IO-Geschichte zielte meine Bemerkung letztlich, war nur ungeschickt ausgedrückt im Eifer des Gefechts.

Also gehen wir der Sache mal auf den Grund:

• Ich nehme mir mein Standard-Raspian vor,
• deaktiviere das swap-file
• mounte einige zusätzliche /var-Verzeichnisse als Ramdisk, insbesondere /var/log
• ebenso /tmp
• disable bash_history
• erhöhe auch die Bufferwerte in der mpd.conf

Damit findet ein Großteil der Schreibvorgänge nicht mehr auf der Speicherkarte statt.
Dann Musikwiedergabe (96/24-flac).
Relativ gut geht das. Also zur Kontrolle

Code: Alles auswählen

apt-get install iotop

Währenddessen heftige Störungen der Wiedergabe => Die Schreibvorgange sind also wirklich Gift.

Code: Alles auswählen

iotop -oa

sagt dann nach einiger Zeit:

Code: Alles auswählen

  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2354 be/4 mpd         174.92 M      0.00 B  0.00 %  0.01 % mpd /etc/mpd.conf
   98 be/3 root          0.00 B     32.00 K  0.00 %  0.01 % [jbd2/mmcblk0p2-]
 2349 be/4 mpd           0.00 B      8.00 K  0.00 %  0.00 % mpd /etc/mpd.conf

Gibt es irgendein Programm, dass mir sagt, in welche Datei der jeweilige Prozess schreibt?

Denn ganz störungsfrei ist die Wiedergabe nicht. Und die Störung scheint auch dann aufzutreten, wenn der Schreibvorgang von root (Nr. 98) stattfindet. Allerdings nicht nur dann. Insgesamt scheinen die Maßnahmen aber einiges bewirkt zu haben. Denn die Störungen sind deutlich unauffälliger als bisher mit den HiRes-files.

top sagt übrigens gerade folgendes für die ersten paar Prozesse:

Code: Alles auswählen

 2508 root      20   0 11820 7224 3528 S  20,6  1,6   3:55.05 iotop
 2349 mpd       20   0 70632  14m 2244 S  12,1  3,3   3:22.98 mpd
 2426 root      20   0  3480 1316  980 R   1,3  0,3   0:18.31 top
   43 root      20   0     0    0    0 S   0,3  0,0   0:00.75 mmcqd/0
 2298 pi        20   0  3752 1676  892 S   0,3  0,4   0:05.22 screen
 2453 root      20   0  4988 2128 1660 S   0,3  0,5   0:09.91 ncmpc
    1 root      20   0  2140  712  608 S   0,0  0,2   0:01.84 init
    2 root      20   0     0    0    0 S   0,0  0,0   0:00.00 kthreadd

Gruß

Jochen

[Melomane]

Ah, offenbar ist zumindest der mpd beteiligt, der seine status-Datei alle paar Minuten schreibt. Also lagern wir die auch noch aus - auf das NAS.

[Melomane]

So - Lohn der Mühe: Offenbar finden keine lokalen Schreibvorgänge mehr statt. Und damit habe ich bei 96/24 so gut wie keine Störungen mehr. 100%-ig fehlerfrei ist die Wiedergabe allerdings noch nicht. Mit 192/24 ist dann aber nach wie vor kein Staat zu machen. Woran das liegt, gilt es noch genauer zu ergründen. Aber nicht mehr heute.

Wenn nun Volumio so störungsanfällig ist, dann dürfte ein erheblicher Teil der Störungen durch die zahlreichen Schreibvorgänge verursacht sein, die Volumio vor allem beim syslog produziert.

Gruß

Jochen

EDIT: Dem cron sollte man wohl auch noch auf die Finger schauen.

[frankl]

auf diese IO-Geschichte zielte meine Bemerkung letztlich, war nur ungeschickt ausgedrückt im Eifer des Gefechts.

Also gehen wir der Sache mal auf den Grund:

• Ich nehme mir mein Standard-Raspian vor,
• deaktiviere das swap-file
• mounte einige zusätzliche /var-Verzeichnisse als Ramdisk, insbesondere /var/log
• ebenso /tmp
• disable bash_history
• erhöhe auch die Bufferwerte in der mpd.conf

Damit findet ein Großteil der Schreibvorgänge nicht mehr auf der Speicherkarte statt.
Dann Musikwiedergabe (96/24-flac).
Relativ gut geht das. Also zur Kontrolle

Code: Alles auswählen

apt-get install iotop

Währenddessen heftige Störungen der Wiedergabe => Die Schreibvorgange sind also wirklich Gift.

Code: Alles auswählen

iotop -oa

sagt dann nach einiger Zeit:

Code: Alles auswählen

  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2354 be/4 mpd         174.92 M      0.00 B  0.00 %  0.01 % mpd /etc/mpd.conf
   98 be/3 root          0.00 B     32.00 K  0.00 %  0.01 % [jbd2/mmcblk0p2-]
 2349 be/4 mpd           0.00 B      8.00 K  0.00 %  0.00 % mpd /etc/mpd.conf

Gibt es irgendein Programm, dass mir sagt, in welche Datei der jeweilige Prozess schreibt?

Hallo Jochen,

ja das sind doch schonmal alles gute Maßnahmen. Du kannst im /proc Dateisystem die offenen File-Descriptoren eines Prozesses sehen und auf welche Files die zeigen, etwa für den ersten mpd Thread oben:

Code: Alles auswählen

 
ls -l /proc/2354/fd

Denn ganz störungsfrei ist die Wiedergabe nicht. Und die Störung scheint auch dann aufzutreten, wenn der Schreibvorgang von root (Nr. 98) stattfindet. Allerdings nicht nur dann. Insgesamt scheinen die Maßnahmen aber einiges bewirkt zu haben. Denn die Störungen sind deutlich unauffälliger als bisher mit den HiRes-files.

top sagt übrigens gerade folgendes für die ersten paar Prozesse:

Code: Alles auswählen

 2508 root      20   0 11820 7224 3528 S  20,6  1,6   3:55.05 iotop
 2349 mpd       20   0 70632  14m 2244 S  12,1  3,3   3:22.98 mpd
 2426 root      20   0  3480 1316  980 R   1,3  0,3   0:18.31 top
   43 root      20   0     0    0    0 S   0,3  0,0   0:00.75 mmcqd/0
 2298 pi        20   0  3752 1676  892 S   0,3  0,4   0:05.22 screen
 2453 root      20   0  4988 2128 1660 S   0,3  0,5   0:09.91 ncmpc
    1 root      20   0  2140  712  608 S   0,0  0,2   0:01.84 init
    2 root      20   0     0    0    0 S   0,0  0,0   0:00.00 kthreadd

Die Ausgabe von top zeigt also, dass es kein Problem mit der CPU-Leistung gibt.

Du kannst mal versuchen, den mpd Daemon mittels 'chrt' mit Realtime-Priority laufen zu lassen. Die Priority kannst Du auch bei einem laufenden Prozess ändern. Im Beispiel oben:

Code: Alles auswählen

sudo chrt -r -p 99 2349

Und vielleicht kannst Du auch noch radikaler einige Dinge abschalten, die Du nicht brauchst, hier sind ein paar Dinge, die ich auf einem Rasbian mache:

Code: Alles auswählen

dphys-swapfile swapoff
dphys-swapfile uninstall
echo 1 > /proc/sys/vm/drop_caches

service lightdm stop
service avahi-daemon stop
service udev stop
service triggerhappy stop
service ntp stop
service minissdpd stop
service  dbus stop
service cron stop
service rsyslog stop
service ifplugd stop
pkill udisks-daemon
pkill ifplugd
pkill menu-cached
pkill -u pi
pkill X

echo -n performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
echo 0 > /proc/sys/vm/swappiness
echo 100000 > /proc/sys/kernel/sched_latency_ns
ifconfig eth0 txqueuelen 10000

modprobe -r snd_bcm2835
modprobe -r snd_seq
modprobe -r snd_pcm

Viel Spaß beim weiteren Experimentieren,
Frank

[Melomane]

Hallo Frank,

bin schon dabei.

Danke für die zusätzlichen Tipps. Die bringen aber bei mir keine weitere Verbesserung. Insbesondere die Umstellung auf realtime bewirkt eher wieder eine Verschlechterung. Da gilt es also weitere Forschung zu betreiben.

Ich habe mir übrigens auch das weiter oben erwähnte RuneAudio installiert. Das ist sozusagen Volumio auf Archlinux. Und bringt deswegen auch keine Verbesserung ohne zusätzliche Eingriffe. Da bleibe ich lieber bei meinem Raspbian.

Ich habe mich auch schon gefragt, ob womöglich die verwendete Speicherkarte und deren Geschwindigkeit eine Rolle bei der Frage spielt, ob Störungen auftreten, solange die Schreibzugriffe nicht abgestellt sind.

Gruß

Jochen

[Melomane]

Frank,

ich spiele noch ein wenig mit chrt. Dem Hauptprozess von mpd kann man ja beim Start mittel pidof die realtime-Fährigkeit verpassen. Aber während der Musikwiedergabe laufen weitere mpd-Prozesse, die dann nicht als rt agieren. Ist das egal oder wie erwischt man die, um sie automatisch mit chrt zu konfigurieren?

Gruß

Jochen

Edit: Im Moment läuft es gut mit rt. Ich weiß nicht, warum das vorhin nicht wollte. Und mir scheint, dass dieser erst später auftauchende weitere mpd-Prozess für das Holen der Daten vom NAS zuständig ist. Gerade der sollte also von rt profitieren:

Code: Alles auswählen

 2346 rt/4 mpd         113.82 M      0.00 B  0.00 %  0.04 % mpd /etc/mpd.conf

Wie man sieht, werden da heftig Datenmengen gelesen. Deswegen habe ich ihm manuell rt zugewiesen. Aber das ist ja keine Dauerlösung.

[Melomane]

Wie man sieht, werden da heftig Datenmengen gelesen. Deswegen habe ich ihm manuell rt zugewiesen. Aber das ist ja keine Dauerlösung.

Aha, die manpage hilft wie so oft.

Edit: Von dieser Seite habe ich einige Optimierungen in Sachen Netzwerk übernommen:
http://mubox.voyage.hk/realtime_kernel
Ob das konkret hilfreich ist, kann ich noch nicht sagen.

[Melomane]

Hallo in die Runde der Interessierten,

ein frisch aufgesetztes Arch Linux scheint erheblich weniger Probleme zu machen als Raspbian, wenn es um Störungen geht: Vielleicht ist es nur Zufall - aber es lassen sich sogar 192/24 nahezu störungsfrei wiedergeben (ein wenig Optimierungspotential ist aber noch gegeben). Und nebenbei können Config-Dateien editiert werden. Das allein kann Raspians Musikwiedergabe schon bei 96/24 völlig aus dem Tritt bringen.

Wenn es nicht die Tagesform oder Zufall ist, frage ich mich, woran das liegt. Aus irgendwelchen Gründen scheint die Performance besser als bei Debian zu sein. Ich habe allerdings (noch) keinen Webserver (lighttpd) laufen. Ob der die Performance bei Raspbian bremst? Eigentlich ist der aber sowieso überflüssig. Es gibt ja genügend andere Clients zur Bedienung.

Gruß

Jochen

[Unicos]

Hi Jochen,

ich nutze oft

Code: Alles auswählen

lsof -p <Prozessid> 

um rauszufinden welche Files etc. offen sind.

Vielleicht hilft es ja beim naechsten suchen.

Gruss

Thomas (Der das alles von Dir und Frank sehr interessiert verfolgt )

[Melomane]

Hallo Thomas,

danke - ich wusste doch, da war was.

Übrigens vermute ich, dass u.U. der neuere Kernel von Arch Linux seinen Teil an der besseren Performance hat. Ich habe nebenbei - neben der laufenden Musikwiedergabe 96/24 - Pakete installiert und deinstalliert. Das ging ohne das geringste Zucken. Und es gibt netterweise auch kernel-header, so dass ich ohne Verrenkungen das modul für mein HiFace 1 kompilieren kann.

Alles in allem scheint mir Arch Linux eine gute Wahl für einen mpd-rpi zu sein.

Ein, zwei kleine ungewohnte Dinge sind mir bislang aufgefallen: Beim Reboot/Shutdown wird die ssh-Verbindung nicht gleich gekappt. PuTTy bekommt erst relativ spät etwas davon mit. Und die runlevel-Verwaltung ist komplett anders als beim ollen Debian. Na ja, Kleinigkeiten!

Gruß

Jochen

[Melomane]

Die Testerei geht weiter:

Frage: Ist es der Webserver, der bremst?

Also Installation von einem fetten Apachen (damit es sich auch lohnt) und php. Dann setzen wir mal ein wenig Last auf das System mittels phpsysinfo. CPU-Load steigt dabei auf nahezu 90%. Aber die Musikwiedergabe (96/24-flac) lässt sich nicht im mindesten aus der Ruhe bringen. Ach ja - phpsysinfo gesteht dem rpi ganze 2 bogomips zu.

Der Webserver ist also zumindest bei Arch Linux aus der Liste möglicher Störenfriede entlassen.

[Sire]

Jochen, ich hatte anfangs auch mit Arch Linux experimentiert. Leider habe ich nichts dokumentiert. Was mir aber auffiel, dass dort auch ein Systemdienst eifrig am Loggen war, und sich nicht abschalten ließ. Ich glaube, nachdem ich ifplugd deaktiviert hatte, hörte das auf... Sicher bin ich aber nicht. Setzt Du Arch Linux weiter ein?

Deine (?) Posts im Volumio-Forum zur Performanceverbesserung habe ich mit Interesse gelesen, selber aber noch nicht umgesetzt. Wie in meinem Vorstellungsthread beschrieben, war ich die letzte Zeit damit beschäftigt, Convolving auf dem Pi zu realisieren. Mit folve ging es dann.

Viele Grüße
Klaus

[Melomane]

Hallo Klaus,

ich nutze in den letzten Tagen raspbian (bei debian fühle ich mich heimischer) und habe der mpd-Lösung im Moment den Rücken gekehrt. Auf dem NAS läuft der squeezebox-server, auf dem rpi squeezelite als Player. Kein Webserver, kein php - damit scheint Ruhe zu sein in Sachen Störungen bei Hires-Wiedergabe. Offenbar ist mit dieser Lösung weniger Verkehr auf dem BUS. Ich traue dem Braten allerdings noch nicht so ganz und beobachte weiter.

Gruß

Jochen

[Sire]

Hallo Jochen,

viele Wege führen nach Rom... Wenn mpd läuft, traten die Highres-Störungen meiner Erfahrung nach nur dann auf, wenn ich ein USB-Soundinterface benutzt habe. Seit ich auf den HiFiBerry DAC umgestiegen bin, gab es definitiv keine Störungen mehr. Zumindest bis flac 24/192, höhere Auflösungen unterstützt der HiFiBerry nicht.
Kabelgebundenes Netzwerk soll auch kritisch sein, verwende ich aber schon wegen der Störeinstrahlung nicht.

Gruß
Klaus

[Sire]

Hallo Jochen,

ich habe gerade im Volumio-Forum diesen thread entdeckt:

My solution to pops and clicks

und dachte es könnte interessant sein, insofern Du nochmal Volumio ausprobieren möchtest…

Gruß

Klaus