Netzwerk-Musikplayer: Wir bauen einen audiophilen Walkman mit dem Raspberry Pi
Dass Gold im Lötzinn für besseren Klang sorgt, klingt zwar sehr nach Esoterik, das Produkt mit dem Zauberzinn finden wir dennoch interessant: Sonys kürzlich vorgestellten Walkman-Player NW-A306 . Aber der Preis stört, 400 Euro sind eine Hausnummer. Können wir eine kostengünstigere Alternative für, sagen wir, ein Viertel des Preises selbst bauen? Wir starten den Versuch – und lernen dabei viel über den Raspberry Pi, seine Möglichkeiten und Einschränkungen.
An der Rechenleistung sollte es erst einmal nicht scheitern: Selbst die ersten Raspberry Pis mit BCM2835-System-on-Chip (SoC) und nur einem ARM-Kern sollten Musikwiedergabe problemlos bewältigen. Dafür wollen wir eine qualitativ hochwertigere Sound-Hardware als den Klinkenausgang des Pi verwenden. Ein Modul namens DAC+ Zero von Hifiberry(öffnet im neuen Fenster) wartet eh seit Längerem darauf, verbaut zu werden, also verwenden wir es kurzentschlossen. Es hat zwar keinen Kopfhörerausgang, aber sollte der sich nicht problemlos nachrüsten lassen? Bedienen wollen wir unseren Musikplayer wie das Vorbild über ein Touchdisplay.
Wir finden ein Modell von Waveshare(öffnet im neuen Fenster) mit 4,3 Zoll Diagonale, das uns gefällt. Im Gegensatz zu deutlich günstigeren Modellen, die auf die Pin-Leiste des Raspberry Pi gesteckt werden, wird es mittels Flachkabel und Display Serial Interface (DSI)(öffnet im neuen Fenster) mit dem SoC verbunden. Verbaut ist ein IPS-Panel, der Touchscreen funktioniert kapazitiv, die günstigen Modelle haben nur einen resistiven Touchscreen. Der reagiert auf Druck, was wir nicht mehr zeitgemäß finden.
Die ersten 70 Euro sind schnell ausgegeben
Leider ist das Display mit 48 Euro recht teuer, dazu kommen 20 bis 24 Euro für das Sound-Modul. Dann müssen wir also beim Raspberry Pi sparen. Eigentlich wollen wir die Zero-Variante verwenden, hier findet sich aber leider kein Display über DSI-Anschluss, sondern lediglich eine Kamera mittels CSI. DSI gibt es nur bei den größeren Boards, das günstigste ist das Model A+, das nur mit einem USB-Anschluss kommt.
Leider braucht das A-Modell doppelt so viel Platz wie ein Zero – den wollten wir eigentlich für eine Powerbank benutzen, um auch unterwegs Musik hören zu können. Aus diesem Grund hatten wir uns auch gegen ein Display mit HDMI-Eingang entschieden, um voluminöse Stecker zu vermeiden. Um unser Modell A+, das etwa 23 Euro kosten soll, aktuell aber nirgendwo erhältlich ist, netzwerkfähig zu machen, spendieren wir ihm für 5 Euro ein USB-WLAN-Modul.
Damit haben wir unser Budget bereits ausgereizt und es fehlen noch eine Powerbank und eine Speicherkarte. Bei der Speicherkarte lohnt es sich, zu einem schnellen Modell zu greifen. Wir haben noch eine 64-GByte-Karte von Samsung (Evo Plus), die eine ganz brauchbare Geschwindigkeit von fast 70 MByte/s beim sequentiellen Lesen erreicht und rund 8 Euro kostet. Weshalb eine schnelle Karte sich lohnt, sehen wir gleich.
Aber zunächst müssen wir noch klären, wie wir einen Kopfhörer an unseren Walkman bekommen. Da es leider quasi unmöglich ist, einen Kopfhörerverstärker nachzurüsten, müssten wir ein anderes Modul verwenden. Denn während es Platinen mit Lautsprecherverstärker für wenige Euro in großer Auswahl gibt, sind Kopfhörerverstärker als fertige Platine unmöglich zu bekommen. Es gibt aber eine kostenneutrale Alternative: Für den gleichen Preis wie unser Hifiberry-Modul bekommen wir das IQaudio DAC+ – mit Klinkenbuchse zum Anschluss eines Kopfhörers.
Die Teileliste steht also, jetzt schauen wir uns an, was die Software können muss, und kommen damit zurück zur Speicherkarte.
Der Pi möchte nicht schlafen
Eigentlich würden wir unseren Walkman-Klon gern bei Nichtbenutzung in einen möglichst energiesparenden Tiefschlaf versetzen. Ähnlich wie ein Handy könnte er dann tagelang mit einer Akkuladung durchhalten und wäre, wenn wir Musik hören wollen, auf Knopfdruck wieder einsatzbereit.
Leider macht uns der Raspberry Pi hier einen Strich durch die Rechnung. Denn einen funktionierenden Suspend to RAM gibt es nicht, außerdem ist das Broadcom-SoC niemals richtig aus, solange es nicht vom Strom getrennt wird. Auch wenn das Betriebssystem, das auf dem ARM-Kern läuft, heruntergefahren wird, bleiben Teile des SoC weiter aktiv.
Das hat zwei Gründe: Erstens hat die Raspberry Pi Foundation auf eine Logik zum Ein- und Ausschalten verzichtet, um einen möglichst kostengünstigen Kleincomputer zu bauen. Zweitens sind die Broadcom-SoC ungewöhnlich aufgebaut. Die eigentliche Kernkomponente ist hier nämlich nicht der ARM-Prozessor, sondern die Grafikeinheit namens Videocore.
GPU startet den Prozessor
Normalerweise startet beim Booten zunächst ein Prozessorkern, der dann mögliche weitere Kerne und Hardwareeinheiten initialisiert. Anders bei den Broadcom-SoC: Hier wird zunächst eine Firmware-Datei in die Videocore-Einheit geladen(öffnet im neuen Fenster) , die dann das SoC initialisiert.
Der ARM-Kern war ursprünglich mehr eine Dreingabe, die beim Raspberry Pi aber die Hauptrolle spielt. Wir benutzen das SoC also anders, als der Hersteller sich das vorgestellt hat. Und den Raspberry Pi verwenden wir anders, als es die Raspberry Pi Foundation sich vorgestellt hat – und abseits des Entwicklungsschwerpunkts, der Schlafzustände nicht umfasst.
Dass unser Musikplayer entweder die ganze Zeit eingeschaltet bleiben oder jedes Mal neu gestartet werden muss, ist natürlich ein Problem. Das wird besonders deutlich, wenn wir uns bereits fertige Musikplayer-Images ansehen, wie wir sie beim Aufrüsten einer Hi-Fi-Anlage verwendet haben. Davon gibt es nicht wenige und alle haben die gleichen Probleme: Sie brauchen sehr lange, bis sie betriebsbereit sind, oder sie werden für unser Model A+ nicht mehr weiterentwickelt. Andere wurden komplett eingestellt.
Also bleibt noch die Möglichkeit, ein eigenes System zu entwickeln. Natürlich aus bereits bestehender Software.
Wir bauen eine Linux-Distribution
Unser eigenes Musikplayer-Linux soll so schlank wie möglich werden: kompakter Kernel, keine nachgeladenen Treibermodule, möglichst wenig Software, die möglichst nur Musik abspielt. Genau für so etwas eignet sich Buildroot: Damit lassen sich Betriebssystem-Images samt Linux-Kernel konfigurieren und erzeugen.
Das mächtige Werkzeug steckt beispielsweise auch hinter OpenWRT, dank vorgefertigter Konfigurationen für diverse Single Board Computer (SBC) ist der Start ziemlich einfach. Alle Komponenten zu kompilieren dauert eine Weile, dann startet unser erstes Image. Mehr als die Konsole mit Anmeldeaufforderung gibt es allerdings erst einmal nicht. Als Nächstes fügen wir weitere Software hinzu.
Mit Kodi finden wir gleich ein vertrautes Media Center. Kodi braucht einiges an zusätzlicher Software, die nur 120 MByte kleine Betriebssystempartition ist schnell zu klein, wir müssen sie vergrößern.
Auch Kodi lässt sich Zeit
Leider stellt sich beim ersten Test (bis dahin haben wir einige Anläufe gebraucht) heraus, dass Kodi zwar mächtig ist, das aber auch seinen Preis hat: 37 Sekunden vergehen, bis die Benutzeroberfläche erscheint. Dabei sind wir noch nicht einmal im WLAN angemeldet.
Damit ist klar: Mit Kodi wird das nichts, zumal die Benutzeroberfläche einfach nicht für unser kleines Display mit nur 800 x 480 Bildpunkten gemacht ist. Die Bedienung ist extrem mühselig, in vielen Menüs scheitern wir an der fehlenden Tastatur. Also begeben wir uns auf die Suche nach Alternativen.
Dabei wird schnell klar: Die sind rar. In Buildroot steht als einzige Alternative mit grafischer Oberfläche noch VLC zur Verfügung. Ohne Tastatur ist das auch unbenutzbar.
Schlank und audiophil: der Music Player Daemon
Nach diesen Fehlschlägen haben wir eine genauere Vorstellung, wie das System zum Abspielen von Musik aussehen soll: Wir wollen den Music Player Daemon (MPD)(öffnet im neuen Fenster) verwenden, so lässt sich der Player nicht nur über das Display, sondern auch etwa vom Tablet oder Computer aus steuern. Über YMPD können wir den Player über den Browser steuern, ein Samba-Plug-in ermöglicht MPD den Zugriff auf die Musiksammlung auf unserem NAS. Außerdem bringt er ein für unsere audiophilen Ohren wichtiges Feature mit: bit-perfekte Wiedergabe.
Was kompliziert klingt, bedeutet schlicht, dass die Software versucht, die Sound-Hardware mit der Abtastrate der wiedergegebenen Musikdatei zu betreiben. Das vermeidet die Abtastratenkonvertierung(öffnet im neuen Fenster) , geläufiger ist der englische Begriff Resampling. Resampling verändert tatsächlich das Tonsignal; ob das hörbar ist, haben wir allerdings nicht getestet.
Die grafische Oberfläche stellt sich allerdings als unerwartet großes Problem heraus: Zwar listet die MPD-Webseite einige Programme auf, die meisten fallen allerdings direkt aus, weil sie entweder GTK oder einen Fenstermanager benötigen. Übrig bleibt nur SkyMPC(öffnet im neuen Fenster) , das auf Qt aufsetzt. Wir integrieren es in die Buildroot-Umgebung. Nachdem wir die Konfigurationsdateien des Programms gefunden und angepasst haben, funktioniert die Anwendung ganz gut.
Damit ist die Software komplett, jetzt geht es daran, den Start zu beschleunigen.
Wir machen dem Pi Beine
Als Metrik für unsere Optimierungsbemühungen messen wir, wie lange es dauert, bis wir die Oberfläche von SkyMPC sehen. Wir beginnen mit den niedrig hängenden Früchten in der Konfigurationsdatei, die den Systemstart kontrolliert.
Hier entfernen wir zunächst die einsekündige Wartezeit beim Systemstart, auch der Regenbogen-Splash-Screen fliegt raus. Hier sind wir auch gleich an einer Stelle, auf die wir fast keinen Einfluss haben: Die Firmware benötigt beim Systemstart gute 5 Sekunden, bevor überhaupt der Linux-Kernel übernimmt. Es gibt zwar eine abgespeckte Variante, mit der startet allerdings der Pi nicht mehr.
Aktuell dauert es 33 Sekunden, bis wir die Oberfläche von SkyMPC sehen. Als Nächstes lassen wir die Kernelausgaben weg, die durch die serielle Konsole ziemlich bremsen. Das funktioniert, indem wir der Kernel-Kommandozeile den Parameter quiet hinzufügen, und spart fast zwei Sekunden. Dann geht es an den Kernel selbst.
Der Kernel ist schon gut optimiert
Hier gibt es allerdings wenig Optimierungspotenzial, da für die verschiedenen Raspberry Pis gute Standardkonfigurationen existieren. Wir kompilieren den Kernel mit integrierten Treibern für Grafikeinheit, Display und WLAN-Stick, dafür entfernen wir die Multimedia-Treiber.
Letztere werden für die Kameraschnittstelle und die verschiedenen En- und Decoder des Broadcom-SoC benötigt. Da wir hiervon aber nichts verwenden, können wir problemlos auf sie verzichten, was den Start um gute vier Sekunden beschleunigt. Dann machen wir weiter mit der Software, die wir über die Buildroot-Konfiguration auswählen.
Die richtige Bibliothek und ein bisschen Schummelei
Unser Spielraum beschränkt sich hier allerdings auf die Konfiguration von Qt. Wir können zwischen verschiedenen Schnittstellen zum Rendern wählen, linuxfb benötigt dabei über eine Sekunde weniger als OpenGL ES, das wir zuerst verwendet hatten.
Dann greifen wir in die Trickkiste und sortieren die Reihenfolge um, in der die einzelnen Anwendungen starten. MPD und die beiden dazugehörigen Clients schieben wir so weit wie möglich nach vorn. Erst, wenn sie gestartet sind, aktivieren wir das WLAN und starten NTP sowie Samba. Letzteres verwenden wir, um über WLAN Dateien auf den Player übertragen zu können.
Damit drücken wir die Startzeit auf etwa 22 Sekunden. Ein As haben wir noch im Ärmel: Der Raspberry Pi lässt sich über die bereits oben erwähnte Konfigurationsdatei einfach übertakten. Mit 900 MHz läuft das SoC noch stabil und fast ein Drittel schneller. Damit kommen wir sogar unter 20 Sekunden, wenngleich mit 19 Sekunden nur knapp. Den Speichertakt um 50 MHz zu erhöhen, hat leider keinen großen Effekt.
Damit ist es Zeit für einen Hörtest und natürlich einige abschließende Worte.
Hörtest und Fazit
Im Hörtest beeindruckt unser audiophiler Raspberry Pi mit unglaublicher Räumlichkeit, präzisen Bässen und glasklaren Höhen. Aber Spaß beiseite: Der Codec des Hifiberry erzeugt wirklich einen guten Klang, der Bass ist kräftig, aber nicht zu sehr betont und auch die Höhen sind sauber.
Aber natürlich ist unser Musikplayer als Bastelprodukt nicht mit einem extra für diesen Zweck entworfenen Produkt vergleichbar. Reduzieren wir die Helligkeit des Displays, kommt unser Player zwar mit unter einem Watt aus und läuft an einer Powerbank einige Stunden. Der Raspberry Pi ist aber eigentlich keine geeignete Plattform für ein mobiles Gerät. Die Leistungsaufnahme und der fehlende Suspend ist dabei nur ein Aspekt. Der zweite ist, dass wir aufgrund der mehreren zusammengesteckten Komponenten eher die Größe eines klassischen Walkmans mit Kassette erreichen.
Noch viel zu tun ...
Und natürlich bleibt noch vieles zu tun: Unser audiophiler Pi hat noch kein Gehäuse, ganz abgesehen von einer Möglichkeit zum Ein- und Ausschalten. Die Software funktioniert, wirklich schön ist sie nicht. Sie ist zudem der Grund, dass wir auf udev angewiesen sind, das viel Zeit beim Systemstart braucht. Ohne udev wird allerdings der Grafiktreiber nicht aktiviert. Mit ein wenig Zeit lässt sich aber sicher herausfinden, welche Magie dazu erforderlich ist.
Auch Qt ist noch immer recht schwergewichtig, eine Alternative mit ncurses dürfte einige Sekunden schneller starten. Oder wir erhöhen einfach die Leistung: Auch vom Raspberry Pi 3 gibt es ein Model A+. Das ist zwar mit rund 30 Euro etwas teurer, bringt dafür aber gleich WLAN mit und verfügt über vier ARM-Kerne, die auch noch die neuere und leistungsfähigere A53-Architektur verwenden und höher takten.
Damit könnte die 10-Sekunden-Marke in greifbarer Nähe liegen – und das Software-Gerüst steht.