DEV Community: Nirina Rabeson

Comment rendre n'importe quelle enceinte compatible Airplay !

Nirina Rabeson — Sun, 15 Sep 2024 13:00:26 +0000

Vous avez déjà des enceintes audio, et elles sont top. Mais elles ne sont pas compatibles Airplay, et vous êtes jaloux·se de votre camarade qui a acheté les plus récentes SONOS.

Avec ce guide, transformez toutes vos enceintes de musique pour qu'elles soient compatibles Airplay ! Et vous pourrez traiter votre camarade de pigeon !

Le setup

Je suis ce qu'on appelle un audiophile hypocrite. Je passe mon temps à écouter de la musique, à me plaindre de la production, de la qualité, de l'audio, et ensuite j'écoute ma musique sur des focales mêmes pas sur-élevées... (Promis, je cherche des pieds).

Même s'il s'agit plutôt d'enceintes de monitoring que des enceintes de musique, elles ne restent pas moins excellentes à leur job, et j'aimerais pouvoir streamer ma musique pas du tout lossless sur ces enceintes depuis mon canapé.

Comment initialiser la Raspberry Pi ?

Ce tuto est grandement inspiré de https://www.xda-developers.com/build-airplay-receiver-using-raspberry-pi/.

Pour mon setup à moi, je passe par une carte son qui possède une entrée USB C. Il suffit donc de la connecter en USB. Pour un autre support, il paraît que l'audio des raspberry n'est vraiment pas dingue ! Mais vous pouvez toujours tenter la sortie jack, voire la sortie HDMI.

Mettre en place la Raspberry

Je recommande d'installer une image lite sur votre carte SD. Par exemple, Raspberry OS Lite via Raspberry Pi Manager https://www.raspberrypi.com/software/.

Pour ne vraiment pas galérer, je recommande de mettre en place la connexion wifi depuis le gestionnaire, ainsi que le mot de passe du compte par défaut.

Une fois la carte flashée et branchée, que vous êtes connectés (via ssh ou directement sur la raspi), lancez ces petites commandes pour installer et initialiser shairplay-sync :

sudo apt-get install shairport-sync # cette étape peut être longue
sudo systemctl start shairport-sync # démarrer le service
sudo systemctl enable shairport-sync # démarrer le service automatiquement à chaque boot

Il faut ensuite trouver la carte son ou votre périphérique sur lequel vous voulez stream votre musique. Pour cela, on va lancer cette commande :

# Lister les périphériques disponibles
aplay -l

La sortie peut ressembler à :

**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
  Subdevices: 8/8
  Subdevice #0: subdevice #0
  Subdevice #1: subdevice #1
  Subdevice #2: subdevice #2
  Subdevice #3: subdevice #3
  Subdevice #4: subdevice #4
  Subdevice #5: subdevice #5
  Subdevice #6: subdevice #6
  Subdevice #7: subdevice #7
card 1: M2X2 [M-Track 2X2], device 0: USB Audio [USB Audio]
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 2: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
  Subdevices: 1/1
  Subdevice #0: subdevice #0

Dans ce cas là, je veux connecter à l'appareil M2X2, mais vous aurez peut-être d'autres noms, ou vous voulez peut-être vous brancher à la sortie hdmi...

Toujours est-il, mettez ce nom du périphérique dans le le fichier de conf de shairport :

sudo vi /etc/shairport-sync.conf

Décommentez la ligne contenant output_device et mettez le périphérique recherché en préfixant par hw:

- // output_device = "default"
+ output_device = "hw:<nom du périphérique>"

Relancez shairport et montez le son :

sudo systemctl restart shairport-sync
sudo amixer sset PCM,0 100%

Et normalement, tadaaaa ! Votre raspberry pi est visible dans votre airplay !

Et tadaaaa ! Mes focales sont désormais compatibles Airplay ! Plus besoin de payer des enceintes bien trop chères pour ce qu'elles sont !

Une suite ?

