À Panik on a pas mal d’expérience avec la réalisation d’émissions hors des studios, au fil des années on en a réalisé en quantités de circonstances différentes, on a varié les logiciels, on a varié les matériels, on a de la documentation pour cinq ou six configurations différentes, on a du matériel à prêter, tout se branche bien dans le système de diffusion pour les décrochages, etc.
Mais ça reste attaché à un point de diffusion et cette semaine on s’est trouvé à vouloir faire des émissions à plusieurs mais chacun·e chez soi… En vérité c’est parti plus simple, il s’agissait de trouver un moyen de s’enregistrer à plusieurs, sans le côté direct. La mode allant à Jitsi Meet, ça a été abordé, des choses se mettaient en place pas loin, mais visiblement pour l’enregistrement c’était pas directement ça. De là je me suis remis à chercher ce qui se faisait en WebRTC pour développer le nécessaire, robot qui se mettrait sur la conférence et enregistrerait le tout, et tant qu’à faire robot qui se mettrait sur la conférence et diffuserait le tout, en direct.
Dans WebRTC il y a Web. J’avais déjà regardé ce qui pouvait se bricoler à côté (genre via GStreamer), sans un bon souvenir, et là pas mieux, il y a des trucs épars, trop épars. Là-dessus lecture de l’actualité LinuxFR faisant un topo d’applications utiles et bien sûr, totalement oublié, Mumble, pourquoi pas ? C'est packagé nickel dans Debian, ça s’installe comme un charme, il y a des clients pour tous les OS, côté mobile ça semble un peu léger mais au pire il y a un client HTML5 (mumble-web). Il y a aussi surtout pas mal de robots déjà prêts, je note particulièrement mumblerecbot qui semble un vieux bricolage spécifique mais semble pouvoir s’actualiser facilement.
On est là mercredi et c’est parfait j’ai mon jeudi pour creuser ça pour de bon. La partie serveur de fait s’installe sans le moindre problème et on arrive rapidement à faire des tests concluants à trois ou quatre, je déploie ça proprement, je dépoie aussi botamusique qui semble une bonne base pour pouvoir piloter des fonctions supplémentaires (jingles, musiques).
Reste la partie diffusion, mon idée ici est d’obtenir un client en ligne de commande, qui se connecte et diffuse la son d’un canal, vers Jack pour s’intégrer correctement dans le reste de l’infrastructure. Sur base de pymumble ça ne doit pas être bien compliqué et il y a un exemple qui passe par PyAudio mais désillusion rapide, je n’arrive pas à une bonne qualité.
Nouvelles recherches et un client terminal est cité, barnard, c’est écrit en Go mais rapidement ça compile et fonctionne. (pour mémoire bêtement le truc qui m’a pris du temps c'est après le git clone, trouver qu’il fallait faire go mod init layeh.com/barnard). De là, c’est assez vite fait de créer un patch pour ajouter une option en ligne de commande pour entrer directement dans un canal.
Vendredi boulot et aujourd’hui retour à la tâche pour brancher ça dans le système de diffusion automatisée de la radio. Le plan ici était simple, la lecture des sons est déjà déléguée à un programme externe et comme on n'en est pas au premier bricolage il y a déjà un petit wrapper posé devant (en C, qui forke un process Python qui va aller écrire dans la base de données le morceau joué, et fait un exec de mpv pour la lecture audio).
Hésitation sur le niveau de bricolage ici, mais pas trop, on est quand même dans une situation où on peut se permettre d'hardcoder à outrance, et de toute façon pour bien faire les choses il aurait fallu remonter plus haut pour ajouter une détection qu’une URI mumble:// est à traiter comme un stream, etc. etc. et donc non, simplement hardcoder qu’une URL commençant par http et contenannt mumble va passer par le nouveau code. Et ce nouveau code, juste un exec du barnard modifié, avec les bons paramètres mis sur la ligne de commande). (mais quand même, prendre le dernier bout de l’URL pour décider du canal à rejoindre).
Tout ça est prêt ce matin, on a justement de nouveaux tests audio prévus à 11h, ils se passent bien, je programme cinq minutes de «â€¯piratage » de l’antenne pour tester et plouf, silence. Je lance le wrapper à la main et là ça fonctionne, on nous entend bien, le son est bon, c’est ok.
Il se passe un truc bizarre avec les processus, comme s’il se forkait à outrance et répétait du code du wrapper, et là je galère à tester différentes possibilités, par exemple ne pas faire l'exec directement de barnard mais d’un script Python, où j'aurai plus facile pour logguer et contrôler les signaux, tout ça sans succès. Mais ça ne m’étonne finalement pas trop, je suspectais un peu barnard et la manière dont il fait son interface d’exiger un terminal, ça manque juste de messages d’erreur. Et donc à la hache je retire ces bouts d’UI de barnard, je découvre quelques bouts de Go, et au final à part les lignes supprimées et les quelques bouts d’affichage modifiés pour écrire sur la sortie standard, l’important se résume à :
- b.Ui = uiterm.New(&b)
- b.Ui.Run()
+ keepAlive := make(chan bool)
+
+ b.Config.Attach(gumbleutil.Listener{
+ Disconnect: func(e *gumble.DisconnectEvent) {
+ keepAlive <- true
+ },
+ })
+
+ b.start()
+ <-keepAlive
Avec ça me voilà en possession d’un lecteur de «â€¯flux mumble » en ligne de commande, zéro fioriture, et pluggué dans le système de diffusion, testé quelques minutes, succès dans la diffusion live automatique.
Je ferai encore quelques essais mais la vraie épreuve ça sera lundi pour la matinale, le «â€¯studio » est prêt.
