Technik
Blog Wiedner Al-Dujaili
Kategorien
Blog abonnieren
Verwaltung des Blogs
Powered by
Getaggte Artikel
17. Jan: ufw: unnecessary firewall
16. Jan: Big Blue Button, ufw und container
Since a few weeks, I rented a server for running Big Blue Button. Besides Jitsi Meet, Big Blue Button is one of the most feature rich free software video conferencing solutions.
Also, Big Blue Button is a bolted mess of many components running barely in any other environment than the one the developers intended. Actually, it's barely running. 
To be fair, there are a lot of components involved. And there aren't many developers having the necessary insights, so progress is slow. Until a few weeks ago BBB had to be run on Ubuntu 16.04 Xenial, but they now have their install script adapted to Ubuntu 18.04 Bionic. Well, we are in 2021 already and a lot of people expect to be able to install BBB on Ubuntu 20.04 Focal. But as I said, progress is slow.
As there are many components, the team strongly recommends to firewall the server. Everyone does that, doesn't they, mh? Well, they decided to use ufw for that. That wouldn't be a problem if I didn't have the idea to setup some additional containers on the machine to make it a little bit more useful.
When mentioning containers almost everyone thinks of docker containers but there are at least two more technologies available on Linux. The aptly named lxc (Linux Containers) and systemd's approach nspawn. As the whole world uses docker and one of my favourite (ex) colleagues prefers lxc I decided to have some fun with nspawn. But I guess many of the problems I had would also appear with lxc or docker.
Actually, BBB makes use of some docker containers so that might have increased my problems but I'm not sure about that as no solution or workaround needed touching their config. I guess, their presence just made my problems seem more complex than they actually were.
The symptoms I observed were simple: My containers didn't get any IP. They had no network connectivity.
The main culprit of course was ufw. BBB's default firewall rules only allow ssh, http, https and a range of ports needed for WebRTC. ufw blocked all traffic from the containers, including DHCP. So I needed to allow DHCP. I wrote an application profile for that but that's mostly unnecessary as we only need to open TCP ports 67 and 68.
ufw allow 67:68/tcp
And my containers got their IP addresses!
But they still couldn't do anything. Okay, I could ping other IP addresses.
ping 8.8.8.8
Call me spoiled, but I'd expect ICMP to be blocked if default policy is to reject. But hey, I was thankful to see that something works at least. But name resolution didn't work. Allowing port 53 analoguosly didn't help. I could tcpdump my packets not reaching the bridge interface. The solution was to allow forwarding packets to this port:
ufw route allow 53
And now, name resolution worked. I left out the steps inbetween (I changed the default forward policy and reset it afterwards). That means I could ping by providing a hostname. Progress! But I couldn't curl. Not only because I had to install the curl package but also because the only open ports for my containers were … let me count … oh, port 53.
ufw route allow 80,443/tcp
And now I can curl.
Of course, there's room for improvement. I could limit the rules to my container subnet or even to single containers. But this last idea is doomed to fail because of DHCP. So I could still limit the forwarding rules to my subnet. As they are only valid for forwarding and I want to forward only to my containers there doesn't seem to any benefit in adding more complexity.
I guess I got all the search terms into this entry I tried while searching for a solution to my problem without getting any concrete results. Maybe someone in the same situation as me might find this helpful.
29. Okt: Mac-Hardware und Webcamvergleich
Eine Sache, die mir seit einigen Wochen im Kopf herumschwirrt: Apple und Hardware. Und Webcams, gerade die waren der Auslöser.
Apples Hardware wird ja viel gelobt, zehrt aber eher von dem Ruf, den sich Apple in den frühen 10er Jahren erworben hat. Ich habe in den vergangenen Jahren mehrfach schon den Kopf schütteln müssen, wie lausig teilweise die Qualität ist (Tastatur, Netzteil).
Auf der anderen Seite gibt es Komponenten, die herausragend sind, die ich auch einmal erwähnen muss:
- Das Trackingpad, Touchpad, wie auch immer ihr es nennen wollt. Es reagiert präzise und Klicks werden eigentlich immer akzeptiert. Die Multitouch-Funktionen sind zwar eher eine Softwareangelegenheit, aber sie sind tadellos umgesetzt.
- Die Lautsprecher. Nicht, dass ich damit eine Party beschallen wollen würde, aber Sprache und Musik kommen klar, ohne zu klirren, ohne deutlich erkennbare Fehler im Frequenzverlauf. Üblicherweise gebe ich nichts auf Lautsprecher in Laptops, weil sie meist einfach Mist sind. Bei dem Macbook Pro 2015, was ich seit Februar nutze, sind sie ihren Aufgaben komplett gewachsen.
- Das Mikrofon. So oft lese ich von miesen Mikros bei Webcams, dass ich tatsächlich sehr angenehm angetan davon bin, dass das Mikro vom Macbook mehr als nur brauchbar ist.
- Zu guter Letzt die verbaute Webcam. Ich habe hier ein Sammelsurium an verschiedenen Laptops von Lenovo und Dell sowie auch eine externe Logitech. Alle stinken sie ab gegenüber der Apple-Webcam. Ich dachte, es könne ja nicht so schwer sein, eine gute Webcam nachzukaufen (die Logitech C720 habe ich vor gefühlt 10 Jahren für 30€ gekauft). Pustekuchen. Kleine Kameramodule von sehr brauchbarer Qualität werden zu hunderten Millionen in Smartphones verbaut, aber der Markt für Webcams ist überschwemmt von billigen Chinawebcams und wird dominiert von … Logitech. Besagte C720 ist im Vergleich zur Macbook-Webcams Mist. Bei WMDE haben wir zwei Logitech Meetup in Betrieb genommen, die bei Tageslicht ganz brauchbar sein mögen, aber nur einen digitalen Zoom bieten (für an die 1000€!), wo dann alles recht matschig aussieht. Immerhin 4k, aber so recht hat mich Logitech nicht überzeugt. Aber es gibt kaum andere Anbieter.
Also habe ich mich auf das Abenteuer "unbekannte Hersteller" eingelassen und mir eine "Papalook Webcam HD 1080p" bestellt.
Nach den ersten Tests habe ich sie wieder eingepackt und bei Amazon die Rücksendung beauftragt. Dann stolperte ich über Rezensionen, die der Kamera eigentlich gute Leistung quittierten. Also wieder ausgepackt und an den Parametern gedreht. Und siehe da!: Mein ursprüngliches Problem, dass die Kamera nur 5fps bei Full-HD liefert, lässt sich beheben, wenn ich von der Kamera ein anderes Farbmodell anfordere.
Jetzt waren in OBS die Farben aber immer noch sehr blass und meine Stirn komplett weiß. Aber durch ein bisschen Googeln stieß ich auf einen Artikel, wo die möglichen Parameter (nicht spezifisch Papalook) mal ein wenig erklärt werden. Belichtungskorrektur runter, Helligkeit rauf, Weißabgleich für Kunstlicht einstellen, und das Bild sah gleich deutlich besser aus.
Durch noch ein bisschen mehr Finetuning habe ich dann ein recht ansehnliches Bild bekommen.
Apple, so scheint mir, hat einfach mal sehr gute Voreinstellungen für die technisch immer noch bessere Webcam mitgeliefert. Soll mir recht sein.
Unter Linux muss ich halt ein wenig mehr Hand anlegen. Skeptisch hatte mich gemacht, dass guvcview (Gnome (oder GTK) UVC Viewer (UVC steht für USB Video Class, eine generische Schnittstelle, um Videogeräte per USB zu verbinden)) ein besseres Bild anzeigte als OBS. Und es waren eben besagte Parameter, an denen ich schrauben musste. Jetzt klappt es auch mit dem Chroma-Key und dem Greenscreen.
Die im Laptop verbaute Webcam wirkt auch bei direkter Kontrolle der Bildparameter matschig und als hinge ein Grauschleier davor.
Meine Lehre jedenfalls ist, dass Apple nicht unbedingt überteuerte Hardware anbietet. Sie bieten Hardware an, wo keine Komponente nur mitgeliefert wird, um eine Checkbox auf der Featureliste abzuhaken. Ich persönlich würde mir ja wünschen, dass mehr Hersteller darauf verzichten, Alibi-Hardware zu verbauen.
Übrigens habe ich es auch mit meinem Handy probiert. Aufmerksame Leser*innen wissen ja, dass ich ein Pixel 3a habe, was dank Google mit die beste Bildqualität liefert. Warum nicht deren Bild anzapfen und als Webcam nutzen? Klar doch: IP Webcam installiert und gestartet, Stream in OBS eingebunden … die Qualität war nochmal deutlich besser als die von Apple-Hardware, keine Frage. Bei meinem ersten Versuch schaltete sich das Handy nach einer halben Stunde ab wegen Überhitzung. Das konnte ich beheben, indem ich es ohne Hülle im Stativ betrieb. Das Stativ allerdings klemmte immer irgendwelche Tasten – die Kamera konnte ich damit nicht mittig im Lichtring ausrichten. Kein Beinbruch, nur halt nicht schön. Schlimmer ist, dass die IP-Verbindung zwischen Laptop und Smartphone nicht reibungslos lief. Schon beim zweiten Einsatz ließ sich der Streamserver auf dem Smartphone nicht mehr finden, so dass meine OBS-Konfiguration ins Leere lief. Für mich war das Anlass, mich mal nach guten, externen Webcams umzuschauen. Aber der Markt ist sehr unübersichtlich. Ich muss mir keine Webcam kaufen, die nur marginal besser als die im Laptop verbaute ist. Mit der Neuanschaffung kann ich zumindest wieder halbwegs meinen Spaß an der nächsten Videokonferenz haben.
Was ich mir wünschen würde: Wenn Webcam-Hersteller einfach mal die Kamera-Hardware von zumindest ordentlichen Smartphone-Kameras verbauen würden. Muss ja nicht gleich Huawei-P30-Niveau sein. Ich fürchte aber, ohne die Nachbearbeitung durch die Software liefern auch deren Kameras nur mäßige Ergebnisse. Logitech und Co. liefern ja für Windows (und manchmal auch macOS) Software mit, die das Kamerabild nachbearbeiten. Als Linux-Nutzer stehe ich ohne da und muss selbst Hand anlegen. Spätestens wenn es allerdings um machine learning und KI bei der Bildaufbereitung geht, ist da jedoch bislang Schluss.
---
Anlass ist übrigens Rollenspiel via Zoom.
"Aber Masin, wenn die Apple-Webcam so toll ist, warum nimmst du dann nicht den Laptop?"
Für mein Privatvergnügen möchte ich nicht Zoom auf meinem Arbeitsgerät installieren, da Zoom in der Vergangenheit durch grobe Patzer gerade unter macOS aufgefallen ist. Immerhin hat die öffentliche Aufmerksamkeit in den vergangenen Monaten dazu geführt, dass Zoom schon kräftig nachgebessert hat. Ich würde gerne auf Zoom verzichten, aber meine Spielrunde hat sich darauf eingeschossen.
---
Auf Facebook kommentierte dann ein Leser, dass ich ja eine semiprofessionelle Kamera per HDMI einbinden könne.
Auch das war eine Überlegung zwischendurch, eine reguläre Kamera zu benutzen. Da gibt es grundsätzlich ja zwei Ansätze.
Ich erinnere mich, wie ich irgendwann um 2005 herum mal einen Skype-Testanruf bei einem Freund gemacht habe, ob er mich hören könne. Ging, aber er entschuldigte sich, dass er kein Headset und auch kein Mikro da habe. Merkwürdigerweise hörte ich trotzdem Tastenklappern und Atmen. Stellte sich heraus, dass sein Camcorder, der per Firewire angebunden war, sein Mikro direkt dem Betriebssystem angeboten hat. Bild hatten wir nicht probiert, aber wir waren sehr erstaunt, dass das überhaupt ging.
Der erste Ansatz wäre also, die Kamera per USB anzuschließen und die Signale auf dem Weg abzugreifen. Wir haben hier noch eine alte Kompaktknipse, mit der ich das probiert habe, aber ohne Erfolg. Ich erinnerte mich, dass Darktable zur Steuerung von Digitalkameras genutzt werden kann, und recherchierte mal, wie die das machen und welche Unterstützung es da gibt. Darktable nutzt libgphoto2, und libgphoto2 hat eine sehr praktische Seite der unterstützten Kameras und ihrer Features. Ich kann davon ausgehen, dass ich eine Kamera brauche, wo "Liveview" vermerkt ist. Zwar bieten immer mehr Hersteller Software an, um ihre Kameras als Webcam nutzen zu können, aber die Firmware der Kamera wird das wohl überhaupt anbieten müssen. Ich gehe davon aus, dass das so semi-standardisiert ist und die Liste ziemlich erschöpfend ist. Nur falls jemand eine Entscheidungshilfe braucht.
Vor der neuen Webcam hatte ich billig in einem Sonderangebot eine kleine 4k-Actioncam von Crosstour erworben, eben in der Erwartung, dass da ein Liveview möglich sei (ich wusste zu dem Zeitpunkt noch nix von o.g. Tabelle). Aber die ausgelieferte Firmware hat das Feature nicht mehr, obwohl es noch in der Anleitung steht, glaube ich. Zumindest in Anleitungen, die man online noch herunterladen kann. Es gibt über Umwege eine alternative Firmware, aber sie erlaubt nur HD-Betrieb als Webcam (720p). Sie spannt aber ein Wifi-Netz auf, wo dann das Kamerabild als Stream abzugreifen ist. Das stellt mich nur vor das Problem, gleichzeitig in zwei WLANs zu sein. Für mich ist das nicht praktikabel. HDMI-Anschluss hat sie auch noch – das wäre noch eine Möglichkeit.
Und damit kommen wir zum zweiten Ansatz, den mein Leser auch vorschlug, eben das Kamerabild per HDMI zu capturen. Die dafür notwendige Capturecard habe ich bislang nur so ab 70€ gesehen, empfohlen wird aber wohl Elgatos Camlink ab ca.130€. Ich habe bei Amazon gerade Capture-Sticks ab 14€ gesehen. Für den Preis probiere ích das mal aus. Wahlweise mit der Actioncam oder mit der Kompaktknipse, wobei ich nicht weiß, ob sie HDMI ausspuckt, ich glaube aber schon. Sollte das gehen, würde es meine Optionen zumindest deutlich ausweiten.
Mittlerweile verfolge ich das Vorhaben ja hauptsächlich nur noch aus Spaß an der Freude, nicht um Ergebnisse zu erzielen.
Ich hatte gestern mal wieder meinen Dell-Laptop Latitude E6430 angeworfen und dachte mir, ich schau mir dessen Kamerabild nochmal an. Eigentlich hatte ich ihn deswegen nicht benutzt, weil er doch nicht das stärkste Pferd im Stall ist (Intel Core i5-3230M CPU @ 2.60GHz). Es ist gerade Abend, Katja hat das Licht da angemacht, wo wir üblicherweise unsere Remote-P&P-Runde aussitzen – die Lichtverhältnisse sind vergleichbar.
So schlecht ist die Webcam da tatsächlich nicht, wie ich sie oben beschrieen habe. Vermutlich weil es ein Businessgerät ist.
Ich nutzte die Gelegenheit und habe mal alle anderen verfügbaren und in Frage kommenden Gerätschaften durchgetestet:
| Dell Latitude E6430 | Apple Macbook Pro 2015 |
 |
 |