J'aimerais bien créer une image raspberry déjà toute prête pour tous les appareils que vous souhaiteriez transformer en enceintes airplay, mais pour être franc je ne comprends pas la doc de sdm... Si quelqu'un a une idée pour m'aider je suis preneur !

GitButler : un client git avec trop de hype ?

Nirina Rabeson — Mon, 18 Mar 2024 19:48:37 +0000

Vous maitrisez git ? Vous êtes un·e expert·e des features branches, vous aimez tester le travail de vos collègues et vous aimez attendre que quelqu'un relise votre travail ? Votre fusions de travail marchent systématiquement ?

Moi non ! (humour) Et maintenant que GitButler existe, je m'interroge comment on peut faire mieux.

Comment travailler en équipe ?

Le standard moderne de collaboration d'équipe est git. C'est un programme qui permet de créer des "branches" sur lesquels les collaborateurs d'un projet travaillent. Ces branches permettent de fusionner les contributions de chacun et de fluidifier le développement parallèle, et à terme tout le monde développe une application commun qui peut être envoyée à des utilisateurs.

Il y a plusieurs "standards" qui sont apparus pour utiliser git, mais les principaux que je vois le plus sont :

Une organisation en gitflow git.flow.readthedocs.io
Le trunk based development Trunk based development

Ces standards permettent d'organiser la répartition du travail et leur intégration, mais ils ne répondent pas à la question de comment vérifier que l'appli finale marche. Comment ça se passe après-tout ?

La réponse va vous surprendre : l'appli finale fini par marcher avec beaucoup de larmes et de sang.

Comment s'assurer qu'une appli fonctionne ?

Dans un environnement de travail moderne, lorsqu'un développeur fait une contribution à un projet, il ou elle soumet une demande de merge de sa branche (PR ou MR) et ses collaborateur·ices relisent le travail et font le travail sur la branche de la personne.

Si le travail est approuvé, et qu'il est fusionné sur la branche de travail principale, les collaborateur·ices relancent à nouveau toute une batterie de tests pour s'assurer que l'application continue de tourner.

S'il y a des problèmes à une seule de ces étapes, on annule toutes les fusions et on revient à l'étape développement sur une branche à part, avec potentiellement un rebase.

Et s'il n'y a pas de problème, tout le monde doit récupérer la modification et à nouveau vérifier que sa demande de merge fonctionne encore, et refaire des tests, et bis repetita.

Mais pourquoi le travail de l'un sur sa machine ne marcherait pas sur celle des autres ? Et pourquoi faut-il revérifier tout le travail une fois qu'il a été approuvé ?

La raison simple, c'est que chaque demande de merge crée une distance entre le développement réalisé et l'existant. Cette distance crée un risque et fait que la fusion du travail peut mal se passer. On travaille donc en réduction de risque et je ne suis pas sûr que ce soit un état d'esprit à adopter dans un travail collaboratif.

D'une certaine façon, on ne vérifie pas que l'appli fonctionne lors d'une fusion de travail, mais plutôt, on vérifie que la fusion ne casse pas l'appli.

Serait-il possible de changer le paradigme de pensée ? Est-il possible de s'assurer que la contribution réalisée soit intégrée au plus vite sur l'application finale ? De réellement tester que l'appli fonctionne, plutôt que personne ne casse le build ? Analysons pourquoi cela est difficile.

Loin des yeux, loin du coeur ; loin de `main`, loin de `merge`

Pour réaliser une quelconque contribution avec l'aide de git, on part en général de la branche principale, ici main. La personne fait son travail, et ensuite fait sa demande de merge et rattrape éventuellement avec un rebase les développements faits sur main.

Les autres contributeurs du projet relisent la demande de merge, et font éventuellement des tests de la contribution en se plaçant dans la branche avec la commande switch ou checkout.

Mais le changement de branche peut-être terrible. Par exemple, voici les commandes que je dois lancer à chaque fois que je change de contexte sur un projet javascript :

