Nachdem in Teil 1 die Installation des Betriebssystems und in Teil 2 die Installation der Magic Mirror-Anwendung beschrieben wurde, folgen im Anschluss noch ein paar optionale Modifikationen.
Schlagwort: Raspberry Pi
Nachdem in Teil 1 die Grundinstallation des Betriebssystems durchgeführt wurde, folgt nun die Installation der GUI sowie der Magic Mirror-Software.
Ein Magic Mirror ist eine faszinierende Idee: ursprünglich vom Niederländer Michael Teeuw erdacht kann so aus einem Raspberry Pi und einem überzähligen Bildschirm mit überschaubarem Aufwand ein schick aussehendes Infoterminal für die ganze Familie gebastelt werden. Letztendlich gab der Artikel „Raspberry beschreibt Spiegel“ in der Ausgabe 7/2016 der Zeitschrift c’t den Ausschlag, eine konkrete Installation auf einem bereits vorhandenen Raspberry Pi 2 durchzuführen.
Ein Großteil der Projekte rund um den Raspberry Pi setzt auf das von der Raspbian Foundation offiziell unterstützte „Raspbian„, welches aber in seiner Grundkonfiguration eher für Desktop-Anwendungen als für schlanke Serverinstallationen gedacht und geeignet ist.
Während zum Beispiel im Rahmen des Foren-Beitrags „Complete Setup Tutorial“ vorgeschlagen wird, die Raspbian-Installation im Schitt „Cleaning up and updating the operating system“ nach Installation von nicht benötigten Komponenten zu befreien, bietet sich als Alternative eine schlanke Distribution wie „Arch Linux ARM“ an, welche während der Grundinstallation deutlich weniger unnötigen Ballast auf die SD-Karte schaufelt.
Nach einer Systemaktualisierung des Raspberry Pi Streamingclients mittels
[root@alarmpi ~]# pacman -Syu
sah im ersten Moment alles gut aus: das Update lief durch, „systemctl –failed“ offenbarte keine neuen Baustellen und auch der zwischenzeitlich abtürzende gmrender-resurrect lief wieder wie geplant.
Ein Problem zeigte sich allerdings beim Abspielen des ersten Audio-Tracks: die Lautsprecher blieben stumm und „aplay -l“ lieferte mit
[root@alarmpi ~]# aplay -l aplay: device_list:268: no soundcards found...
den Hinweis, daß irgendetwas mit dem Treibern für den HiFiBerry nicht in Ordnung war.
Der entscheidende Tip kam vom HiFiBerry-Support innerhalb weniger Minuten in Form des „Configuring Linux 3.18.x-Guide„:
In January 2015, the Raspberry Pi kernel developers have decided to start using Linux 3.18.x. With this version a new way to load device drivers have been introduced to the Raspberry Pi environment. It is called device tree overlay. This brings big changes to the way how to configure the necessary drivers for the HiFiBerry boards.
Nach Einfügen der Zeile „dtoverlay=hifiberry-dac“ in die Datei „/boot/config.txt“ wurde der HiFIBerry wieder erkannt und die Soundausgabe funktionierte wieder.
Nachdem sich der Streamingclient im Alltag bewährt hat und auch die WiFi-Anbindung problemlos funktioniert, steht als letzter Schritt noch die Verbesserung der über den 3,5″ Klinkenausgang nur mäßigenKlangqualität an. Neben der Wolfson Pi Audio Card, deren Treibersituation weiterhin schwierig bleibt gibt es als Alternative den HiFiBerry, der – ja nach gewählter Ausstattung – den Raspberry Pi auch gleich um zwei Chinchbuchsen erweitert.
Einzige Schwierigkeit bei der Installation ist die anfallende Lötarbeit, denn während die Wolfson Pi Audio Card die Verbindung für den p5-Anschluß integriert hat, muß beim HiFiBerry zum Lötkolben gegriffen werden. Die Aufgabe sollte aber auch mit geringen Kenntnissen und Fertigkeiten lösbar sein – für das „wie“ gibt es ein eine extra Hilfeseite „Soldering the HiFiBerry„, auf der auch ein Demonstrationsvideo verlinkt ist.
Die weiteren Schritte sind schnell erledigt: HiFiBerry aufstecken und in der Datei „/etc/modules-load.d/raspberrypi.conf“ die benötigten Module hinzufügen sowie das originale Soundmodul „snd-bcm2835“ auskommentieren:
[root@alarmpi ~]# cat /etc/modules-load.d/raspberrypi.conf bcm2708-rng #snd-bcm2835 snd_soc_bcm2708_i2s bcm2708_dmaengine snd_soc_pcm5102a snd_soc_hifiberry_dac
Nach einem Reboot sollte die Ausgabe von „aplay“ (im Paket „alsa-utils“ enthalten) dann das richtige Ausgabegerät anzeigen:
[root@alarmpi ~]# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: sndrpihifiberry [snd_rpi_hifiberry_dac], device 0: HifiBerry DAC HiFi pcm5102a-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0
Da das originale Testscript für Raspbian ausgelegt ist und unter ArchLinux nur bedingt funktioniert, kann der abschließende Test auch manuell erfolgen
[root@alarmpi ~]# cd /tmp [root@alarmpi tmp]# wget http://www.hifiberry.com/files/sin1000_48khz.wav ... [root@alarmpi tmp]# aplay sin1000_48khz.wav
Hat alles geklappt, sollte nun ein Testsignal ertönen, ansonsten geht es auf die Fehlersuche – am besten mit einem Multimeter.
Optional: Initiallautstärke setzen
Da für HiFiBerry keine hardwaremäßige Lautstärke-Konfiguration (z.B. über „alsamixer“) existiert, ist es u.U. erforderlich, die softwaremäßige Initiallautstärke von gstreamer zu verändern. Hierzu sind zwei Änderungen notwendig:
Als erstes wird eine Variable entsprechend den beiden vorhandenen „friendly“ und „uuid“ in der Datei „/etc/conf.d/gmediarender“ gesetzt, die Werte und deren Auswirkungen können der Dokumentation entnommen werden.
[root@alarmpi ~]# cat /etc/conf.d/gmediarender #Friendly Name to display to network devices friendly=hifi-pi gMedia UPnP Renderer #UUID #Change this to make different players unique uuid=90aba109-6333-4669-85d1-d9316244f7f9 #initial volume initvolume=-6
Als zweites muß diese Variable im Initscript „/etc/systemd/system/multi-user.target.wants/gmediarender.service“ eingetragen werden:
[root@alarmpi ~]# cat /etc/systemd/system/multi-user.target.wants/gmediarender.service [Unit]
Description=UPnP renderer using gstreamer
After=network.target
[Service]
Type=forking
EnvironmentFile=/etc/conf.d/gmediarender
ExecStart=/usr/local/bin/gmediarender -f "${friendly}" --gstout-initial-volume-db=${initvolume} -u "${uuid}"-d
[Install]
WantedBy=multi-user.target
Wichtig ist, darauf zu achten, daß beim Parameter „gstout-initial-volume-db“ KEINE Anführungszeichen verwendet werden, da es sich hierbei um einen numerischen Wert und keinen String handelt.
Fehlersuche
Als erste Maßnahme empfiehlt sich, die Kontakte von der Unterseite des Raspberry Pi zur Oberseite des HifiBerry zu kontrollieren. Dies kann bei ausgeschaltetem Raspberry erfolgen.
Führt dies zu keinem Ergebnis, ist als nächstes eine Überprüfung der GPIO-Schnittstelle dran, für deren Grundlage z.B. die GPIO-Übersicht von mikrocontroller.net dienen kann.
Ein erster Test sollte das Anliegen der +5V und +3.3V am p5-Anschluss sicherstellen, bevor dann die Pins 28 bis 38 einzeln nach folgendem Schema geschaltet und überprüft werden können:
echo 28 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio28/direction echo 1 > /sys/class/gpio/gpio28/value
Nach der Konfiguration als Ausgang sollte an dem jeweiligen Pin eine Spannung von 3.3V anliegen.
Ist dies nicht der Fall, so sollten die entsprechenden Lötstellen überprüft werden. Mit etwas Pech liegt auch ein Defekt am Raspberry Pi selbst vor – beim ersten hier eingesetzten Modell ließ sich Pin29 nicht zur Zusammenarbeit überreden.