Netzwerk-Sound-Server mit pulseaudio & mpd

Bei meinem Desktop habe ich aktuell das Problem, dass die analoge Audioausgabe von einem lautem Masserauschen begleitet wird, sobald ich meinen alten Vollverstärker daran anschließe. Das ist mir etwas unheimlich, aber auch ein gründliche Inspektion von Gehäuse und Netzteil brachte nichts ungewöhnliches zu Tage. Als einfachste Lösung erschien mir eine externe USB-Soundkarte anzuschaffen. Die Wahl fiel nach auf eine Behringer Ucontrol UCA202; vor allem wegen des guten Preis-/Leistungsverhältnisses, der geringen Größe und guter Linuxkompatibilität.

Damit ich aber nicht immer meinen Rechner zu Musikhören bemühen muss, habe ich die Karte kurzentschlossen an meinem kleinen Homeserver angeschlossen (eine Seagate Dockstar mit Debian Squeeze), mit dem Ziel, dort den Musikserver mpd zu betreiben, den ich z.B. bequem mit meinem Smartphone steuern kann.

alsa installieren

Also die Karte anschließen und alsa installieren:

apt-get install alsa-base alsa-utils

Anschleißend muss man alsa erlauben, die USB-Karte als Default zu verwenden, was es standardmäßig zugunsten eingebauten Audiohardware (in meinem Fall nicht existent) verweigert. Also in /etc/modprobe.d/alsa-base.conf die Zeile

options snd-usb-audio index=-2

ändern in

options snd-usb-audio index=0 nrpacks=1

wobei vor allem das index=0 wichtig ist. Der nrpacks Parameter soll angeblich die Latenz senken, was ich aber nicht beurteilen kann. Wieder erwarten blieben die angeschlossenen Boxen aber vorerst stumm. Nach längerem hin und her, in dem mir vor allem die .asoundrc großes Vergnügen bereitet hat…, brachte vermutlich ein Kernelupdate auf den aktuelleren weniger veralteten Squeeze-Backports-Kernel 2.6.39-bpo.2-kirkwood Abhilfe. Damit läuft jetzt aber alles wunderbar (und mit alsa Standarteinstellungen).

mpd installeren

Die Installation von mpd lief dafür absolut problemlos:

apt-get install mpd

Anschließend sollte man sicherstellen, das der Benutzer mpd die Musiksammlung zumindest lesen kann, etwas durch ein

chmod -R 775 ~/Music

Dann in der Datei /etc/mpd.conf den Pfad zur Musiksammlung anpassen und den Netzwerkzugriff erlauben, indem man die Zeile

bind_to_address               "localhost"

durch ein vorgestelltes “#” auskommentiert. Eine ausführliche Anleitung gibt es im Ubuntuusers-Wiki. Nun kann man mit diversen Clientapplikationen — ich nutzte Sonata unter Ubuntu und MPDroid unter Android — die Musikwiedergabe steuern.

Netzwerkstreaming

Soweit konnte mich das ganze Setup durchaus begeistern. Allerdings hatte ich auf meinem Desktop weiterhin keine funktionierende Audioausgabe. Die nächstliegendste Idee war, die Audioausgabe über LAN zum Server zu streamen. Dazu bietet es sich an, noch einen Pulseaudio-Server auf den alsa-Server zu setzen, da dieser derartiges Streaming out-of-the-box (und — um etwas vorauszugreifen — auch durchaus überzeugend) beherrscht.

Server (Debian Squeeze)

Also pulseaudio auf dem Server installieren:

apt-get install pulseaudio

und in den system Modus schalten. Dazu in der Datei /etc/default/pulseaudio

PULSEAUDIO_SYSTEM_START=0

von 0 auf 1 ändern. Achtung: Der system Modus birgt wohl ein gewisses Sicherheitsrisiko, man sollte auf jeden Fall darauf achten, dass in der selben Datei auch

DISALLOW_MODULE_LOADING=1

gesetzt ist.

Nun nutzt pulseaudio die Einstellungen aus /etc/pulse/system.pa, und man kann durch ein Einfügen der Zeile

load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/16

den Empfang von Netzwerkstreams auf Port 4713 aktivieren (natürlich evtl die letzte Maske auf das eigene Subnet anpassen).

Anschließend den pulse-Sever starten

/etc/init.d/pulseaudio start

und testen. Es bieten sich an, nun auch mpd auf Pulseaudio umzustellen. Dazu in /etc/mpd.conf den Paragraphen über alsa auskommentieren und den über pulseaudio aktivieren.

Client (Ubuntu Oneiric)

Auch hier sollte der pulseaudio installiert und funktionsfähig sein (bei Ubuntu seit 8.04 Standard). Nun kann man durch setzen der Zeile

default-server = tcp:SERVERIP:4713

in der Datei  /etc/pulse/client.conf die KOMPLETTE Audioausgabe auf den Server umleiten, was bei mir allerdings erst nach einem Neustart funktionierte.

Fazit