# changer de branche
git checkout feature/whatever
git pull --rebase
# Installer le projet en espérant avoir le bon package manager
# Merci https://github.com/antfu/ni
ni
# faire des tests de lint et de type et de format
nr build
# faire des tests unitaires variés (avec parfois de la mesure de coverage)
nr test
# faire des tests E2E et d'intégration (facultatif)
nr test:e2e
# faire des tests manuels divers et variés sur l'application
nr dev
# faire de potentiels tests divers et variés sur l'application un peu plus "finale"
nr start

Et chacune de ces commandes peut prendre entre une seconde à une minute, et cela pour chaque feature qui souhaite être apportée.

Avec un peu de chance toutes ces commandes sont exécutées automatiquement avec une pipeline, ce qui diminue le risque d'un problème durant une fusion de travail.

Mais ce n'est pas parfait, car une fois le travail approuvé et fusionné, il faut refaire toutes ces étapes en local sur son propre environnement et sa propre branche avec la modification intégré.

Les manipulations de branches sont relativement simples dans git, jusqu'à ce qu'il y ait besoin de rebase plusieurs branches, de gérer les conflits, de sélectionner de façon spécifique les commits que l'on veut intégrer... Et chacun de ces modifications créent des manipulations parfois complexes, qui nécessitent encore des tests, de l'intégration, des installations. Et en cas d'erreur, c'est difficile de savoir à quelle étape on s'est planté.

Voyons comment on peut simplifier tout cela avec GitButler.

Comment intégrer le travail de tous, passé, présent, et futur, de façon continue ?

GitButler est un workflow de git qui permet de se passer du contexte de branches et le remplace par celui de branches virtuelles.

Regardez cette vidéo qui expliquera à quel point c'est renversant 🙃 :

youtube.com

Avec GitButler, sur un ordinateur local, il n'y a qu'une seule branche qu'on va nommer workflow. Quand je dois travailler sur ma feature, je fais mon travail dans workflow, je commit sur workflow.

Si on était en git classique, il suffit de push ma modif... Mais je ne peux pas, car la branche workflow n'est pas ma branche... C'est comme si je poussais sur main... Comment créer ma branche ? Comment faire ? 😨

L'idée de GitButler, c'est qu'il n'y a pas besoin de se poser ces questions.

On peut automatiquement depuis GitButler créer une branche virtuelle à partir d'un commit (imaginez un git rebase -i user-friendly), mais le travail reste sur la vraie branche workflow.

Pour demander une relecture, GitButler transforme la branche virtuelle en une vraie branche (pour permettre par exemple à une CI ou à des collègues de récupérer le travail), et lorsque la modification est approuvée par ses collègues, la branche est branchée dans main du projet.

La magie de GitButler, c'est qu'une fois la modification mergée sur main, et même avant, les contributions de tous les autres peuvent être déjà appliquées sur notre branche locale workflow. On peut même directement récupérer main distant sur notre workflow local, sans avoir besoin de pull ou rebase ou merge.

L'interface est très simple et permet de fusionner beaucoup de commits de façon simple, et de façon revenir sur les modifications vu qu'on a pas besoin de changer de branche, tout simplement.

La panoplie de tests que l'on réalisait auparavant sur chaque branche peut-être exécuté sur une seule branche, en prenant en compte facilement le travail passé, présent et futur du projet.

Vous me direz, on peut déjà faire cela avec des cherry-pick, des rebase et autres joies. Mais dès lors que vous avez beaucoup de contributions, c'est difficile à gérer simplement.

Dans l'autre sens, si on veut pousser beaucoup de modifications, et éventuellement en beaucoup de MR ou PR, c'est difficile à faire avec chaque branche qui sont potentiellement liées entre elles.

Il y a bien des inconvénients ??

Pour l'instant je vois plusieurs arnaques, car le projet est bien récent :

Pour être franc, je me sens toujours un peu perdu dans GitButler tellement c'est différent
Le projet est très récent et il se pose encore des questions fondamentales non résolues dans GitButler (comment fusionner de vraies branches ?)
Pas d'invite de commande à ma connaissance, tout se fait par leur GUI (et je déteste ça)
C'est un peu difficile de savoir ce qui est sur notre branche workflow, et si elle correspond bien à l'appli finale...
Les gens ne semblent pas comprendre à quoi sert réellement GitButler ? Sur les internets je vois beaucoup de commentaires de gens pour qui ça va leur permettre de mieux gérer leurs 40 stashs ou leur rebase à 70 commits, mais pour moi c'est plutôt un problème d'organisation qui peut déjà être corrigé sans GitButler...

