Vous le savez, tout le monde le sait, un CD ne vit pas très longtemps. 20, 30 ans ? 100 ans au maximum, paraît-il, mais en conditions optimales, c'est-à-dire stocké dans un endroit dont l'hygrométrie et la température y sont strictement contrôlées. La seule solution, hors le vinyl ? Les sauvegardes, de disque en disque...

J'ai donc commencé à ripper tous mes CD (une vingtaine sont en fait déjà morts) en vue de les coller sur un serveur. Cela s'appelle un media center. Oui, je sais, ça existe depuis longtemps, sur tous les systèmes d'exploitation, et on peut ainsi distribuer chez soi tant de la musique que de la vidéo, mais je ne m'y étais pas attaqué pour plein de raisons. D'abord, la flemme, mais pas que. Un ordinateur ronronnant en permanence dans le salon ? Et puis quoi encore ?

C'est quand le Raspberry Pi est sorti que le concept a pris forme. À l'origine, je n'en ai pris un que pour l'intégrer sur mon pedalboard en tant que pédale d'effet, ce qui est en effet le cas aujourd'hui (on en reparlera plus tard). Mais l'idée faisait son chemin et j'ai continué à ripper/encoder en FLAC tous mes CD, enfin le plus possible : actuellement, 350 sur 500. Tout est mis sur un disque à part connecté à un vieux Linksys NSLU2 (le même que celui du Slab et du Slampler) sur lequel tourne un serveur NFS et où se trouvent déjà mes sauvegardes.

Ensuite, l'application. Il suffisait dans un premier temps de prendre un logiciel reconnu, tout en un, de connecter le RPi à la télévision par HDMI, de tester avec quelques albums stockés en local, puis d'étendre le système par un serveur de fichiers distant, une carte son externe, un petit écran dédié, une télécommande, etc.

XBMC

XBMC était le choix logique. Un logiciel maintenu avec une grosse communauté d'utilisateurs, un forum actif, tout qui va bien, on essaye, d'autant plus qu'un port spécifique existe pour le Raspberry Pi : raspbmc.

Et ça marche presque bien dès le départ, en effet. Il faut simplement configurer un peu le système en faisant monter le volume NFS par /etc/fstab et régler différents paramètres dans l'interface utilisateur. Le son passe par le câble HDMI donc chez moi sur la télévision. Dégueulasse, évidemment. Pas grave, on passe à l'étape suivante, la carte son externe, en commençant par une Behringer à pas cher.

Mais XBMC ne reconnaît pas la carte-son, car XBMC ne supporte pas ALSA.

A priori, on peut comprendre : moi aussi, j'ai du mal à supporter ALSA. Par exemple, je ne comprends toujours pas les détails de son architecture après avoir écrit un player de samples et une pédale d'effets. M'enfin... c'est quand même dommage pour un logiciel multimedia sous Linux de ne pas s'appuyer sur les couches standard sous-jacentes. Je ne sais pas très bien ce qui s'est passé en 2013 mais le support de pulseaudio a été abandonné sans penser qu'il eût été bien vu de conserver des fonctionnalités de base comme l'indépendance vis à vis du matériel. Il en existe des versions appelées omxbackport utilisant OpenMAX (quelle bonne idée, personne ne s'en sert sous Linux), censé rendre la carte USB visible dans l'interface. Sauf que non, alors il faut tweaker la conf ALSA (?) et inhiber le chargement d'un module noyau (!) pour que la carte son soit utilisée en lieu et place du DAC interne à base de PWM 1 bit. Apparemment, certains y arrivent. Moi je n'ai réussi qu'à aiguiller le son de la télé vers la carte son pendant 10mn, complètement par hasard, avant plantage. Impossible de retrouver les bons réglages ensuite.

Bref, XBMC c'est de la merde.

J'aurais peut-être pu mieux me débrouiller, et puis il existe des forks paraît-il mieux foutus comme Plex, mais en fait il n'y a pas que ce souci-là. La gestion des vidéos ne m'intéresse pas vraiment alors que c'est un point fort du logiciel, et surtout sa conception monolithique me gênait de plus en plus.

Alors que je commençais à en avoir vraiment marre de passer des heures à chercher une solution à ce qui devrait être un non-problème, je me suis demandé comment je ferais, moi. Après tout, je connais l'API ALSA, coder un système de liste et de sélection des morceaux n'a rien de difficile... C'est l'articulation entre les deux qui pose un problème d'architecture. Derrière l'interface utilisateur, la gestion technique des flux audio s'effectue en arrière-plan, ce qui oriente tout de suite vers un démon (ou un thread, mais mes interdits religieux restent bien trop contraignants dans ce contexte applicatif), communiquant par socket avec le front-end. Ce qui m'a fait penser à quelque chose...

Music Player Daemon

Cela existe, évidemment. mpd, repéré au cours de pérégrinations dans les packages Debian, d'abord écarté car pas assez tout en un et d'un abord peu engageant, mpd, donc, s'avère après réflexion parfaitement adapté. Le démon fait son boulot discrètement. Il gère tous les formats de fichiers ainsi que la carte son (par ALSA, heh). Une pléiade de clients, comme Sonata et GMPC sous Linux ou MPoD sur iPhone, permet de contrôler la lecture à distance autant qu'en local. Il suffit de leur donner l'adresse IP du serveur et ça juste marche.

Dernière étape... non, avant-dernière. L'écran pour se débarrasser de la télévision quand on lance un client en local. Un projet de petit écran HDMI financièrement accessible existe sur Kickstarter ; en attendant, les moins chers des écrans de recul pour voiture font 4"3 de diagonale, soit la taille d'un smartphone, et coûtent dans les 20 €, mais il vaut mieux prendre un 7" comme celui-ci car l'interface composite rend difficile la lecture des petits caractères.

Enfin, il ne restera plus qu'à greffer un capteur infrarouge aux broches du connecteur GPIO du Raspberry Pi pour commander la sélection des morceaux en local à la place de la souris actuelle.

Et les CD, et leur lecteur, iront se faire oublier à la cave.