J’ai posé ta question à Claude et la réponse est mitigée :
"Oui, je pense qu’il faut passer à @sonn-audio/node-airplay. Mais en l’examinant, j’ai trouvé un problème plus important que le choix de la bibliothèque : il touche les HomePod quelle que soit la bibliothèque utilisée.
Pourquoi changer
- Maintenance :
@lox-audioserver/node-airplay-senderest archivée, alors que la nouvelle a été publiée fin août et que la 0.1.2 date du 22 septembre. - Licence : la nouvelle est sous Apache-2.0, comme le template, et n’a aucune dépendance. L’intégration pourrait donc quitter l’AGPL que je lui avais imposée à cause de l’ancienne.
- Qualité : l’auteur dit l’avoir testée sur un HomePod (OS 27) et un BeoLab 50. Elle gère vraiment AirPlay 2, en choisissant automatiquement la méthode de synchronisation que l’enceinte accepte (PTP ou NTP). Elle gère aussi l’échange d’authentification de certains vieux récepteurs AirPlay 1 qui refusent la connexion sans lui.
- Un argument fort : son README indique que les HomePod et Apple TV récents (OS 27) acceptent une session AirPlay 1 mais restent muets. L’ancienne bibliothèque ne faisait qu’un AirPlay 2 « best-effort ». Sur un HomePod récent, l’intégration actuelle risque donc de ne produire aucun son.
Ce que ça coûte
- La bibliothèque est jeune (0.1.x, un seul auteur).
- Son interface est bas niveau : connexion, synchronisation, paquets audio. Il faudrait réécrire la logique de lecture, soit environ 250 lignes dans
src/player.jsCette session n’est pas en cours d’exécution, ses fichiers ne peuvent donc pas être ouverts. Envoyez un message pour la relancer.. - Ce fichier est isolé du reste : la découverte, les scènes, le widget et les tests de l’application ne changent pas. Il faudrait seulement conserver en plus le champ
etdes enregistrements mDNS.
Le problème de fond, que la bibliothèque ne règle pas
J’ai vérifié dans le code de Gladys comment il crée le conteneur d’une intégration. Il est sur un réseau Docker en mode bridge, avec toutes les capacités Linux retirées. Aucun mode réseau host n’est possible, ni pour le conteneur principal ni pour un sous-conteneur, et les ports exposés sont attribués au hasard.
- Pour les HomePod / Apple TV (PTP) : l’émetteur doit servir l’horloge sur les ports UDP 319/320, et l’enceinte vient l’interroger à l’adresse que l’émetteur lui donne. Cette adresse serait l’IP interne du conteneur (172.x), injoignable depuis le réseau local. Ces appareils resteraient donc probablement muets.
- Pour les enceintes tierces en NTP et les récepteurs AirPlay 1 : c’est plus favorable, mais rien ne le garantit, car l’enceinte doit aussi recontacter l’émetteur.
Je l’avais signalé comme une limite ; c’est en réalité potentiellement bloquant pour les HomePod. La vraie solution serait que Gladys propose une option réseau pour ce type d’intégration. Ça vaudrait la peine de l’aborder avec les mainteneurs de Gladys."
Peut-être garder cette solution sous le coude et attendre qu’elle mature un peu ?
Et en réalité, je n’ai pas encore eu l’occasion de tester mais ça n’est peut-être pas encore possible de passer en intégration externe en l’état