Zugegebener Weise habe ich das ganz Setup noch nicht sehr lange in Betrieb, aber bisher funktioniert alles problemlos. Insbesondere hatte ich bei den Audio-over-Lan große bedenken bezüglich der Latenz der Signale, aber das scheint gänzlich unbegründet gewesen zu sein. Selbst Filme lassen sich ohne erkennbare Verzögerung der Tonspur und Abzüge in der Soundqualität anschauen. In ein paar Wochen kann ich dann vermutlich noch ein paar Erfahrungswerte hinzufügen.

Ubuntu Natty: Unity auf Netbook unbenutzbar? [Update]

Eigentlich warte ich üblicherweise nach dem Erscheinen einer neuen Ubuntuversion einige Wochen, bevor ich upgrade. Vielleicht hätte ich dabei bleiben sollen; da ich aber einige Probleme auf meinem Netbook (ein Samsung NC10) hatte, habe ich gestern direkt bei erscheinen von Ubuntu 11.04 “Natty Narwhal” das Upgrade angestoßen. Das Problem war vor allem, das ich zum teXen meiner Diplomarbeit gerne mit 2 Monitoren (den Netbookbildschrim und einem externen Monitor) arbeite, was unter 10.10 und Unity nicht vernünftig  (d.h. unterschiedliche Auflösungen auf beiden Monitoren) funktionierte. Deshalb habe ich Gnome als Desktopoberfläche verwendet, das aber – aus nicht nachvollziehbaren Gründen – immer 2-3 Minuten brauchte, um beim Starten den Desktop anzuzeigen…

Neben vielen anderen umbauten sollte insbesondere auch diese Multimonitorfähigkeit von Unity in Natty verbesserte werden, was mich zu dem schnellen Upgrade motivierte. Das funktioniert einem kurzen Test zufolge auch, leider beanspruchte das Rendern der Oberfläche via Compiz nun permanent 99% meiner CPU. Grafische Effekte sind ja ganz nett, aber das ist dann vielleicht doch etwas übertrieben… Benutzbar ist das so auf jeden Fall nicht.

Hat noch jemand ähnliche Probleme auf seinem Netbook? Wurde durch den Umstieg von Mutter auf Compiz wirklich die Lauffähigkeit auf Netbooks total zerstört? Das kann ich mir aufgrund der hohen Verbreitung der quasi identischen Hardware eigentlich nicht vorstellen…

Zur Zeit nutzte ich bis auf weiteres den 2D-Fallback von Natty, der aber weiterhin 2-3min braucht, um den Desktop anzuzeigen bzw Nautilus zu öffnen…

[Update] Mittlerweile bin ich dank der aktuellen C’t etwas schlauer. Anscheinend soll das 3D-Unity auf Intel-Chips mit mindestens der Zahl 950 im Namen flüssig laufen. Im Umkehrschluss heißt das wohl, dass ich auf meinem NC10 mit 945GME Pech gehabt habe. Mit dem Paket “unity-2d” kann man sich aber eine gut benutzbare 2D-Version von Unity installieren. Diese läuft gefühlt etwas langsamer als (Mutter-)Unity unter 10.10, lässt ich aber besser benutzen, u.a. wegen dem sich automatisch ausblendenden Starter. Großer Nachteil ist, dass sich unity-2d noch weniger konfigurieren lässt als die 3D-Version. Mittlerweile lassen sich aber anders als in der C’t beschrieben zumindest die Symbole im Starter per Drag ‘n Drop anordnen. [/Update]

lipsync: Ein Open-Source Dropdox Klon

Zur Zeit benutzte ich das kleine Programm unison um die Daten auf meinem Netbook und Desktop zu synchronisieren. Dazu gleichen beide mein Homeverzeichniss mit meinen kleinen NAS (eine Seagate Dockstar mit Debian Lenny) ab. Das funktioniert auch problemlos, der Nachteil ist nur, dass es bei jeder Sync das komplette Homeverzeichnis nach neuen oder geänderten Dateien durchsucht, was normalerweise mehr Zeit in Anspruch nimmt als das eigentliche Backup. Auch wenn das alles automatisiert im Hintergrund abläuft, habe ich mich gestern mal nach einer schöneren Lösung umgesehen.

Eigentlich ist mir das Prinzip von Dropbox, Ubuntu One etc. ganz sympathisch, die das Dateisystem auf den Clients live auf Änderungen überwachen (eine Funktion, die der Linux-Kernel mit inotify von Haus aus mitbringt) und diese dann direkt zum Server übertragen. Somit spart man sich das durchrödeln des kompletten Datenbestandes und minimiert nebenbei auch noch die Gefahr, die Änderungen zwischen zwei Syncs zu verlieren. Leider sind die beiden Dienste zu teuer, als dass ich sie sinnvoll nutzen könnte.

Gestern bin ich dann über lsyncd gestolpert, das ein solches System zum einfachen Selbsthosten bauen will/schon gebaut hat. Ich habe das bis jetzt noch nicht ausprobiert, aber es liest sich auf jeden Fall schon mal sehr gut! Mehr Infos gibt es im Blog von Fak3r, dem Programmierer dahinter. Hoffentlich schließen sich noch ein paar Leute dem Projekt an, z.B. wäre ein kleiner optionaler für die Client super. Sobald mir meine Diplomarbeit wieder etwas mehr Zeit lässt, werde ich das auf jeden Fall gründlich ausprobieren, und hier über meine Erfahrungen berichten.