Projet LBM

Description matérielle

J'ai récemment décidé de m'équiper d'un système audio multi-room. L'idée était d'obtenir un système permettant d'écouter la même source (stream via Bluetooth, MP3 stockés en interne, radio, CD) dans plusieurs pièces. Après un petit tour des solutions existantes, j'ai découvert qu'il n'existait pas de système permettant de gérer simplement la radio et les CD.

L'idée m'est donc venue de réaliser moi-même ce système audio, ayant récemment entendu parler du combo Raspberry Pi / hifiberry .

Quelques mois plus tard, et après de nombreuses heures de travail, j'ai réalisé trois amplis autonomes et connectés entre eux :

Le premier (en bois, en bas à gauche), est placé dans le salon. Il est constitué d'une carte rpi3, d'un adaptateur Bluetooth, d'un lecteur CD (avec son alim dédiée), d'une carte son hifiberry Amp 2 (sortie son jusque 60 W). Pour interagir avec, cet ampli dispose d'un écran LCD multi ligne, de deux encodeurs rotatifs/boutons et de quatre boutons. Ces derniers éléments sont aussi présents sur les deux autres modèles. Le boitier a été réalisé en découpe laser.
Pour le deuxième, j'ai évidé un vieil ampli de guitare HS tout en conservant son haut-parleur. J'y ai inséré à la place une alim de 18V et un convertisseur 18V->5V. Une carte Raspberry Pi Zero W, une carte son HiFiBerry Mini AMP 1 (alimenté par le rpi, sortie 5W max). Deux petits HP sont logés en bas de l'ampli et sont constamment reliés à la carte son hifiberry. De son côté, l'HP central peut être relié à la carte hifiberry ou bien à une entrée ligne via un switch. Un petit ampli audio permet ensuite d'alimenter correctement ce dernier. J'y ai ajouté un mini transformateur de découplage pour éviter les problèmes de masse sur le chemin électrique carte hifiberry vers ampli audio.
Le dernier se trouve dans la cuisine. Ce dernier a été réalisé en impression 3D afin de le réduire son encombrement au maximum tout en conservant une qualité audio correcte. Il comporte une carte Raspberry Pi Zero W, une carte son HiFiBerry Mini AMP 1, deux petits HP large-bandes, une batterie (autonomie d'une dizaine d'heures en lecture) et des mêmes boutons que ces prédécesseurs.

Une fois les composants réunis, découpés, imprimés, l'étape de câblage a débutée. Chaque ampli comporte une vingtaine de câbles type jumpers partant des GPIOs du RPI vers les différents éléments. Cette étape est assez longue et fastidieuse car les erreurs de branchement (il y en a toujours !) sont difficiles à détecter. De même, l'utilisation conventionnelle d'une carte son HiFiBerry Mini AMP 1 rend indisponible les ports GPIOs du RPI, j'ai donc dû relier la carte son au RPI directement à partir de jumpers.

Description logicielle

Ayant décidé de partir de zéro, j'ai opté pour l'OS raspbian lite (sans interface graphique) sur chaque ampli. Plusieurs logiciels/bibliothèques m'ont été utiles par la suite :

