LineageOS auf Oneplus One (bacon) installieren

Geschrieben von Masin Al-Dujaili am Sunday, 29. October 2017 in Technik

Urlaub. Mistwetter. Da könnte man ja mal das Oneplus One (OPO) mit LineageOS bespielen, oder?
 
Was gibt es zu berücksichtigen?
 
*seufz*
 

Hürden

Signal. Die Schlüssel von Signal lassen sich leider nicht retten, da ich das OPO nicht gerootet hatte. Jeder App-Entwickler kann in der Manifest-Datei seiner App angeben, ob sie auf "adb backup" reagieren soll oder nicht. Und OpenWhispersystems hat sich dagegen entschieden aus Sicherheitsgründen (die ich komplett nachvollziehen kann, mir aber so ein wenig die Motivation nehmen).
 
Google Authenticator. Ich habe sechs Dienste in den Authenticator eingebunden. Was für Signal gilt, gilt auch hier: kein Backup möglich. Immerhin kann ich die Verknüpfung temporär auf ein anderes Gerät schieben, um das später wieder zurück auf das OPO zu schieben. Nicht, dass ich falsch verstanden werde: Es gibt keine Automatik. Das muss bei jedem Dienst so gemacht werden, als würde ich die Zweifaktorauthentifizierung neu einrichten.
 
Syncthing. Auch hier liegen die kryptographischen Schlüssel außerhalb meines Zugriffs. Hier muss ich im Anschluss all meinen Geräten die neue Installation wieder bekanntmachen.
 

Vorbereitung

Laden wir erstmal die passenden Pakete herunter:

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.

0 Kommentare Mehr...

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.

Audio-Pi als Ausgabegerät in den Pulseaudioeinstellungen. Ich habe keine Ahnung, warum er zwei Mal auftaucht.

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.

1 Kommentar Mehr...

Seite 1 von 1, insgesamt 2 Einträge

Suche

Nach Einträgen suchen in Blog Wiedner Al-Dujaili:

Das Gesuchte nicht gefunden? Gib einen Kommentar in einem Eintrag ab oder nimm per E-Mail Kontakt auf!