| Logitech HD C720 | Papalook HD 1080p |
 |
 |
| Crosstour Actioncam 4k | Lenovo Ideapad Y700 |
 Leicht andere Perspektive, da ich meinen Platz auf dem Sofa in der Zwischenzeit räumen musste. Für eine 720p-Kamera ist das Bild eigentlich nicht soooo schlecht. Nachteil ist natürlich, dass es sich um eine Fix-Fokus-Kamera handelt, andererseits ist der Fokusbereich groß genug, will ich meinen. Gewöhnungsbedürftig ist der Kisseneffekt wegen Weitwinkellinse. |
 Das ist der Rechner, der genug Leistung hat, um sich neben der Videokonferenz noch zu langweilen (Intel Core i7-6700HQ CPU @ 2.60GHz). Die Kamera ist indiskutabel schlecht. |
| Lenovo Ideapad U330p | Lenovo Thinkpad X230 |
 Erstaunlich finde ich, dass die Webcam besser ist als die vom Y700, was mehrere Jahre später auf den Markt kam. Trotzdem nur vorletzter Platz in meinem persönlichen Ranking. |
 Von den Lenovo-Laptops zeigt das X230 definitiv die beste Qualität, gleichauf mit dem Macbook, wenn auch mit weniger intensiven Farben. |
