Sommaire
Introduction
Note de lecture : cette dépêche est très détaillée, je vous conseille de passer les sections qui vous intéressent moins.
Motivation
Dans mon salon, j’ai des petites enceintes toutes bêtes qui sonnent plutôt bien. Mettre de la musique implique de s’embêter à brancher un ordinateur, sur lequel je suis le seul avoir le contrôle. Ce serait bien d’avoir un système prêt à l’emploi et que tout le monde peut contrôler.
Objectifs
- Pas d’achat : on fait avec de la récup
- Peu gourmand en énergie
- Silencieux (à part la musique, bien sûr)
- Facile à utiliser pour une personne non technique
- Pouvoir mettre de la musique sans que ça soit pénible, en utilisant ma bibliothèque musicale locale, ou des radios internet
- Pouvoir laisser n’importe qui se connecter en Bluetooth et lancer sa propre musique
Nous allons, ensemble, remplir ces objectifs. On va rentrer dans les détails, qui peuvent être utiles dans d’autres applications, et parce que je sais que certaines personnes ici aiment ça, bande de geeks :-)
Matériel à disposition
- des enceintes parfaitement fonctionnelles mais sans fonctionnalité Bluetooth
- un appareil style netbook du début des années 2010 (dans mon cas, c’est une vieille tablette Airis Kira Slimpad plus vraiment adaptée au web moderne, dotée d’un processeur Intel Atom un peu lent, d’un peu de stockage assez lent, d’un Wifi plutôt lent, du Bluetooth, d’1 Giga de mémoire vive)
Note sur les interférences Wifi et Bluetooth. Le Wifi de cette tablette est en 2,4 GHz, pareil que le Bluetooth. Tout échange wifi cause des perturbations sur le Bluetooth et tout transfert intensif rend le Bluetooth inutilisable. Du grand classique. Un Wifi 5, 6 ou 7 aurait été appréciable. Il serait possible d’utiliser une carte Wifi USB, mais je n’en ai pas donc on fera sans.
Ce qu’on va faire dans les grandes lignes
- Installer une Debian minimale
- La configurer pour qu’elle soit accessible par le réseau, la plus rapide et légère possible en utilisation mémoire, en temps de démarrage et en consommation énergétique
- Installer et configurer MPD
- Installer et configurer Samba
- Configurer en mode « enceinte Bluetooth »
Installation standard minimaliste de Debian
Par souci de concision, on ne va pas détailler l’installation de Debian, il existe d’autres ressources au besoin.
En résumé :
- Debian classique en 32 bits (ça consomme moins de mémoire que du 64 bits)
- j’ai laissé l’installateur faire le partitionnement (une partition principale en ext4, et une partition swap de 1G)
- j’ai ajouté l’option noatime sur la partition principale pour éviter d’écrire inutilement lors des accès, ce qui use le SSD et ralentit le système (d’autant que le SSD est lent)
- lors de l’étape Tasksel, choisir console, serveur ssh et utilitaires standard, et en particulier pas d’environnement de bureau
- on installe sudo et on ajoute l’utilisateur au groupe sudo, ou alors on se donne accès à root en ssh avec une clé SSH
- on installe iwd (le remplaçant moderne de
wpa_supplicant, supposé plus performant et plus stable permettant également de se passer de NetworkManager assez facilement) et on connecte l’appareil en wifi avec
- on identifie et désactive ou on désinstalle le superflu avec
systemd-analyze critical-chain et systemd-analyze blame (typiquement, si vous avez installé NetworkManager, ModemManager a peut-être été installé alors que vous n’avez pas de modem à gérer)
- on peut configurer le menu de Grub pour moins attendre au démarrage
Note : sur cette tablette, l’installateur Debian n’arrive pas à se connecter en Wifi, j’ai donc utilisé la version DVD (le premier suffit).
Gains énergétiques potentiels
Éteindre l’écran
L’écran est potentiellement une des plus grosses sources de consommation électrique. On n’en a pas besoin, donc on va l’éteindre au démarrage et à la sortie de veille.
Pour cela, on va installer vbetool (sources : outils pour éteindre l’écran, lancer une commande au démarrage, lancer une commande après la veille):
sudo apt install vbetool
cat << EOF | sudo tee /etc/systemd/system/screenoff.service
[Unit]
Description=Screen off
After=suspend.target
[Service]
ExecStart=vbetool dpms off
[Install]
WantedBy=multi-user.target suspend.target
EOF
Attention : ça peut compliquer grandement l’usage de l’appareil, on peut vouloir appliquer un délai avant extinction pour se faciliter la vie.
Powertop pour améliorer la consommation électrique
Powertop permet de voir ce qui utilise le CPU et les diverses ressources, et d’ajuster un peu les paramètres de mise en veille de différents périphériques.
On va l’installer :
sudo apt install powertop
Ensuite, ça peut être cool de lancer l’outil pour constater un peu ce qui tourne et consomme des ressources, de se déplacer dans les onglets, et de tenter des trucs dans l’onglet « Tunables » :
sudo powertop
Si passer tout à Good ne cause pas de problème d’instabilité évidente, alors on peut appliquer la configuration de Powertop à chaque démarrage (source) :
cat << EOF | sudo tee /etc/systemd/system/powertop.service
[Unit]
Description=PowerTOP auto tune
[Service]
Type=oneshot
Environment="TERM=dumb"
RemainAfterExit=true
ExecStart=/usr/sbin/powertop --auto-tune
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable powertop.service
Sinon, il y a des solutions mentionnées dans la source pour désactiver certains changements (si vous observez des dysfonctionnements avec certains périphériques par exemple, et notamment si vous avez des problèmes de Wifi ou Bluetooth)
Perso, je sais que sur cette tablette, passer tout à Good fait (faisait il y a 10 ans en tout cas) qu’après un délai la première frappe sur le clavier ou le premier clic de la souris était ignoré, et aussi était nécessaire pour réveiller l’USB – clairement je m’en fiche ici, mais si votre wifi ou votre Bluetooth est en USB et que les paramètres causent une extinction après un délai, clairement ce n’est pas bon).
Bonus : Configurer le bouton power pour mettre en veille
Sur ma tablette, un appui court sur le bouton power éteint la tablette (et ensuite on la rallume en appuyant 3 longues secondes). Si on souhaite qu’un appui court mette en veille l’appareil et un appui long l’éteigne, comme ça on fait un compromis énergétique supposément raisonnable pour rendre l’ensemble un poil plus pratique, c’est facile avec systemd.
Ajoutez ces deux lignes au fichier /etc/systemd/logind.conf :
HandlePowerKey=suspend
HandlePowerKeyLongPress=poweroff
Rechargez les paramètres :
sudo systemctl restart systemd-logind
MPD : Music Player Deamon
Ok, passons au cœur du sujet : mpd.
Késako
Simplement, c’est un lecteur de musique pilotable à distance qui est capable de :
- lire de la musique que vous mettez dans son dossier de travail ;
- lire des playlists que vous mettez dans son dossier de travail ;
- lire des flux radio, qui sont par exemple définis dans des playlists.
Entre autres.
Certains clients MPD, comme Cantata (une application Qt5 plus ou moins abandonnée mais encore dans les dépôts), sont même capables de lire de la musique sur votre serveur MPD que vous avez localement sur votre ordinateur, ou de gérer les playlists. Ça rend d’ailleurs la constitution de playlists vaguement confortable. Vous n’avez pas besoin d’écrire des playlists M3U à la main, quoi.
Les avantages sont multiples :
- c’est méga léger, une machine épuisée peut faire tourner MPD à l’aise
- si vous lisez la musique stockée sur le serveur, le réseau n’est pas engorgé
- on peut être plusieurs à contrôler la musique, ce n’est pas une personne qui contrôle tout, et on peut le faire depuis le canapé
- il existe toute une flopée de clients, il y en a pour tous les goûts pourvu que vous aimiez les logiciels abandonnés ou en ligne de commande / en ncurses (ouais, c’est quand même un problème que j’identifie et qui a largement retardé mon adoption de MPD)
- les gens non techniques apprécieront les applications mobiles telles que M.A.L.P pour gérer la musique et le volume sonore.
C’est parti pour l’installation
sudo apt install mpd
On va modifier sa configuration :
sudo nano /etc/mpd.conf
On peut laisser les paramètres par défaut suivants :
music_directory "/var/lib/mpd/music"
playlist_directory "/var/lib/mpd/playlists"
Vous l’aurez compris, c’est là où on stocke les musiques et les playlists. Dans la section suivante, on verra comment rendre le dépôt de morceaux simple et convivial.
On va laisser la plupart des autres paramètres par défaut.
On va changer bind_to_address, qui est par défaut à localhost, mais on veut que n’importe quel appareil sur le réseau soit capable de s'y connecter. On va aussi explicitement mettre le port à la valeur par défaut (ce n’est probablement pas nécessaire, mais c’est ce que j’ai fait) :
bind_to_address "0.0.0.0"
port "6600"
On veut aussi que quand des fichiers sont changés dans les dossiers music et playlists, mpd se mette à jour tout seul pour ne pas avoir à le baby-sitter :
auto_update "yes"
J’ai tenté d’activer zeroconf pour que les clients MPD puissent le trouver tout seul :
zeroconf_enabled "yes"
zeroconf_name "Music Player @ %h"
Mais en vrai, je n’ai pas réussi à faire fonctionner ça. En tout cas, un prérequis est d’avoir installé et activé avahi-daemon, on verra ça plus tard dans la partie Samba du coup.
Vous aurez peut-être envie de mettre un mot de passe voire de changer les permissions par défaut en décommentant et adaptant les paramètres suivants, mais c’est optionnel :
#password "password@read,add,control,admin"
#default_permissions "read,add,control,admin"
Ensuite, la partie critique, la sortie audio. Pour l’instant, on va dire à mpd d’utiliser Alsa directement. C’est le plus direct et le plus léger (on passera à PipeWire plus tard, pour gérer l’aspect récepteur Bluetooth)
audio_output {
type "alsa"
name "My ALSA Device"
device "hw:0,0" # optional
mixer_type "hardware" # optional
# mixer_device "default" # optional
mixer_control "Master" # optional
mixer_index "0" # optional
}
Pour une de mes installations, j’ai commenté mixer_device parce que ce n’est manifestement pas la bonne valeur chez moi, et que ça marche bien sans.
Vous pouvez vous passer des autres valeurs optionnelles, mais vous n’aurez pas le contrôle du volume sonore depuis les clients MPD si vous faites ça. Vous allez donc devoir trouver les bonnes valeurs pour les paramètres mixer_*, et pour device. ainsi que mixer_control et mixer_index.
Quelques indices :
-
hw:0,0 est probablement la bonne valeur pour device, et 0 pour mixer_index aussi. Vous pouvez lister vos cartes son avec aplay -L. Vous aurez peut-être besoin d’installer le paquet alsa-utils.
- la valeur de
mixer_control est le nom du contrôle que vous utiliserez pour changer le volume dans alsamixer, du paquet alsamixergui que vous aurez probablement besoin d’installer.
Si vous galérez trop avec les valeurs de mixer-*, vous pouvez simplement utiliser mixer_type "software", c’est moins propre mais ça devrait faire le taf. Et sinon, vous pouvez toujours sortir l’artillerie lourde et passer directement à PipeWire.
Pour appliquer vos modifications :
systemctl enable --now mpd # À partir de Debian Trixie, mpd n’est plus activé par défaut au niveau du système
systemctl restart mpd # Si MPD tournait déjà
Vous pouvez déboguer vos changements avec la commande suivante, qui suit les logs en temps réel :
journalctl -fu mpd
Vous avez plusieurs options pour essayer de lire des choses avec mpd :
- installer l’application M.A.L.P sur votre téléphone Android, ou une autre application cliente MPD, et ajouter un profil avec la bonne adresse, le bon port et le bon mot de passe ;
- installer un client comme Cantata sur votre ordinateur, avec la bonne adresse, le bon port et le bon mot de passe ;
- installer
mpc directement sur le serveur. Normalement mpc play permet de lancer la lecture.
Moi, j’ai testé avec une webradio dans une playlist (/var/lib/mpd/playlists/radio-paradise-main-mix.m3u avec le contenu http://stream.radioparadise.com/ogg-192m), mais on peut aussi évidemment placer un morceau dans /var/lib/mpd/music/.
ReplayGain
Le niveau sonore de mes morceaux n’est pas homogène, donc il faut sans cesse adapter le volume d’un morceau à l’autre. C’est pénible, voire inutilisable en l’état. Une solution pour ça est replay gain : on analyse et on enregistre le niveau sonore d’une piste dans ses métadonnées.
Il existe plein d’outils pour faire ça, dont https://github.com/complexlogic/rsgain
On peut le faire avant d’envoyer les fichiers sur l’appareil. Pour ma part, je l’ai fait sur la tablette, et il n’existe pas de paquet Debian 32 bits, donc je l’ai compilé :
sudo apt install cmake build-essential pkd-config git libavcodec-dev libavformat-dev libtag1-dev libebur128 libinih-dev libfmt-dev
git clone --depth=1 https://github.com/complexlogic/rsgain
cd rsgain
mkdir build
cd build
cmake ..
make -j2
sudo make install
Il faudra s'assurer que les morceaux au format Opus sont étiquetés avec le tag R128_TRACK_GAIN et pas REPLAYGAIN_TRACK_GAIN, parce que c'est ce que MPD s’attend à avoir. Pour ça, on va convaincre rsgain de suivre les standards (que certains lecteurs de musiques ne comprennent pas) en créant un preset qui contient :
[Opus]
OpusMode=s
Mes morceaux ne sont pas organisés par albums, donc je désactive l’analyse par album. Je vais donc partir du preset no_album :
mkdir -p ~/.config/rsgain/presets; cat << EOF > ~/.config/rsgain/presets/no_album_standard_opus.ini
[Global]
TagMode=i
Album=false
TargetLoudness=-18
ClipMode=p
MaxPeakLevel=0.0
TruePeak=false
Lowercase=false
ID3v2Version=keep
PreserveMtimes=false
DualMono=false
OpusMode=s
EOF
Ensuite, on peut le rsgain sur le dossier de musiques avec ce preset. Mes morceaux ne sont pas organisés par albums, donc je désactive l’analyse par album.
rsgain easy -p no_album_standard_opus -m MAX /var/lib/mpd/music
Note : l'option --skip-existing permet d'ignorer les fichiers déjà taggés :
rsgain easy --skip-existing -p no_album_standard_opus -m MAX /var/lib/mpd/music
Avec cette option, on peut exécuter cette tâche régulièrement, par exemple dans un cron, pour calculer le ReplayGain pour les nouveaux fichiers. Pour la première exécution, il vaut certainement mieux ne pas l’utiliser, sinon, si vous aviez déjà des fichiers qui avaient l'information, il se peut que le résultat ne soit pas uniforme.
Il faut dire à MPD d’utiliser le ReplayGain dans /etc/mpd.conf :
replaygain "track"
Vous aurez peut-être besoin de jouer avec les autres paramètres liés au volume et au ReplayGain.
Voici les miens :
# Ce paramètre définit la pré-amplification à appliquer pour les morceaux qui ont l'information du ReplayGain
replaygain_preamp "0"
# Ce paramètre définit la pré-amplification à appliquer pour les morceaux qui ne l'ont pas
replaygain_missing_preamp "0"
# Faut-il interdire à MPD de dépasser le niveau original d'amplification en appliquant le ReplayGain?
replaygain_limit "no"
# Faut-il permettre à MPD d'ajuster le volume pendant la lecture pour normaliser ?
volume_normalization "no"
Un autre paramètre qu’on peut régler, c'est la manière dont MPD règle le volume dynamiquement pour ReplayGain. Dans votre bloc audio_output, vous pouvez ajouter replay_gain_handler et la valeur "software" (c'est la valeur par défaut) ou "mixer". En théorique, les traitements software dégradent le son, mais en pratique, avec "mixer", je tombe sur ce bug qui met le volume à 100% après chaque changement de piste.
Note : je ne suis pas encore convaincu d’avoir réussi à trouver les réglages parfaits, n’hésitez pas à expérimenter.
Les clients MPD
À ce stade, vous devriez avoir un serveur MPD fonctionnel et configuré. Si applicable, vous pouvez commencer à suggérer aux gens de votre foyer d’installer l’application M.A.L.P sur leur appareil Android ; elle est libre et disponible sur F-Droid et sur le Play Store. Avec un peu de chance, votre enthousiasme était communicatif et c’est eux qui vous demanderont :-)
Pour les autres types d’appareils, vous allez devoir faire vos recherches vous-même je n’ai pas étudié les options sous Windows, Mac ou iPhone, mais il y en a. Pour Linux, j’ai essayé Cantata. Il me convient, si ce n’est qu’il a l’air un peu abandonné, et il a une interface certes conviviale, mais quand même un peu brute. Il existe des widgets qui s’intègrent aux différents environnements de bureaux pour les différents systèmes d’exploitation, je n’ai pas exploré. Le site de MPD propose une liste de clients, et le wiki de Arch aussi.
Samba pour déposer les morceaux (et les playlists)
Déposer des morceaux, vous allez probablement le faire depuis un ordinateur, et à peu près n’importe quel système d’exploitation est capable d’aller chercher un dossier SMB en réseau, alors je vous propose de configurer un serveur Samba. Ça a le bon goût d’être très léger, très simple à faire et de fonctionner depuis n’importe quel OS. Allons-y, et tant qu’à faire, on va aussi installer Avahi, qui permettra aux ordinateurs sous Linux et Mac de découvrir les dossiers partagés tous seuls :
sudo apt install samba avahi-daemon
On va partager nos dossiers music et playlists au monde entier en lecture-écriture (YOLO). On édite /etc/samba/smb.conf:
[Musique]
path=/var/lib/mpd/music
read only=no
writable=yes
comment=Fichiers musique MPD
guest ok = yes
force group = audio
force user = mpd
browsable = yes
public = yes
create mask = 0644
directory mask = 0755
[Playlists]
path=/var/lib/mpd/playlists
read only=no
writable=yes
comment=Listes de lecture MPD
guest ok = yes
force group = audio
force user = mpd
browsable = yes
public = yes
create mask = 0644
directory mask = 0755
Je ne maitrise pas particulièrement Samba et il y a peut-être des options superflues, mais globalement l’esprit c’est :
- n’importe qui doit pouvoir accéder à ces deux en lecture et en écriture depuis le réseau. En particulier, la création de dossiers doit marcher
- MPD doit pouvoir lire ce qu’on a écrit dans ces dossiers
- les fichiers et dossiers doivent avoir des permissions sensées
Bien sûr, on peut vouloir restreindre l’accès à certains utilisateurs et/ou avec un mot de passe. Je vous laisse creuser.
Après un redémarrage de Samba :
sudo systemctl restart samba
Avec un peu de chance, dans l’onglet « Réseau » de votre gestionnaire de fichier, dans la section « Partages SMB », votre appareil apparait. Sinon, vous devriez pouvoir y accéder avec smb://HOST/ avec Dolphin et probablement Nautilus, probablement \\HOST sous Windows.
Alternatives possibles à Samba
- Si on a un NAS, monter un dossier sur le serveur MPD, voire installer MPD sur le serveur de stockage, ou avoir une tâche chron qui fait un rsync bien placé
- Mettre en place une synchronisation avec Nextcloud ou Syncthing, et faire pointer MPD vers le bon dossier, ou ajouter le dossier de MPD comme dossier de stockage externe à Nextcloud par exemple
- SFTP
- NFS
- FTP (mais les autres options sont probablement meilleures)
Récepteur Bluetooth
Ce n’est bien sûr pas nécessaire si vous êtes parfaitement satisfait·e avec MPD, mais si vous voulez que votre appareil soit en plus capable de se comporter comme une enceinte Bluetooth, vous êtes au bon endroit.
Les difficultés qu’on va résoudre sont les suivantes :
- pour l’instant, MPD accède au son directement avec ALSA, et en général on ne peut pas être plusieurs sur ALSA. En tout cas, et même s’il a l’air possible de faire fonctionner Bluetooth et ALSA ensemble, ça n’a pas l’air d’être terriblement simple ou même stable. Donc on va utiliser PipeWire. On aurait pu utiliser PulseAudio, mais PipeWire le remplace, et fonctionne généralement mieux.
- PipeWire, c’est pensé pour être lancé dans une session graphique d’un utilisateur, mais nous, on a un serveur headless. Il va falloir faire en sorte de lancer une session utilisateur au démarrage sans interaction, et que cette session ne soit pas tuée.
- mpd tourne avec son utilisateur, PipeWire avec son utilisateur, et après s’être rendu compte qu’il faut que ça soit les mêmes, faut aussi savoir comment, et le faire.
Lors de l’installation de Debian, on a défini un utilisateur. On peut utiliser cet utilisateur. Sinon, on peut aussi en créer un pour ça, pensez bien à l’ajouter aux groupes audio et bluetooth.
Garder une session utilisateur active
On va démarrer une session utilisateur au boot :
sudo loginctl enable-linger user # remplacer user par le nom d’utilisateur
On va s’assurer que les processus de cette session ne sont pas tués au moment où on quitte une session (par exemple quand on quitte une session ssh) : dans le fichier /etc/systemd/logind.conf, décommentez la ligne KillExcludeUsers et ajouter le nom d’utilisateur après le =. Vous deviez avoir
KillExcludeUsers=user
où user est le nom d’utilisateur.
On peut maintenant recharger ces paramètres :
sudo systemctl restart systemd-logind
Installer PipeWire et les choses nécessaires
À ce stade, MPD bloque probablement l’utilisation du son parce qu’il s’y connecte via ALSA. On va le stopper.
sudo systemctl stop mpd
PipeWire et WirePlumber vont dorénavant gérer le son, et libspa-0.2-bluetooth permet au démon qui gère le Bluetooth (Bluez) de s’inter-connecter à PipeWire pour le Bluetooth Audio.
sudo apt install wireplumber pipewire libspa-0.2-bluetooth
En tant que votre utilisateur (nommé user dans les commandes précédentes) (c’est important), activez PipeWire au démarrage et lancez-le :
systemctl --user enable --now pipewire wireplumber
Notez que pipewire-pulse n’est pas nécessaire, d’ailleurs vous pouvez le supprimer ou le désactiver en toute sécurité s’il a été installé.
Installer un agent Bluetooth qui accepte toutes les connexions audio sans vérifications avec code
Normalement, accepter les connexions Bluetooth se fait à l’aide d’un agent Bluetooth :
- qui tourne dans votre session graphique : c’est géré par votre environnement de bureau, ou une application comme
bluetooth-applet (est-ce que ça existe encore ?) que vous lancez. Là, évidemment, on n’a pas de session graphique, et pour l’instant on n’a pas d’agent Bluetooth qui tourne.
- En ligne de commande, avec un outil comme
bluetoothctl. Je vous invite à essayer. Vous pouvez lancer des commandes comme pairable on, discoverable on, scan on, et essayer de vous connecter avec un autre appareil. Après vos tests, vous pouvez tout recommencer en faisant oublier les appareils des deux côtés.
Évidemment, on ne va pas se connecter en ssh pour lancer bluetoothctl à chaque fois qu’on veut se connecter en Bluetooth. On va mettre en place un agent qui démarre automatiquement et qui a un comportement similaire à un casque ou des enceintes Bluetooth : qui accepte toutes les connexions Bluetooth audio. Pour ça, on va utiliser un script Python partagé par Collabora sous Licence LGPL 2.1+ qui fait ça très bien et qu’on va lancer au démarrage.
Bien sûr, ça veut dire que vos voisins peuvent s’amuser à jouer des trucs chez vous, ou même se connecter fortuitement en choisissant la mauvaise entrée.
Ce script a une dépendance, qu’on va installer :
sudo apt install python3-dbus
On va placer ce script dans speaker-agent.py:
#!/usr/bin/python3
# SPDX-License-Identifier: LGPL-2.1-or-later
import dbus
import dbus.service
import dbus.mainloop.glib
from gi.repository import GLib
BUS_NAME = 'org.bluez'
AGENT_INTERFACE = 'org.bluez.Agent1'
AGENT_PATH = "/speaker/agent"
A2DP = '0000110d-0000-1000-8000-00805f9b34fb'
AVRCP = '0000110e-0000-1000-8000-00805f9b34fb'
bus = None
class Rejected(dbus.DBusException):
_dbus_error_name = "org.bluez.Error.Rejected"
class Agent(dbus.service.Object):
exit_on_release = True
def set_exit_on_release(self, exit_on_release):
self.exit_on_release = exit_on_release
@dbus.service.method(AGENT_INTERFACE,
in_signature="", out_signature="")
def Release(self):
print("Release")
if self.exit_on_release:
mainloop.quit()
@dbus.service.method(AGENT_INTERFACE,
in_signature="os", out_signature="")
def AuthorizeService(self, device, uuid):
# Always authorize A2DP and AVRCP connection
if uuid in [A2DP, AVRCP]:
print("AuthorizeService (%s, %s)" % (device, uuid))
return
else:
print("Service rejected (%s, %s)" % (device, uuid))
raise Rejected("Connection rejected by user")
@dbus.service.method(AGENT_INTERFACE,
in_signature="", out_signature="")
def Cancel(self):
print("Cancel")
if __name__ == '__main__':
dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
agent = Agent(bus, AGENT_PATH)
mainloop = GLib.MainLoop()
# By default Bluetooth adapter is not discoverable and there's
# a 3 min timeout
# Set it as always discoverable
adapter = dbus.Interface(bus.get_object(BUS_NAME, "/org/bluez/hci0"),
"org.freedesktop.DBus.Properties")
adapter.Set("org.bluez.Adapter1", "DiscoverableTimeout", dbus.UInt32(0))
adapter.Set("org.bluez.Adapter1", "Discoverable", True)
print("RPi speaker discoverable")
# As the RPi speaker will not have any interface, create a pairing
# agent with NoInputNoOutput capability
obj = bus.get_object(BUS_NAME, "/org/bluez")
manager = dbus.Interface(obj, "org.bluez.AgentManager1")
manager.RegisterAgent(AGENT_PATH, "NoInputNoOutput")
print("Agent registered")
manager.RequestDefaultAgent(AGENT_PATH)
mainloop.run()
Le script mentionne le Raspberry Pi, mais il n’y a absolument rien de spécifique au Raspberry dedans, il est suffisamment générique.
On va lancer ce script au démarrage en créant le fichier ~/.config/systemd/user/speaker-agent.service
[Unit]
Description=Bluetooth speaker agent
[Service]
ExecStart=python3 speaker-agent.py
[Install]
WantedBy=default.target
Et en l’activant (--now le lance tout de suite) :
systemctl --user enable --now speaker-agent.service
Il faudra aussi mettre JustWorksRepairing = always dans /etc/bluetooth/main.conf pour permettre le re-appairage sans interaction. Bon là j’avoue, je paraphrase largement ma source :-)
Ensuite, on va autoriser la connexion Bluetooth même sans session active (en SSH par exemple) (source). Si on ne fait pas ça, la connexion Bluetooth n’est pas possible si l’utilisateur n’a pas une session active (les symptômes : on arrive à se connecter en Bluetooth que quand on est loggué en SSH ou autre, et la connexion Bluetooth casse dès qu’on quitte la session).
mkdir -p ~/.config/wireplumber/bluetooth.lua.d
cat > ~/.config/wireplumber/bluetooth.lua.d/80-disable-logind.lua << EOF
-- Disable arbitration of user allowance of bluetooth via D-Bus user session
bluez_monitor.properties["with-logind"] = false
EOF
systemctl --user restart wireplumber
Adapter MPD (et Samba) pour utiliser PipeWire
Pour que MPD utilise PipeWire, il faut adapter :
- sa configuration pour qu’il tourne avec le même utilisateur
- sa configuration
audio_output
- les permissions dans
/var/lib/mpd
Dans /etc/mpd.conf, changer la ligne user :
user "mpd"
Elle doit maintenant utiliser votre utilisateur :
user "user"
Commentez votre bloc audio_output, on va maintenant utiliser PipeWire (je suppose qu’on pourrait garder les deux et les clients MPD peuvent probablement permettre de choisir la sortie son, mais ça me parait complexifier l’utilisation pour un intérêt pas clair, ce qui va contre nos objectifs) :
audio_output {
type "pipewire"
name "PipeWire Sound Server"
}
Maintenant, il est temps d’adapter les permissions dans /var/lib/mpd. On va stopper Samba juste avant, et adapter sa configuration.
sudo systemctl stop mpd samba # si mpd tournait encore
sudo chown -rv user /var/lib/mpd
sudo systemctl start mpd
Note : MPD peut aussi être démarré dans une session utilisateur et à ce stade, c’est ce qu’il serait probablement le plus logique de faire, en bougeant /etc/mpd.conf et le contenu de /var/lib/mpd dans le dossier de notre utilisateur. C’est d’ailleurs la manière privilégiée de démarrer MPD à partir de Debian Trixie. Par simplicité et cohérence, et parce que cette section « Récepteur Bluetooth » est optionnelle mais que les manipulations pour lancer une session utilisateur au démarrage décrites dans cette section seraient nécessaires pour lancer MPD en tant que service utilisateur au démarrage dans tous les cas et que ça apporte une réelle complexité, on fait le choix de garder MPD en tant que service système.
Modifiez /etc/samba/smb.conf. Dans les deux blocs de partages qu’on a ajouté précédemment, changez la ligne force user = mpd en:
force user = user
Puis on peut redémarrer Samba :
sudo systemctl start samba
Permettre à PipeWire de configurer sa priorité
Si vous voyez cela dans les logs de PipeWire :
user@tablette:~$ journalctl --user -fu pipewire
avril 29 13:41:01 tablette systemd[514]: Started pipewire.service - PipeWire Multimedia Service.
avril 29 13:41:01 tablette pipewire[531]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
avril 29 13:41:01 tablette pipewire[531]: mod.rt: found session bus but no portal
avril 29 13:41:02 tablette pipewire[531]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
avril 29 13:41:02 tablette pipewire[531]: mod.rt: could not set nice-level to -11: Permission non accordée
avril 29 13:41:02 tablette pipewire[531]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
avril 29 13:41:02 tablette pipewire[531]: mod.rt: could not make thread 547 realtime using RTKit: Permission non accordée
Ça veut grosso modo dire que PipeWire cherche à se rendre plus prioritaire via un mécanisme fourni par les environnements de bureau (xdg-desktop-portal), n’y arrive pas parce qu’évidemment, aucun environnement de bureau ne tourne, alors il essaie de demander au service système rtkit, et se fait jeter.
Ce n’est pas très grave et on pourrait vivre sans, mais ça pourrait aider à limiter les saccades sonores, donc on va réparer ça (et je pense avoir vu une bonne amélioration grâce à ça).
Le fichier /usr/share/polkit-1/actions/org.freedesktop.RealtimeKit1.policy dicte qui a le droit ou non de configurer sa priorité (découvert ici, mais le conseil de modifier ce fichier système n’est pas bon, au moins parce qu’une mise à jour future risque d’écraser les modifications) :
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
"-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
"http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
<vendor>Lennart Poettering</vendor>
<action id="org.freedesktop.RealtimeKit1.acquire-high-priority">
<description>Grant high priority scheduling to a user process</description>
<description xml:lang="tr">Bir sürece yüksek öncelikli çalışabilme yetkisi ver</description>
<message>Authentication is required to grant an application high priority scheduling</message>
<message xml:lang="tr">Sürecin yüksek öncelikli çalıştırılabilmesi için yetki gerekiyor</message>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>yes</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
<action id="org.freedesktop.RealtimeKit1.acquire-real-time">
<description>Grant realtime scheduling to a user process</description>
<description xml:lang="tr">Bir sürece gerçek zamanlı çalışabilme yetkisi ver</description>
<message>Authentication is required to grant an application realtime scheduling</message>
<message xml:lang="tr">Sürecin gerçek zamanlı çalıştırılabilmesi için yetki gerekiyor</message>
<defaults>
<allow_any>no</allow_any>
<allow_inactive>yes</allow_inactive>
<allow_active>yes</allow_active>
</defaults>
</action>
</policyconfig>
Dans un système Unix, les paramètres systèmes sont dans /etc. Pour Polkit, il existe un mécanisme pour écrire des règles, qu’on va utiliser. On va créer une règle qui permet à n’importe quel utilisateur du groupe audio de modifier la priorité de ses processus. C’est probablement trop large, mais je ne connais pas bien Polkit et ça fera le taf pour notre application dédiée à l’audio. Si vous avez des meilleures idées, n’hésitez pas à partager en commentaire.
sudo cat > /etc/polkit-1/rules.d/rt.rules << EOF
polkit.addRule(function(action, subject) {
if (subject.isInGroup("audio") && (
action.id == "org.freedesktop.RealtimeKit1.acquire-high-priority" ||
action.id == "org.freedesktop.RealtimeKit1.acquire-real-time"
)) {
return polkit.Result.YES;
}
})
EOF
sudo systemctl restart polkit.service
systemctl --user restart pipewire
On pourra constater l’absence des échecs dans les journaux de PipeWire.
Bon, on sent bien que toute cette utilisation audio sans session utilisateur standard n’est pas un cas d’utilisation hyper bien prévu et on se retrouve à toucher des coins un peu sombres du système…
Évitez les flux Wifi 2,4 GHz
Si vous avez un Wifi en 2,4 GHz, ça peut causer des soucis avec le Bluetooth, et le son peut saccader. Si vous observez cela, il faudra alors limiter au maximum les services et autres tâches de fond qui font des communications réseau. Évidemment, si vous pouvez utiliser un câble Ethernet, c’est encore mieux.
Sur ce plan, tous les codecs audio Bluetooth ne semblent pas se valoir. Pour tester ça, j’ai lancé un test iperf3 entre la tablette et mon ordinateur portable pour saturer le Wifi. Ça devenait immédiatement catastrophique avec le codec SBC-XQ, alors qu’avec le codec Opus 05, il y a initialement des saccades, puis ça s’améliore vite. J’imagine que le codec Opus dégrade très efficacement la qualité pour compenser. Bon, malheureusement, tous les systèmes ne permettent pas de choisir son codec donc ce n’est qu’une solution partielle au problème.
Note sur l’utilisation des ressources
C'est léger :
load average: 0,12, 0,10, 0,05
$ free -mh
total utilisé libre partagé tamp/cache disponible
Mem: 986Mi 253Mi 324Mi 6,1Mi 550Mi 733Mi
Échange: 974Mi 0B 974Mi
Globalement, le CPU s’ennuie en pleine lecture, et à peine un tiers du Giga de mémoire vive est utilisé, la partition d’échange s’ennuie, donc il y a encore largement la place de faire tourner d’autres trucs sur cet appareil si jamais. On peut aussi constater qu’ajouter MPD et tout ce bazar à une installation existante ne la surchargerait pas plus que ça.
On a aussi un temps de démarrage autour des 20 secondes, ce qui est franchement pas mal.
Conclusion et améliorations possibles
On est pas mal rentrés dans les détails, c’était l’occasion d’explorer plein de choses mine de rien. J’ai à la fois appris des choses, précisé des connaissances, et mis plein de choses que je savais ensemble pour obtenir un résultat très satisfaisant. On se retrouve à manipuler de la gestion de services, des configurations systemd un peu poussées, du bluetooth, du son avec ALSA et PipeWire, de la gestion de session utilisateur sur un système headless, et plein d’autres trucs et aller dans les détails comme le boot pour avoir quelque chose de rapide, comme l’écran éteint au bon moment, ou la personnalisation du comportement du bouton power (honnêtement, je n’étais pas très sûr que c’était possible, j’avais lancé la recherche au cas où !).
J’espère que l’aventure vous a plu aussi.
Bien sûr l’ensemble est perfectible, alors je vous laisse avec des idées, n’hésitez pas à partager les vôtres en commentaires :
-
Jouer un son au démarrage / à l’appairage Bluetooth. – pour l’instant, la tablette s’allume et puis plus rien. En général, les enceintes Bluetooth jouent un petit son quand elles sont prêtes ou qu’elles viennent d’être appairées et ça peut être pratique
-
Commande vocale. Il y a clairement des manières d’utiliser le micro de la tablette pour demander le morceau suivant, précédent ou régler le volume. Ça peut être pratique quand on n’a pas le téléphone sous la main et ça peut avoir son petit effet en soirée la première fois, tant que les gens ne sont pas encore complètement blasés par le concept parce que tout le monde n’a pas un Google Nest ou un Alexa chez soi, surtout dans ma bulle sociale. Mais c’est probablement finalement très gadget et je me vois mal interrompre une conversation en criant un ordre pour gérer la musique…
-
Appairage Bluetooth plus sécurisé. En général, les enceintes Bluetooth acceptent les nouveaux appareils dans un mode spécial. En appuyant sur le bouton Bluetooth, ou quelque chose comme ça. Ça peut éviter que les voisin·e·s ne te rickrollent au moment le plus inopportun. Ça vaudrait le coup de travailler sur quelque chose comme ça. Avec l’écran tactile, il est probablement possible de dessiner une forme particulière reconnue (ça serait un peu badasse, ou plus probablement, n’accepter (une seule) nouvelle connexion que dans les X minutes après le démarrage ou le retour de veille. Comme ça, demander l’appairage consiste à appuyer deux fois sur le bouton power, ce qui est plutôt acceptable. Si vous avez des idées, n’hésitez pas à partager…
-
Réveil à distance avec du Wake-on-LAN. Ça ne s’applique probablement pas à mon matériel, mais il est possible d’utiliser astucieusement le WoL pour réveiller l'appareil à distance, avec éventuellement la complicité d’un routeur ou d’un serveur toujours allumé chez vous.
-
Désactiver le Wifi quand le Bluetooth est utilisé. Pour éviter les interférences, on pourrait imaginer que quand un appareil se connecte en Bluetooth, on éteint le Wifi (avec rfkill par exemple), on met MPD en pause (ou on le stoppe s’il est en train de jouer un flux) parce qu’on ne peut plus le contrôler, puisque le Wifi n’est plus actif, et on réactive le Wifi quand l’appareil Bluetooth est déconnecté. On pourrait même être plus fin et détecter quand du son est joué.
-
Automatiquement mettre MPD en pause lors d’une connexion Bluetooth. (un peu doublon avec le précédent point) Pour l’instant, il faut manuellement mettre en pause mpd, sinon les deux flux audios se jouent en même temps.
-- Changer la classe Bluetooth de l’appareil. Ça permettrait à l’appareil de se déclarer comme appareil audio, pour que ça affiche le bon icône sur les autres appareils.
-
Mises à jour automatiques. Il ne faut pas que ça casse des choses en pleine lecture, ni que ça cause des interférences avec le Bluetooth à cause des téléchargements.
-
Ne pas persister les logs. Pour l’instant, les logs sont écrits dans
/var/log sur le SSD, entrainant une usure et un ralentissement cependant probablement tous deux négligeables. On pourrait vouloir ne pas les garder, mais c’est aussi risquer de perdre des informations de débogage le jour où il y a un pépin.
Je vais probablement trouver d’autres choses à améliorer après publication de l’article. Je partagerai peut-être les choses intéressantes en commentaires ou dans des journaux, et je ferai peut-être vivre l’article sur mon site.
Connexion
