Inkscape: Grafische Editoren, Beschreibungssprachen und ihre Tücken
Geschrieben von Masin Al-Dujaili am Friday, 11. June 2021 in Rollenspiel, Technik, Tischrollenspiel
Meine Erfahrungen mit Microsoft 365
Geschrieben von Masin Al-Dujaili am Friday, 29. January 2021 in Technik
ufw: unnecessary firewall
Geschrieben von Masin Al-Dujaili am Sunday, 17. January 2021 in Technik
Big Blue Button, ufw und container
Geschrieben von Masin Al-Dujaili am Saturday, 16. January 2021 in Technik
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.
Error: Assertion failed for PostgreSQL Cluster
Geschrieben von Masin Al-Dujaili am Monday, 11. January 2021 in Technik
If you ever encounter this error message
Assertion failed for PostgreSQL Cluster cluster-name
or
Assertion failed on job for postgresql@11-cluster-name.service
after creating a cluster of the name "cluster-name" it might be because somewhere the hyphen is considered invalid. Just
pg_dropcluster <version> cluster-name pg_createcluster <version> clustername
to drop and re-create the cluster without hyphen.
I created this blog entry because I could not find any reference to this specific error with this specific reason. It might be some Debian specific error as PostgreSQLs initdb command is wrapped by pg_createcluster which again isn't mentioned by PostgreSQL. Searching the web shows mostly results in context of Ubuntu and Debian.
Mac-Hardware und Webcamvergleich
Geschrieben von Masin Al-Dujaili am Thursday, 29. October 2020 in Technik
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.
KeePassXC-Features, die mehr Beachtung verdienen: Multiple URLs, Sharing, AutoOpen
Geschrieben von Masin Al-Dujaili am Wednesday, 18. March 2020 in Technik
(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
Die schöne neue Musikstreamingdienstwelt ist eine Playlisthölle
Geschrieben von Masin Al-Dujaili am Wednesday, 25. December 2019 in Technik
.
indest steht Amazon Music auf der Roadmap. Bringt mich jetzt also auch nicht weiter.Erlösung und Algorithmen
Geschrieben von Masin Al-Dujaili am Sunday, 10. February 2019 in Gesellschaft und Politik, Technik
Erlösung. Lasst uns über Erlösung reden. Damit meine ich die spirituelle Erlösung.
Kann es sein, dass des Menschen größte Erlösung ist, von der Verantwortung seines eigenen Treiben freigesprochen zu werden? Die Welt so erklärt werden kann, dass jeder und alle Gruppen, mit denen er sich identifiziert, frei von Schuld seien?
Aber ganz ohne Schuld geht es ja auch nicht, denn irgendwas Schlimmes passiert ja doch in der Welt, also braucht es Schuldige. Da man selber keine Verantwortung hat und demnach nicht Schuld sein kann –oder ist man nicht schuld und hat demnach keine Verantwortung?–, muss es jemand anders sein.
Spannend finde ich, dass es nie ohne Absicht geht. Es passiert was Schlimmes? Jemand _wollte_, dass dieses Schlimme passiert! Das kann wohl als böse bezeichnet werden, und die Person oder Gruppe als das Böse. Früher hielt noch der Teufel dafür her, heute sind es Verschwörer, die Geheimdienste, Juden (naja, das ist nicht neu), Rothschilds, Soros, das Kapital (alle drei als Stellvertreter für "die Juden") oder –ganz abgefahren– Aliens, Echsenmenschen, Hohlweltler.
Wie komme ich darauf? Deswegen.
YouTube announced they will stop recommending some conspiracy theories such as flat earth.
— Guillaume Chaslot (@gchaslot) 9. Februar 2019
I worked on the AI that promoted them by the *billions*.
Here is why it’s a historic victory. Thread. 1/https://t.co/wJ1jbUcvJE
Guillaume Chaslot beschreibt darin, wie der Empfehlungsalgorithmus von YouTube schon nach kurzer Zeit Verschwörungsphantasien befeuerte, weil einige wenige Intensivnutzer ihm beibrachten, dass darüber die Aufmerksamkeitszeit maximimiert werden kann. Und diese Videos bieten genau das an, was diese Zielgruppe offensichtlich am meisten ersehnt: Erlösung. Erlösung von der Last, selber an ihrem Zustand, der ihnen so viel Zeit auf YouTube beschert, schuld zu sein. Es sind natürlich Ausländer, Migranten und Flüchtlinge, die ihm die Arbeit wegnehmen und seinem Staat Fantastilliarden an Geld kosten, die ansonsten ihm zustünden. Es sind böse Ölmultis (Rockefeller, bestimmt auch Juden) und Echsenmenschen, die die Vermarktung seines Perpetuum Mobiles behindern. Es sind die Verschwörer der NWO und deren Geheimdienste, die Chemtrails versprühen und mittels HAARP jedwede selbstverständlich ihm innewohnende Brillianz und Grandesse unterdrücken.
Natürlich kann es sein, dass er oder sie vollkommen unverschuldet in diese Lebenslage gerutscht ist. Den Unterschied macht aber aus, ob er oder sie sich als Kollateralschaden wirtschaftlicher Umstände und Unglücke sieht oder als Opfer finsterer Machenschaften und Umtriebe.
Und YouTubes Empfehlungsalgorithmus bietet eben auch Erklärungen, die klar benennbaren Personen oder Gruppen die Verantwortung dafür zuschieben. Videos über Wirtschaftstheorie und -politik sind eben keine Hingucker.
Dieser Tweet bringt es auf den Punkt:
Huh, we were worried we’d build a paperclip maximizer, but instead we built an engagement maximizer, and it might be just as bad.
— Filippo Valsorda (@FiloSottile) 10. Februar 2019
Falls jemanden die Anspielung nicht auffällt, sie stammt hierher: "Suppose we have an AI whose only goal is to make as many paper clips as possible. The AI will realize quickly that it would be much better if there were no humans because humans might decide to switch it off. Because if humans do so, there would be fewer paper clips. Also, human bodies contain a lot of atoms that could be made into paper clips. The future that the AI would be trying to gear towards would be one in which there were a lot of paper clips but no humans." ( Nick Bostrom, as quoted in "Artificial Intelligence May Doom The Human Race Within A Century, Oxford Professor Says")
Die gute Nachricht ist, dass Google wohl jetzt an der Stellschraube dreht, mit der beständig neue Süchtige nach Erlösung geschaffen wurden. Wir werden sehen, welche Auswirkungen das hat.
LineageOS auf Oneplus One (bacon) installieren
Geschrieben von Masin Al-Dujaili am Sunday, 29. October 2017 in Technik
Hürden
Vorbereitung
Netterweise stellen die Leute von LineageOS auch eine leichtverständliche Anleitung zu Verfügung.
Hintergrund
An der Stelle kann ich mal kurz erläutern, warum ich das überhaupt auf mich nehme. Seit September 2016 hat das OPO keine Updates mehr bekommen. Das war auch ungefähr der Zeitpunkt, als Cyanogen Inc. beschlossen hat, den Betrieb und die Weiterentwicklung ihres Cyanogen OS einzustellen. Schon vorher fiel Cyanogen Inc. durch fragwürdige Geschäftsentscheidungen auf:
- Exklusive, wenn auch zeitlich befristete Vertriebsrechte für einen indischen Smartphone-Hersteller für Cyanogen OS in Indien, was Oneplus als early supporter verärgerte.
- Einführung von Microsoft-Apps in das System-Image von Cyanogen OS.
- Entwicklung von "MOD ready", einer Infrastruktur im OS, um Bestandteile durch Komponenten anderer Anbieter austauschen zu können
Das alles hinterließ einen schalen Nachgeschmack zu einem Produkt, das zu großen Teilen auf dem Engagement der Community beruht, die sich um Emanzipation ihrer Nutzer*innen bemüht. Der Name Cyanogen jedenfalls erschien der Community derart beschädigt, dass sie das Community-Projekt CyanogenMod zu LineageOS umbenannten. Cyanogen Inc. ist jedenfalls nicht mehr, und damit sind auch eventuelle Updates eher fragwürdig, zumal Oneplus sicher mehr Interesse daran hat, ihr hervorragendes Oneplus 5 (und bald 5T) zu verkaufen.
An der Stelle wäre es interessant mal zu recherchieren, wie Wileyfox mit dem Cyanogen-Debakel umgegangen ist. Kolleg*innen haben mir berichtet, dass die Swifts (1. Generation) noch Updates auf Android 7.0 oder 7.1 bekommen hätten, die aber sicher nicht von Cyanogen Inc. stammen konnten. Aber auch auf den Swifts hat sich LineageOS 14.1 als bessere Wahl herausgestellt.
Zwei meiner Motivationen sind aber KRACK, ein Angriff auf die WiFi-Verschlüsselung WPA2, für die LineageOS seit Mitte Oktober wohl Patches eingespielt hat, und BlueBorne, ein Angriff auf Bluetooth, der entfernte Code-Ausführung allein über aktiviertes und sogar ungepaartes Bluetooth ermöglicht, was bei LineageOS seit Anfang Oktober gepatcht ist. Ist ersteres vielleicht nur eine theoretische Bedrohung, ist zweiteres komplett fahrlässig zu ignorieren.
Weiterhin gibt es ein paar Ärgernisse, die ich hoffe behoben zu sehen:
- Das OPO versucht ständig Kontakt zum sog. Cyanogen-Konto aufzunehmen, dessen Server aber längst abgeschaltet ist. Selbst mit deaktiviertem "Sicherheit->Geräteadministrator" von Cyanogen belastet das den Akku.
- Wenn der Massenspeicher des OPO voll läuft, so ab 80 bis 90 Prozent Belegung, scheitern nicht nur Bluetooth-Verbindungen häufiger mal, das Gerät vergisst auch Paarungen.
- Bluetooth selber frisst im Leerlauf enorm viel Akkukapazität. Der Unterschied über Nacht ist ungefähr 100 → 85 Prozent zu 100 → 45 Prozent. Ich kann mich ehrlich gesagt nicht daran erinnern, dass das anfangs auch so war. Ich vermute ja, das letzte Cyanogen-OS-Update hat diesen Regress mitgebracht.
- Das Mikrofon wird offensichtlich stummgeschaltet, wenn ich beim Telefonieren auf freisprechen schalte. Das war anfangs ganz sicher nicht der Fall.
Durchführung
Heute geht es hier um LineageOS auf dem OPO, weswegen ich den Umzug der Authenticator-ZFA auf das andere Gerät nicht beschreibe.
Zwingend notwendig ist die Android Debug Bridge (adb). Unter Linux ist sie einfach über das Paketmanagement zu installieren, unter Windows … nun, Windows-Nutzer*innen müssen sich was suchen.
Am OPO wird dann Android-Debugging in den Entwickleroptionen aktiviert. Dazu müssen diese erstmal freigeschaltet werden: In den Einstellungen wird heruntergescrollt bis "Über das Telefon". Dort wird 7× auf die Buildnumber getippt. Im Anschluss können die "Entwickleroptionen" oberhalb von "Über das Telefon" gefunden werden. Ein bis zwei Bildschirme heruntergescrollt ist "Android-Debugging aktivieren" zu finden.
An der Stelle ließe sich dann das Telefon ans USB-Kabel und dieses an den Computer anschließen. Mein Arch Linux hat hier aber die Kooperation verweigert, indem es das Telefon nicht mehr finden wollte, nachdem USB-Debugging aktiviert wurde. Dementsprechend konnte ich nicht
adb reboot bootloader
ausführen. In den Entwickleroptionen konnte ich aber ein etwas besser ausgestattetes Neustart-Menü aktivieren, was mir das direkte Booten in den Bootloader Fastboot erlaubt.
Sobald auf dem Display des OPO "fastboot" erscheint, kann es über den Befehl "fastboot" angesprochen werden. Bei Linux ist das meines Wissens Teil des adb-Pakets, bei Windows … siehe oben. Mit
fastboot devices
lässt sich anzeigen, ob das Gerät zu finden ist. Ist dem so, lässt sich das OPO mit folgendem Befehl entsperren, falls es noch nicht entsperrt ist:
fastboot unlock oem
Das Gerät wird gelöscht (auf Werkseinstellungen zurückgesetzt)! Im Anschluss startet es neu. Android-Debugging ist leider wieder deaktiviert worden, deswegen erneut aktivieren und wieder in den Fastboot-Bootloader booten. Jetzt lässt sich das oben heruntergeladene TWRP vorübergehend installieren:
fastboot flash recovery twrp-x.x.x-x-bacon.img
Die Versionsnummer ist entsprechend anzupassen. "Vorübergehend" deswegen, weil ich Warnungen gelesen habe, dass ein dann startendes Cyanogen OS das TWRP-Recovery einfach wieder löscht und durch das originale ersetzt. Sollte aus Versehen das OPO also nicht ins Recovery, sondern ins Android gebootet werden, muss diese Prozedur ggf. wiederholt werden. Ist TWRP geschrieben worden, kommt der Teil, der etwas Fingerfertigkeit erfordert: Das OPO muss ausgeschaltet werden. Bei mir half es nicht, lange auf den Power-Button zu drücken – ich musste mit [Power]+[Vol-Down] hart ausschalten. Netterweise ist das gleich die Tastenkombination, mit der auch ins Recovery gebootet werden kann, was dann jetzt ansteht.
TWRP erlaubt es, die benötigten Daten per adb oder per Dateimanager auf das OPO zu kopieren. Da eh schon das Terminal offen ist, heißt es
adb push lineage-14.1-20171023-nightly-bacon-signed.zip /sdcard
LineageOS darf die Google-Apps nicht beinhalten. Deswegen müssen diese für die Verwendung des Play Store gesondert heruntergeladen werden, z.B. von http://opengapps.org/. Das OPO braucht Pakete für die ARM-Plattform, LineageOS 14.1 entspricht Android 7.1. Mit ein bisschen Herumprobieren fand ich heraus, dass das größte installierbare Paket die Mini-Version ist (hier direkt verlinkt). Dieses wird dann auch auf das OPO kopiert:
adb push opengapps-arm-7.1-mini.zip /sdcard
Werden optional root-Rechte gewünscht, ist noch das LineageOS-SU-Addon von https://download.lineageos.org/extras zu beschaffen: ebenfalls ARM, ebenfalls für 14.1. Auch dieses dann rüberkopieren:
adb push addonsu-14.1-arm-signed.zip /sdcard
Damit wäre alles beisammen. Am OPO dann in TWRP "Wipe" auswählen, "Advanced Wipe" und dort dann System, Data und Cache auswählen. Das Löschen bestätigen, kurz warten und zurück ins Hauptmenü. Jetzt können die ZIP-Dateien installiert werden mit "Install". Dort können die eben kopierten Dateien dann nacheinander ausgewählt werden, und zum Schluss wird die Installation dann bestätigt. Weil es nichts kostet, habe ich das Angebot, Dalvik Cache und Data zu wipen angenommen, ebenso die Installation der TWRP-Android-App (die eigentlich nur ein Platzhalter für die richtige App ist). Jetzt kann neugestartet werden. Das erste Mal Android 7.1. zu booten, kann ein wenig länger dauern.
Anmerkung: Mein adb-Problem in Arch Linux habe ich nicht behoben bekommen. Netterweise stellte mir Katja kurzzeitig ihren Ubuntu-Laptop zur Verfügung, wo das Kopieren per adb problemlos verlief. Trotzdem hat mich das wahnsinnig gemacht, da ich in dmesg mitansehen konnte, wie das OPO am USB im Halbsekundentakt die USB-Verbindung verlor und wiederherstellte. Wenn ich ehrgeizig bin, recherchiere ich da mal eine Lösung.
Nach dem Bootvorgang bot mir LineageOS die Wiederherstellung aus verschiedenen Quellen an, unter anderem über mein Google-Konto. Dort konnte ich dann mein A0001 auswählen. Ärgerlicherweise wurde mir keine Option zur Auswahl des WLAN gegeben, bevor ich mit der Ersteinrichtung durch war. Immerhin stellte das Gerät nicht alles wieder her, bevor ich durch war. Sobald ich auf dem Startbildschirm war, aktivierte ich das WLAN und war beruhigt, nicht mein Datenvolumen aufzubrauchen. Immerhin fing es an, mehr als 150 Apps herunterzuladen.
Fazit
Abgesehen von meinen adb-Schwierigkeiten war der Vorgang eigentlich recht problemlos. Ärgerlich ist natürlich, dass einige Apps unwiderruflich ihre Einstellungen verlieren (Signal, Syncthing, Authenticator, WhatsApp (naja, WhatsApp ist mir egal)). Das OPO bootet Android N klaglos und verrichtet seinen Dienst. Bacon, so der Codename des OPO, ist ein offiziell unterstütztes Gerät von LineageOS. Ich erwarte nicht mehr Probleme von LineageOS als vom vorher installierten Cyanogen OS, eher weniger, wegen gereifterer Software und engagierter Community. Ich bin sicher, es wird seine eigenen Macken mitbringen. Mal schauen. So weit bin ich bislang ganz angetan.
Raspberry Pi als Netzwerk- und Bluetooth-Audiogerät (Teil 1)
Geschrieben von Masin Al-Dujaili am Tuesday, 3. October 2017 in Technik
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.
Seite 1 von 1, insgesamt 11 Einträge