Les "arnaques" que je présente sont surtout de la méfiance par rapport à une technologie nouvelle. Cela ne m'empêche pas d'être hyped.

Il y a aussi une quantité d'enablers que pas tout le monde est prêt à entendre ou à mettre en place :

Avoir des CI/CD très robustes
Avoir la culture de la qualité, car on ne peut pas s'amuser à planter la branche principale pour tout le monde.
Avoir une séparation du travail claire pour éviter de faire exploser le nombre de merge conflicts
Avoir une definition of done claire et partagée auprès de toute l'équipe, en lien avec la culture de qualité de l'équipe.

Ces enablers sont de mon point de vue fortement similaires à ceux pour réaliser du Trunk Based Development.

La suite de GitButler ?

De mon côté, j'ai essayé d'intégrer GitButler dans un de mes projets où je suis le seul à l'utiliser pendant que le reste de l'équipe reste sur un schéma GitFlow. J'avoue que j'ai eu marre de lire des issues github et de suivre leur discord pour comprendre pourquoi des fonctions de base étaient manquantes.

D'une façon plus générale, utiliser GitButler nécessite à tous les contributeurs d'un projet d'augmenter leur attention à la qualité, car avec ce workflow, on n'est plus seulement responsable de sa branche, on est responsable de l'ensemble du projet. À voir si l'industrie est prête à l'entendre...

Je m'appelle Nirina, je suis développeur front chez Zenika, et merci pour cette lecture 🌻

Et vous, que pensez-vous de GitButler ? Êtes-vous prêt à faire le saut ? Jetez-y un coup d'oeil : https://gitbutler.com/

Comment l'IA change radicalement le son des guitares électriques.

Nirina Rabeson — Sun, 28 Jan 2024 09:20:01 +0000

Vous avez sûrement déjà une fois dans votre vie écouté un morceau de musique contenant de la guitare, mais vous-êtes vous déjà demandé comment le son de cette guitare est produit ?

A priori, vous vous dites qu'il faut une guitare, un ampli de guitare et un micro pour capter le son, pour obtenir une installation ressemblant à cela (source):

Et si je vous disais que ce morceau de musique contenant de la guitare que vous venez d'écouter n'utilise (probablement) pas d'ampli de guitare ? 😱

Vvous entendez tout simplement une émulation digitale, basée sur le machine learning.

Mais comment le son d'une guitare est-il produit ?

Tout commence par des micros

Les amplis de guitare sont tels qu'ils sonnent aujourd'hui un peu par une coïncidence. Quand les premières guitares électriques ont été inventées, il a fallu fabriquer des amplificateurs pour qu'on entende quelque chose. Le son d'une guitare électrique est produit à partir de micros utilisant un système de bobinages, qui captent les vibrations des cordes en métal. C'est cette partie de la guitare :

C'est très bien, mais le seul soucis, c'est qu'on n'entend rien ! Le signal produit par ce micro est très faible et il faut alors l'amplifier.

Les premiers amplificateurs

Pour amplifier un signal, aujourd'hui on utiliserait un transistor. Mais les premières guitares électriques remontent d'avant l'invention même des transistors ! Les fabriquants ce sont alors tournés vers ce qui existait et était accessible pour l'époque : les tubes électroniques, ou vacuum tubes en anglais.

Les premiers groupes de rock à utiliser des guitares électriques ont ce qu'ils avaient sous la main, à savoir des amplis à tubes électroniques, et ces groupes sont devenus hyper mainstream (The Beatles, Pink Floyd, ACDC, Guns and Roses...). La culture populaire a donc associé le son des guitares à des amplificateurs utilisant des tubes électroniques.

Sauf qu'un ampli à tube, c'est hyper galère à utiliser...

