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.