| Google Pixel 3a Frontkamera | Google Pixel 3a Hauptkamera |
 Es gibt kein Szenario, in dem diese Kamera zum Einsatz kommen würde fürs gemütliche Rollenspiel per Videokonferenz. Sie ist nur der Vollständigkeit halber aufgeführt. Man beachte, dass sie besser ist als praktisch jede integrierte Laptop-Webcam in einem Smartphone, dass bei Markteinführung für 400€ über den Ladentisch ging. |
 Ohne Blick auf den Monitor ist es ganz schön schwer, sich selbst zu knipsen. Hat für den ersten Versuch aber ganz ordentlich funktioniert. Ich denke, die Bildqualität spricht für sich, warum ich versucht habe, sie als Webcam einzuspannen. |
| Lenovo Tab4 10plus | Panasonic Lumix DMC-TZ 6 |
 Hier sieht man, dass Lenovo nicht nur schlechte Kameras verbaut. Sie ist vielleicht nicht wirklich gut, aber im Vergleich zu den Laptop-Webcams ein echter Augenöffner. Die Teilnahme an der Videokonferenz mit dem Tablet ist aber eher unkomfortabel für zwei Personen. Dafür ist das Display dann doch zu klein. Außerdem lässt sich das Tablet in seiner Hülle nur begrenzt ausrichten. |