Et quel sont les problèmes des amplis à tubes électroniques ?

Aujourd'hui, les tubes ont de nombreux problèmes pratiques pour faire de la guitare :

Les amplis à tubes pèsent une tonne
Plus personne ou presque ne fabrique des tubes électroniques
Ils sont plutôt fragiles comparé à des transistors
Les amplis à tubes coûtent très cher
Ils ont des volumes sonores beaucoup trop élevés.

Pour le dernier point, cela vient du fait que pour atteindre le maximum d'un ampli à tubes, il faut mettre son gain et son volume au maximum, et je vous laisse imaginer pour les voisins ce qu'ils en pensent...

Pourquoi ne pas alors les remplacer par des transistors ?

Excellente question, et la réponse est simple : un transistor a un comportement différent, d'un point de vue du traitement du signal, d'un tube électronique.

Cette différence est suffisante pour que cela s'entende, et surtout suffisante pour que cela ne sonne pas comme les groupes mainstream qui ont défini le son d'une guitare électrique (rappeler vous, The Beatles, Pink Floyd...).

C'est pourquoi, on utilise des amplis à tubes électroniques : personne ne veut que sa guitare sonne différemment... (sous entendu, mal), et le public en général s'attend à entendre des tubes (même si au fond tout le monde s'en fiche des guitares).

Comment remplacer un ampli à tubes donc ?

Pour pouvoir remplacer un ampli à tubes, il faut savoir d'abord ce que l'on veut modéliser, ce que l'on cherche, qu'est-ce qui fait le son d'une guitare.

Un ampli à tubes, c'est un circuit électronique qui réagit de façon non linéaire à un signal entrant. Cette non-linéarité c'est concrètement ce qui produit le son riche d'une guitare, le fameux overdrive, voire distorsion quand on pousse le volume. Voici un exemple visuel de distorsion :

En haut, on peut considérer que c'est le son produit par une guitare, et en bas on peut considérer que c'est le signal émis par l'amplificateur. On peut remarquer que ces deux signaux n'ont presque rien en commun, si ce n'est qu'ils montent et descendent en même temps.

Cette distorsion, c'est le fameux son caractéristique d'une guitare. Si je vous mets le début Highway to Hell de ACDC, vous reconnaissez instantanément le son : https://www.youtube.com/watch?v=l482T0yNkeo

Recréer une distorsion produite par un tube avec des transistors est difficile, mais non impossible. Mais comme il s'agit d'un phénomène non linéaire (comprendre, très compliqué d'un point de vue de la physique), il faut une très grande finesse pour réussir à produire un son convaincant. Pour chaque petite différence tonale entre une distorsion à tube et un transistor, il faut faire un petit affinage, et il y a des millions voire des milliards de petites différences tonales qui sont toutes à faire méticuleusement... si seulement il existait un moyen de configurer des milliards d'affinages facilement... 🤔

L'IA à la rescousse de la guitare

Voici un crash course de l'IA : on prend un réseau de neurones, c'est un ensemble de paramètres qui savent se reconfigurer de façon autonome pour imiter un comportement en fonction d'une entrée et d'une sortie.

Ce réseau de neurones, on va lui donner deux éléments :

En entrée, on donne un signal que l'on a enregistré auparavant qui correspond à ce qu'on donnerait à un ampli de guitare.
En sortie, on retourne le signal produit par l'ampli de guitare.

On pourrait dire que l'entrée correspond à ce qu'un guitariste pourrait jouer, mais c'est un peu lent et on préfère envoyer une sorte de "bruit blanc" qui permet de pousser l'ampli au maximum de ses capacités, et cela sonne comme ça : Baissez le son avant d'écouter ce truc siouplé

Ce qu'on demande à l'IA, c'est de faire en sorte que son modèle produise la même sortie pour une même entrée que l'ampli. En d'autres termes, on demande à l'IA de reproduire les mêmes non linéarités qu'un ampli de guitare, et on lui demande de l'enregistrer en un fichier qu'on appelle une capture.

Cette capture ensuite peut prendre un quelconque signal de guitare, et restitue donc une sortie comme si c'était un vrai ampli. C'est votre ampli virtuel tout simplement.

Pour les détails plus techniques, on demande à l'IA de réduire la différence entre le signal produit par son modèle et celui enregistré depuis l'ampli, et ensuite vous invoquez l'armée d'outils d'optimisation d'un modèle (tensorflow, pycharm, votre GPU le plus puissant du marché).

Et est-ce que ça marche bien ?

Non seulement ça marche bien, mais en plus, personne n'entend réellement la différence.

Quand je dis personne, c'est que dans un morceau final, mixé, masterisé, pressé, distribué, streamé puis enfin écouté dans un casque ou des écouteurs ou des hauts parleurs d'une qualité variable, personne n'est capable de faire la différence entre un son de guitare sortant d'un vrai ampli, d'un son de guitare venant d'un ampli virtuel capturé par une IA.

En fait, cela marche tellement bien qu'on commence à embarquer des modèles dans des unités portables de plus en plus petites, comme le QuadCortex ou le Line6 HX Stomp.

En fait, cela marche tellement bien que n'importe qui peut capturer son ampli à la maison... Ou des pédales d'effets, ou des hauts parleurs, ou d'autres captures... ou d'autres plugins...

En fait, cela marche tellement bien que des groupes entiers de musique commencent à apparaître parce qu'ils peuvent produire des sons de guitare nouveaux qui n'étaient pas pratiques ou commodes à faire sur des amplis à tubes...

Je vous mets au défi de me dire, entre ces groupes, lesquels utilisent de vrais amplis, et lesquels utilisent une capture :

https://www.youtube.com/watch?v=I0WzT0OJ-E0
https://www.youtube.com/watch?v=qpgTC9MDx1o
https://www.youtube.com/watch?v=pQzxNLfAW8o
https://www.youtube.com/watch?v=zg2076b5Lqc

Vous remarquerez que sur les exemples donné, il y a beaucoup de métal, et c'est un peu normal : c'est le genre dans lequel il y a le plus de distorsion. Et si vous voulez une expérience optimale, écoutez cette musique à 85dB et ce lien vous expliquera peut-être pourquoi !

Peut-on tout capturer ?

Vous remarquerez, je ne vous ai parlé que d'amplis de guitare, mais on peut aussi capturer les hauts parleurs de l'ampli, le micro qui capture l'ampli, les effets appliqués en pré ou post amplification... Tout est capturable.

En fait, aujourd'hui, à peu près tout le signal d'une guitare, depuis les micros jusqu'à la production, est modélisé dans une capture. Et si même l'industrie de la musique le fait, c'est parce que c'est très pratique. Au lieu d'investir dans un ampli pesant des tonnes et coûtant une fortune, on peut acheter un plugin qui contient une infinité de sons possibles pour une guitare, qui sont réglables en instantané.

Et même le jeu des guitaristes commencent à se faire capturer, avec des plugins entiers qui reprennent le jeu d'un artiste, et c'est plutôt convaincant... À vous de vous faire une opinion : https://www.youtube.com/watch?v=Snh6gaHjRN0

C'est pourquoi je trouve que l'IA change radicalement le son des guitares, parce que maintenant en deux clics et trois captures on peut produire n'importe quel son.

Est-ce que c'est pour autant la fin des amplis à tubes ? Je ne pense pas. Déjà, il n'y a probablement personne de plus traditionnel qu'un guitariste, et il faudra longtemps avant que la communauté passe totalement à autre chose.

De plus, les amplis à tube de guitare d'aujourd'hui se modernisent et apportent plein de nouvelles fonctions : sortie audio pour enregistrement direct dans une carte son, effets de guitare intégrés à l'ampli, possibilité de changer en bluetooth les paramètres de la distorsion, système de baisse de volume pour être compatible en appartement... Même les amplis traditionnels se modernisent.

Pour conclure, voici une petite vidéo de moi jouant de la guitare... Saurez-vous dire si je joue sur un vrai ou un faux ampli ?