Les incontournables git (versionning) et vim (éditeur de texte dans le terminal, très utile en SSH)
Mpd/Mpc pour la lecture de musique présente en mémoire et la radio. En pratique, mpd est un logiciel qui tourne en permanence et se charge de lire des listes de lecture. mpc permet ensuite de communiquer avec mpd (modification de volume, lecture , pause, ajout ou suppression d'éléments dans la liste de lecture). mpd peut être paramétré à l'aide d'un fichier de configuration permettant de gérer plusieurs sortie (de mon côté, j'utilise une sortie en local, à l'aide de la carte son hifiberry et une sortie vers snapcast).
Snapcast pour le partage temps réel du contenu. SnapServer reçoit un flux audio (par exemple depuis mpd) et se charge de le transmettre vers toutes les machines présentes sur le réseau local exécutant SnapClient. Snapcast gère ensuite l'envoie des données liées au flux audio et la synchronicité de la lecture sur tous les amplis.
Et au final, j'ai écrit un programme en python3 chargé entre autre, de gérer les entrées et sorties physique de l'ampli, de fournir une interface graphique textuelle sur l'écran LCD, de communiquer avec les autres amplis (notamment pour récupérer le flux audio d'un autre ampli, ou bien pour streamer la source en cours d'utilisation vers les autres ampli) et enfin, de gérer les entrées réseau (application de type télécommande permettant d'utiliser l'ampli à distance sous Android.)

Le code python peut être obtenu sous github ici . Ce code est spécifique à mes amplis, il ne pourra donc pas être utilisé a priori pour un autre système multiroom. Cependant, vous y trouverez une bonne base de départ pour la gestion d'un écran LCD et des boutons. De même, la lecture du code vous aidera aussi à mieux comprendre l'utilisation conjointe du couple mpd/snapcast. Ce programme python est automatiquement exécuté au démarrage du rpi via systemd et la création d'un service.

Pour aller plus loin

Je liste ici toutes les difficultés que j'ai rencontrées pour mener à bien ce projet ainsi que leurs solutions :

Les rpi 3 et zero W ne peuvent gérer de manière correcte le Bluetooth et le wifi en même temps (a priori, problème d'interférence qui réduit radicalement les débits). Ainsi, on ne peut pas streamer du contenu sur l'ampli via Bluetooth si le wifi est allumé.
Sur un des amplis, j'ai ajouté un dongle Bluetooth. Une fois configuré, le problème disparait. Sur les autres amplis, j'ai ajouté un mode permettant d'éteindre le wifi lorsqu'un flux audio est reçu par Bluetooth.
A priori, le problème semble avoir disparu avec le passage sous raspbian buster.
Par défaut, Snapserver envoie son contenu vers toutes les instances de Snapclient qui se charge de la sortie audio. Pour une utilisation locale (c’est-à-dire non multiroom), je trouve l'utilisation de Snapcast un peu lourde. J'ai donc choisi d'utiliser deux sorties sous mpd, une en local (donc pas besoin de snapcast), et l'autre vers l'instance de Snapserver. En pratique, il convient de démarrer Snapserver et Snapclient lorsque cela est utile uniquement.
Concernant la gestion du réseau local, j'ai choisi de ne pas écrire en dur les noms/adresses des autres amplis dans le code python. Cela permet d'ajouter un nouvel ampli ou bien d'en retirer un à la volée.
Pour réaliser cela, j'ai développé une librairie (en python3) utilisant le protocole UDP multicast pour annoncer régulièrement chaque élément connecté à un instant t combiné à des liaisons pair à pair entre chaque entités connectée à l'aide du protocole TCP. Cette librairie est complétement indépendante du reste du projet et peut être utilisée à d'autres fins. Elle peut être obtenue ici .
Afin d'éviter la création (et la gestion) de nombreux threads, j'ai choisi d'utiliser asyncio pour la gestion de la partie TCP.
A l'aide de cette librairie, les différents amplis (ainsi que les télécommandes) se découvrent mutuellement et peuvent ensuite facilement communiquer entre eux.
Après quelques jours d'utilisation, l'envoi des message UDP multicast semble dysfonctionner. N'ayant pas réussi à trouver la cause de ce phénomène, j'ai ajouté un restart journalier du programme (à 15 h, sauf si l'ampli à été utilisé récemment.). Depuis, les problèmes ont disparus.
Le régulateur interne du rpi ne permet pas d'alimenter correctement un lecteur de CD externe. Mon ampli possédant le lecteur CD étant branché sous 18V (c'est la carte hifiberry amp2 qui se charge de délivrer les 5V au rpi), j'ai ajouté un convertisseur 18V-5V de trois ampères max pour alimenter correctement le lecteur CD via un câble dédié.
L'utilisation de boutons et encodeurs rotatifs n'est pas aisée avec le rpi. En effet, ce dernier ne fonctionne pas en temps réel (comme c'est le cas pour un microcontrôleur ou bien une carte Arduino) et donc certains signaux électriques se perdent. J'ai donc chercher à optimiser au mieux le code gérant ces entrées et opté pour des encodeurs rotatifs munis de condensateur pour limiter au maximum les effets lié au switch bounce. Cela étant fait, je rencontre encore de temps en temps des soucis avec les encodeurs. A mon avis, il faudrait investir dans un microcontrôleur dédié pour la gestion des entrées. Ce dernier communiquant ensuite avec le rpi via une liaison i2s par exemple.