kommt noch |
| Apple iPhone 8 Frontkamera | Apple iPhone 8 Hauptkamera |
 |
 Irgendwie war es beim iPhone deutlich anstrengender, das Gerät falsch herum gegriffen zu bekommen. |
| Sony Playstation Eye | |
 Die Kamera ist alt. Sie meldet sich ja nicht mal als UVC-Gerät und braucht ein eigenes Kernelmodul. Aber sie schafft hohe Bildraten (60 Hertz). |
Mir ist noch zusätzlich ein Thinkpad in die Hände gefallen, das ich heute Abend mal testen kann, wenn die Lichtverhältnisse wieder vergleichbar sind. Außerdem habe ich ja noch mein Arbeits-iPhone, das ich zwar nie dafür verwenden würde, aber welches ich durchaus der Vollständigkeit einmal mit aufführen kann. Meine alten Nexusse (Nexen? Nexi?) und das Oneplus One werde ich mir aber ersparen.
Der billige USB-HDMI-Capture-Stick kommt heute. Ich mache mich dann mal auf die Suche nach dem Ladegerät. Die Beispielbilder werde ich oben nachreichen, weitere Gedanken hänge ich ggf. als Update markiert ans Ende des Beitrags.
Update 2020-10-29 19:00 Uhr
Mit dem Bild des Thinkpads würde ich ja sagen, die Grenze zwischen grottigen und akzeptablen Webcams verläuft zwischen Consumer- und Business-Geräten, wie auch bei vielen anderen Merkmalen. Die Erweiterbarkeit und Reparierbarkeit von Consumer-Geräten ist gegenüber Business-Geräten immer nachrangig. Die Bildschirme von Business-Geräten sind für längere Arbeitszeiten vorgesehen und nicht für den schnellen Reiz bei der Ausstellung in der Computerabteilung. Ich könnte mir noch die Mühe machen und mein HP-Compaq-Netbook aus der Schublade holen, aber allein die Vorstellung, den Bootvorgang zu durchstehen bereitet mir körperliche Schmerzen – ich gehe mal davon aus, dass die Webcam darin nur dem Haken auf der Featureliste diente.
Eigentlich punkten Consumer-Geräte nur bei einem Punkt: dem Preis. Gerne in Verbindung mit vermeintlich in harten Zahlen ausgedrückten Merkmalen wie Takt oder Massenspeicher. Ich rate schon seit Jahren dazu, lieber ein gebrauchtes Business-Gerät letzter oder vorletzter Generation zu kaufen statt eines neuen Consumer-Geräts. Viele nicht so offensichtliche Merkmale machen deren Benutzung und Besitz um einiges angenehmer.
Ich will nicht verschweigen, das gebrauchte Business-Geräte womöglich doch den einen oder anderen Nachteil haben dürften. So werden sie wahrscheinlich dicker oder schwerer sein, der Akku wird Alterungsspuren aufweisen, und überhaupt kann eine CPU der letzten oder vorletzten Generation und ihre dazugehörige Hardware stromhungriger sein.
18. Mär: KeePassXC-Features, die mehr Beachtung verdienen: Multiple URLs, Sharing, AutoOpen
(Anm. d. Autors: Dies ist die zweite Fassung, nachdem die erste im Cache des Browsers verloren ging. Es kann meiner Ungeduld angelastet werden, wenn der Text irgendwo inhaltliche Sprünge macht. Sie waren in der ersten Fassung nicht vorhanden. 
)
Multiple URLs
Sharing
AutoOpen
25. Dez: Die schöne neue Musikstreamingdienstwelt ist eine Playlisthölle
.
indest steht Amazon Music auf der Roadmap. Bringt mich jetzt also auch nicht weiter.10. Feb: Erlösung und Algorithmen
3. Okt: Raspberry Pi als Netzwerk- und Bluetooth-Audiogerät (Teil 1)
If you are interested in an english version of this post just ask in the comments. Almost all of the instructions I used for this blog post were in english anyway so there might not be that much use for an english version.
Seit zwei Jahren spiele ich mit dem Gedanken, einen Raspberry Pi als Netzwerk- und Bluetooth-Audiogerät zu konfigurieren, um die alte Mini-Kompaktstereoanlage von Technics im Wohnzimmer mal ins aktuelle Jahrzehnt zu holen. Zu diesem Zweck habe ich mir damals einen Raspberry Pi 2 B und ein Hifiberry DAC+-Board inkl. passendem Gehäuse besorgt. Der Spaß hat zusammen 70 bis 80 € gekostet – je nach Anbieter kann der eine oder andere Euro gespart werden.
Heute würde ich für meinen Anwendungsfall sicher nicht zum 2 B greifen, sondern eher zum Zero W, der Bluetooth und WiFi bereits eingebaut hat. Für 30 € gibt es ein Starterset mit vorbestückter GPIO-Stiftleiste und Netzteil sowie Adaptern. Der passende Hifiberry DAC+ Zero kostet auch nur 15 €. Mit 45 € plus den Kosten für ein passendes Gehäuse liegen die Kosten doch deutlich niedriger.
Meinen 2 B habe ich mit einem USB-Wifi-Adapter und einem Bluetooth-Adapter aus Restbeständen ergänzt. Dafür müssten auch noch so 10 € eingeplant werden, müssten die gekauft werden. Eine passende Micro-SD-Karte ist auch für ein paar Euro zu haben. Ich habe eine mit 2 GB Kapazität genommen, die ich noch da hatte. Vermutlich noch aus einem meiner frühen Nokia-Smartphones.
Warum nicht den Audioausgang des Pi benutzen? Der verbaute DAC des Pi ist von so grausamer Qualität, dass so manches Telefon der Deutschen Post im Vergleich als Hifigerät gelten kann.
Warum überhaupt ein Hifiberry? Sicher wäre auch eine USB-Soundkarte gegangen. Sieht halt nur nicht schick aus. Schon der Wifi-Adapter ist eher hässlich.
Anforderungen 2015
Mein Audiogerät soll folgende Anforderungern erfüllen:
- Pulseaudio im Netzwerk bereitstellen
- Bluetoothaudio entgegennehmen und ausgeben
- Audio per DLNA abspielen
- sich als Element einer Multiroom-Lösung auf Pulseaudio-Basis verhalten
Erster Versuch
Zu meinem Unglück musste ich 2015 feststellen, dass Raspbian –die offizielle Distribution von der Raspberry Pi Foundation basierend auf Debian– leider ein 4-GB-Medium erfordert. Ich versuchte mein Glück also erstmal mit Arch Linux ARM. Neben der Tatsache, dass es auf ein Datenträger deutlich kleiner als 4 GB passt, fand ich die Installation auch viel angenehmer, da ich dabei das Gefühl von mehr Kontrolle hatte. Für Anfänger ist das aber sicherlich nichts, auch wenn die Anleitung wenig Raum für Fragen lässt. Ein Showstopper mag sein, dass die Anleitung voraussetzt, dass ein laufendes Linux-System benutzt wird.
Bevor das hier jetzt ausufert: Aus dem Audioausgang kam nur furchtbare Statik. Nix zu machen. Nada.
Glücklicherweise stieß ich während meiner Websuche auf Minibian. In der Hoffnung, dass ich mir nach der Installation selektiv die Pakete nachinstallieren kann, die ich für mein Projekt brauche, habe ich es damit probiert. Minibian produzierte kein Rauschen – die Hardware schien also nicht kaputt zu sein. Beruhigend.
Tatsächlich klappte es außergewöhnlich einfach, Pulseaudio so zu konfigurieren, dass es Audio aus dem Netzwerk entgegennimmt – genau, was ich mir heutzutage von modernen Systemen erhoffe. Bluetooth wollte aber partout nicht funktionieren. Nach tagelanger Recherche schob ich die Schuld einfach darauf, dass Minibian sich doch irgendwie susbtantiell von einem regulären Raspbian unterscheidet.
Aus Gründen, die mir nicht mehr einfallen wollen, kam mein Vorhaben erstmal zum Erliegen. 2016 schob sich dann ein Retropie-Vorhaben dazwischen (funktioniert auch wunderbar). Und vor zwei Wochen wollte ich dann mal wieder loslegen.
Nächster Versuch
Zwei Jahre später kann ich ja mal wieder Arch Linux ARM ausprobieren, dachte ich mir. Was auch immer damals schiefgegangen war – vielleicht wurde es ja ausgebügelt.
Installation Hifiberry
Hifiberry stellt eine allgemeine Installationsanleitung zur Verfügung, die auch für Arch Linux ARM gilt. Meine /boot/config.txt sieht danach folgendermaßen aus:
# See /boot/overlays/README for all available options gpu_mem=64 initramfs initramfs-linux.img followkernel dtoverlay=hifiberry-dacplus
Je nach Modell des Hifiberry muss natürlich ein anderes Overlay eingefügt werden. Das reicht dann auch bereits schon aus, um dem Hifiberry nach einem Neustart Töne zu entlocken.
Konfiguration Pulseaudio
Als erstes müssen ein paar Pakete installiert werden:
[root@alarmpi ~]# pacman -S pulseaudio pulseaudio-zeroconf pulseaudio-bluetooth
Das Zeroconf-Paket dient dazu, damit Pulseaudio per Avahi im Netzwerk seine Dienste anbieten, das Bluetooth-Paket sorgt dafür, dass Pulseaudio den Audioeingang per Bluetooth via BlueZ erstellen kann.
Entgegen aller Ratschläge im Web wird Pulseaudio als Systemdienst betrieben. Üblicherweise wird der Pulseaudio-Dämon als Benutzer-Dämon betrieben, aber der Audio-Pi soll ja ohne Benutzer-Anmeldung ganz stupide Audio entgegennehmen und auf dem Audioausgang des Hifiberry ausgeben. Auf einem regulären Desktop oder Laptop sollte das tatsächlich nicht so gemacht werden.
Damit Pulseaudio als Systemdienst starten kann, braucht systemd eine Datei namens bspw. /etc/systemd/system/pulseaudio.service:
[Unit] Description=PulseAudio system server [Service] ExecStart=/usr/bin/pulseaudio --system --disallow-exit --log-target=journal #ExecStart=/usr/bin/pulseaudio --system --disallow-exit --disallow-module-loading --log-target=journal ExecReload=/bin/kill -HUP $MAINPID [Install] WantedBy=multi-user.target
Solange die Konfiguration nicht finalisiert ist, bleibt --disallow-module-loading auskommentiert. Wenn Pulseaudio als Systemdienst betrieben wird, braucht es einen Nutzer namens pulse und zwei Gruppen, pulse und pulse-access:
[root@alarmpi ~]# groupadd --system pulse [root@alarmpi ~]# groupadd --system pulse-access [root@alarmpi ~]# useradd --system -g pulse -G audio -d /var/run/pulse -m pulse [root@alarmpi ~]# usermod -G pulse-access root [root@alarmpi ~]# usermod -G pulse-access alarm
Ich habe keine Ahnung, ob die beiden letzten Befehle wirklich notwendig sind, schaden tun sie aber auch erstmal nicht. Als nächstes wird verhindert, dass Pulseaudio bei Anmeldung eines Nutzers normal startet:
[root@alarmpi ~]# echo "default-server = /var/run/pulse/native" >> /etc/pulse/client.conf [root@alarmpi ~]# echo "autospawn = no" >> /etc/pulse/client.conf
Der Dienst kann jetzt enabled und gestartet werden:
[root@alarmpi ~]# systemctl daemon-reload [root@alarmpi ~]# systemctl enable pulseaudio.service [root@alarmpi ~]# systemctl start pulseaudio.service
Bevor alles funktioniert, wird Pulseaudio sicher noch ein paar Mal neu gestartet. Für die Konfiguration von Pulseaudio werden die Dateien system.pa und daemon.conf in /etc/pulse benutzt.
/etc/pulse/system.pa
#!/usr/bin/pulseaudio -nF # # This file is part of PulseAudio. # # PulseAudio is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # PulseAudio is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, see <http://www.gnu.org/licenses/>. # This startup script is used only if PulseAudio is started in system # mode. ### Automatically load driver modules depending on the hardware available .ifexists module-udev-detect.so load-module module-udev-detect tsched=0 .else ### Use the static hardware detection module (for systems that lack udev/hal support) load-module module-detect .endif ### Load several protocols .ifexists module-esound-protocol-unix.so load-module module-esound-protocol-unix .endif load-module module-native-protocol-unix ### Automatically restore the volume of streams and devices load-module module-stream-restore load-module module-device-restore ### Automatically restore the default sink/source when changed by the user ### during runtime ### NOTE: This should be loaded as early as possible so that subsequent modules ### that look up the default sink/source get the right value load-module module-default-device-restore ### Automatically move streams to the default sink if the sink they are ### connected to dies, similar for sources load-module module-rescue-streams ### Make sure we always have a sink around, even if it is a null sink. load-module module-always-sink ### Automatically suspend sinks/sources that become idle for too long load-module module-suspend-on-idle ### Enable positioned event sounds load-module module-position-event-sounds ### Customizations #load-module module-native-protocol-unix auth-anonymous=1 load-module module-zeroconf-publish load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.1.0/24 auth-anonymous=1 set-default-sink 0 #set-card-profile 0 stereo-fallback ### Automatically load driver modules for Bluetooth hardware .ifexists module-bluetooth-policy.so load-module module-bluetooth-policy .endif .ifexists module-bluetooth-discover.so load-module module-bluetooth-discover .endif
/etc/pulse/daemon.conf:
# This file is part of PulseAudio. # # PulseAudio is free software; you can redistribute it and/or modify # it under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # PulseAudio is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU Lesser General Public License # along with PulseAudio; if not, see <http://www.gnu.org/licenses/>. ## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for ## more information. Default values are commented out. Use either ; or # for ## commenting. ; daemonize = no ; fail = yes ; allow-module-loading = yes ; allow-exit = yes ; use-pid-file = yes ; system-instance = no ; local-server-type = user ; enable-shm = yes ; enable-memfd = yes ; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 MiB ; lock-memory = no ; cpu-limit = no ; high-priority = yes ; nice-level = -11 ; realtime-scheduling = yes ; realtime-priority = 5 ; exit-idle-time = 20 ; scache-idle-time = 20 ; dl-search-path = (depends on architecture) ; load-default-script-file = yes ; default-script-file = /etc/pulse/default.pa ; log-target = auto ; log-level = notice ; log-meta = no ; log-time = no ; log-backtrace = 0 ; resample-method = speex-float-1 resample-method = trivial ; avoid-resampling = false ; enable-remixing = yes ; remixing-use-all-sink-channels = yes ; enable-lfe-remixing = no ; lfe-crossover-freq = 0 flat-volumes = no ; flat-volumes = yes ; rlimit-fsize = -1 ; rlimit-data = -1 ; rlimit-stack = -1 ; rlimit-core = -1 ; rlimit-as = -1 ; rlimit-rss = -1 ; rlimit-nproc = -1 ; rlimit-nofile = 256 ; rlimit-memlock = -1 ; rlimit-locks = -1 ; rlimit-sigpending = -1 ; rlimit-msgqueue = -1 ; rlimit-nice = 31 ; rlimit-rtprio = 9 ; rlimit-rttime = 200000 ; default-sample-format = s16le ; default-sample-rate = 44100 ; alternate-sample-rate = 48000 ; default-sample-channels = 2 ; default-channel-map = front-left,front-right ; default-fragments = 4 ; default-fragment-size-msec = 25 ; enable-deferred-volume = yes ; deferred-volume-safety-margin-usec = 8000 ; deferred-volume-extra-delay-usec = 0
Nach einem Neustart von Pulseaudio
[root@alarmpi ~]# systemctl restart pulseaudio.service
finden andere Pulseaudio-Dämonen im Netz dann auch schon den Pi. Vielleicht müssen noch entsprechende Zeroconf-Pulseaudio-Pakete auf den jeweiligen Rechnern installiert werden, sollte der Pi nicht in der Liste der Audioausgabegeräte auftauchen.
Konfiguration Bluetooth
Bluetooth unter Linux kann einen in den Wahnsinn treiben. Als Lektüre dazu empfehle ich Bluez must be one of the best kept secrets in Linux und Bluez – greatest Linux mystery. Ohne ordentliche Dokumentation sehe ich leider auch kaum eine Möglichkeit, die letzten Bluetooth-Baustellen zu beseitigen.
Natürlich werden erstmal ein paar Pakete benötigt:
[root@alarmpi ~]# pacman -S bluez bluez-utils
Dann wird die /etc/bluetooth/main.conf bearbeitet:
[General] # Default adapter name # Defaults to 'BlueZ X.YZ' Name = wohn # Default device class. Only the major and minor device class bits are # considered. Defaults to '0x000000'. #Class = 0x000100 Class = 0x200420 # How long to stay in discoverable mode before going back to non-discoverable # The value is in seconds. Default is 180, i.e. 3 minutes. # 0 = disable timer, i.e. stay discoverable forever DiscoverableTimeout = 0 # How long to stay in pairable mode before going back to non-discoverable # The value is in seconds. Default is 0. # 0 = disable timer, i.e. stay pairable forever PairableTimeout = 0 # Automatic connection for bonded devices driven by platform/user events. # If a platform plugin uses this mechanism, automatic connections will be # enabled during the interval defined below. Initially, this feature # intends to be used to establish connections to ATT channels. Default is 60. #AutoConnectTimeout = 60 # Use vendor id source (assigner), vendor, product and version information for # DID profile support. The values are separated by ":" and assigner, VID, PID # and version. # Possible vendor id source values: bluetooth, usb (defaults to usb) #DeviceID = bluetooth:1234:5678:abcd # Do reverse service discovery for previously unknown devices that connect to # us. This option is really only needed for qualification since the BITE tester # doesn't like us doing reverse SDP for some test cases (though there could in # theory be other useful purposes for this too). Defaults to 'true'. #ReverseServiceDiscovery = true # Enable name resolving after inquiry. Set it to 'false' if you don't need # remote devices name and want shorter discovery cycle. Defaults to 'true'. #NameResolving = true # Enable runtime persistency of debug link keys. Default is false which # makes debug link keys valid only for the duration of the connection # that they were created for. #DebugKeys = false # Restricts all controllers to the specified transport. Default value # is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW). # Possible values: "dual", "bredr", "le" #ControllerMode = dual # Enables Multi Profile Specification support. This allows to specify if # system supports only Multiple Profiles Single Device (MPSD) configuration # or both Multiple Profiles Single Device (MPSD) and Multiple Profiles Multiple # Devices (MPMD) configurations. # Possible values: "off", "single", "multiple" #MultiProfile = off # Permanently enables the Fast Connectable setting for adapters that # support it. When enabled other devices can connect faster to us, # however the tradeoff is increased power consumptions. This feature # will fully work only on kernel version 4.1 and newer. Defaults to # 'false'. #FastConnectable = false # Default privacy setting. # Enables use of private address. # Possible values: "off", "device", "network" # "network" option not supported currently # Defaults to "off" # Privacy = off Enable=Source,Sink,Media,Socket [GATT] # GATT attribute cache. # Possible values: # always: Always cache attributes even for devices not paired, this is # recommended as it is best for interoperability, with more consistent # reconnection times and enables proper tracking of notifications for all # devices. # yes: Only cache attributes of paired devices. # no: Never cache attributes # Default: always #Cache = always [Policy] # # The ReconnectUUIDs defines the set of remote services that should try # to be reconnected to in case of a link loss (link supervision # timeout). The policy plugin should contain a sane set of values by # default, but this list can be overridden here. By setting the list to # empty the reconnection feature gets disabled. #ReconnectUUIDs=00001112-0000-1000-8000-00805f9b34fb,0000111f-0000-1000-8000-00805f9b34fb,0000110a-0000-1000-8000-00805f9b34fb # ReconnectAttempts define the number of attempts to reconnect after a link # lost. Setting the value to 0 disables reconnecting feature. #ReconnectAttempts=7 # ReconnectIntervals define the set of intervals in seconds to use in between # attempts. # If the number of attempts defined in ReconnectAttempts is bigger than the # set of intervals the last interval is repeated until the last attempt. #ReconnectIntervals=1,2,4,8,16,32,64 # AutoEnable defines option to enable all controllers when they are found. # This includes adapters present on start as well as adapters that are plugged # in later on. Defaults to 'false'. AutoEnable=true
Die wichtigen Dinge passieren in "Enable=" und ich habe keine Ahnung, warum "Source, Sink, Media" nicht ausgereicht hat. "Name=" ist frei wählbar – ich würde auf Sonderzeichen verzichten. "Class=0x200420" sagt an, dass der Bluetooth-Adapter sich als Car Audio System ausgeben soll (Quelle). Vermutlich gehen auch andere – hilfreich dabei dürfte der Bluetooth Class of Device (CoD) Generator sein. Auf der linken Seite einfach Audio oben und Audio unten auswählen, dann erscheint rechts eine Liste möglicher Minor Device Classes. Ich habe es erst mit 0x200428 probiert, aber ohne Erfolg, was aber wohl eher an den fehlenden DBus-Konfigurationen lag.
Konfiguration DBus
Unter Linux kommunizieren Prozesse untereinander auf verschiedenen Wegen, und DBus ist einer davon. Das ganze Setup erfordert, dass verschiedene Dienste unter verschiedenen Benutzerkonten miteinander sprechen dürfen.
/etc/dbus-1/system.d/pulseaudio.conf:
<?xml version="1.0"?> <!--*-nxml-*-->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<policy group="pulse">
<allow own="org.pulseaudio.Server"/>
</policy>
<policy context="default">
<allow send_destination="org.pulseaudio.Server"/>
<allow receive_sender="org.pulseaudio.Server"/>
</policy>
</busconfig>
/etc/dbus-1/system.d/pulseaudio-bluetooth.conf:
<busconfig>
<policy user="pulse">
<allow send_destination="org.bluez"/>
</policy>
</busconfig>
/etc/dbus-1/system.d/bluetooth.conf:
<!-- This configuration file specifies the required security policies
for Bluetooth core daemon to work. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- ../system.conf have denied everything, so we just punch some holes -->
<policy user="root">
<allow own="org.bluez"/>
<allow send_destination="org.bluez"/>
<allow send_interface="org.bluez.Agent1"/>
<allow send_interface="org.bluez.MediaEndpoint1"/>
<allow send_interface="org.bluez.MediaPlayer1"/>
<allow send_interface="org.bluez.ThermometerWatcher1"/>
<allow send_interface="org.bluez.AlertAgent1"/>
<allow send_interface="org.bluez.Profile1"/>
<allow send_interface="org.bluez.HeartRateWatcher1"/>
<allow send_interface="org.bluez.CyclingSpeedWatcher1"/>
<allow send_interface="org.bluez.GattCharacteristic1"/>
<allow send_interface="org.bluez.GattDescriptor1"/>
<allow send_interface="org.freedesktop.DBus.ObjectManager"/>
<allow send_interface="org.freedesktop.DBus.Properties"/>
<allow send_destination="org.bluez.Manager"/>
<allow receive_sender="org.bluez.Manager"/>
<allow send_destination="org.bluez.Adapter"/>
<allow receive_sender="org.bluez.Adapter"/>
<allow send_destination="org.bluez.Device"/>
<allow receive_sender="org.bluez.Device"/>
<allow send_destination="org.bluez.Service"/>
<allow receive_sender="org.bluez.Service"/>
<allow send_destination="org.bluez.Database"/>
<allow receive_sender="org.bluez.Database"/>
<allow send_destination="org.bluez.Security"/>
<allow receive_sender="org.bluez.Security"/>
</policy>
<policy at_console="true">
<allow send_destination="org.bluez"/>
</policy>
<!-- allow users of lp group (printing subsystem) to
communicate with bluetoothd -->
<policy group="lp">
<allow send_destination="org.bluez"/>
</policy>
<policy context="default">
<deny send_destination="org.bluez"/>
</policy>
</busconfig>
Das ist aus verschiedenen Quellen zusammengetragen. Falls jemand versteht, was die einzelnen Zeilen tun: Ich freue mich über Kommentare. Ich vermute, die Zeilen mit Bluetooth-Druckern sind überflüssig, aber es funktioniert so erstmal. In der verwendeten Anleitung fand ich den Hinweis, dass
[root@alarmpi ~]# systemctl restart dbus && systemctl restart polkit && systemctl restart systemd-logind
bereits reichen sollte, ein Neustart aber die sichere Variante sei. Wie jetzt über Bluetooth Audio empfangen kann, erkläre ich im Abschnitt "Baustellen".
Baustellen
Bluetooth-Kopplung
Der Audio-Pi sollte jetzt unter dem gewählten Namen, bei mir "wohn", per Bluetooth gefunden werden können. Mein Android-Tablet konnte jedenfalls erfolgreich ein Pairing durchführen. Aber: Eine Verbindung ist damit noch nicht möglich. Ich muss bislang auf der Kommandozeile bluetoothctl aufrufen und in der interaktiven Shell dann explizit trust <device bt mac> eingeben. Erst danach verbindet sich mein Tablet mit dem Pi und kann darüber dann auch Audio ausgeben. Angeblich solle dieser Schritt ausbleiben können, wenn eine PIN gesetzt würde. Ich habe aber nicht herausfinden können, wie ich meinen Pi mit einer PIN sichere. Ich würde ja so eine Alibi-PIN wie 0000 oder 1234 setzen – auch das fände ich dann noch hinreichend komfortabel. Idealerweise möchte ich aber komplett auf eine PIN verzichten – einfach paaren, verbinden, Audio abspielen. Aber die Dokumentation zu BlueZ ist verbesserungswürdig. Stark verbesserungswürdig.
DLNA
DLNA habe ich hier noch nicht konfiguriert. Ich hatte bei meiner 2015er-Recherche aber schon ein paar verständliche Anleitungen gefunden – es sollte also gehen. Wenn ich dann noch zusätzlich Video über den HDMI-Anschluss ausgeben könnte, wäre das ein netter Zuspieler für Fernseher.
MPD
Das ist neu in der Liste meiner Anforderungen. Bei meiner aktuellen Recherche stieß ich vermehrt auf Audioausgabe via MPD. Beim kurzen Überfliegen der Anleitungen sah das nicht so schwer aus. MPD-Clients gibt es auch für Smartphones, und was meine Auswahl an Software vergrößert, mit der ich Audio wiedergeben kann, ist mir immer willkommen. Ich finde ja, Bluetooth-Audio ist für Zwecke der Audio-Wiedergabe im Netz eher eine Krücke, wenn nichts anderes vorhanden ist, und nicht meine Wahl-Lösung.
Multiroom-Audiowiedergabe
Wenn ich bedenke, dass das mein ursprüngliches Anliegen war, dann habe ich bislang aber mächtig versagt. Mit Pulseaudio ist das aber wohl sehr einfach umzusetzen. Mir mangelt es im Moment natürlich ganz klar an weiteren entsprechende Audio-Pis, aber ich werde einfach demnächst mal meiner eigenen Pi-Zero-Kaufempfehlung folgen und mir noch zwei weitere Audio-Pis basteln. So finde ich auch den Hifiberry Amp+ sehr spannend, da ich darüber recht einfach einen regulären Lautsprecher netzwerkfähig bekommen könnte. Zu schade, dass es gerade den nicht im Zero-Format gibt, aber die zusätzlichen Verstärkerbausteine dürften einfach zu viel sein dafür, von den Anschlüssen ganz zu schweigen.
WLAN-Einbindung
Momentan macht der Audio-Pi nur LAN, obwohl der Wifi-Stick dranhängt. Ich muss also noch die WLAN-Konfiguration machen. Toll wäre natürlich, würde er ein eigenes Netz aufspannen, wenn kein bekanntes in der Nähe ist, um dann per Webinterface sein WLAN konfigurieren zu lassen.
Sobald ich Inhalt für Teil 2 habe, werde ich den hier auch verlinken. Im Moment reicht mir das von der Länge her. Wenn ich mir meinen zweiten Audio-Pi bastele, werde ich der Anleitung hier folgen und schauen, ob ich grobe Fehler gemacht habe, die ich dann natürlich korrigieren werde.
If you are interested in an english version of this post just ask in the comments.