Analyse : Diffuser Deezer sur toute la maison


Utiliser  mon abonnement Deezer à domicile

Un première solution, le streaming Bluetooth

  • Parmi  les configurations d’écoute à domicile, celle qui me semble avoir le plus de succès aujourd’hui, c’est le streaming Bluetooth.  Pourquoi fait il autant d’adeptes actuellement ? Mon propos peut sembler caustique, mais vous noterez avec moi que Bluetooth fait vendre des enceintes actives, souvent assez chères. Mais il plait aussi aux fournisseurs de contenu, dont la vocation est de donner accès aux titres musicaux via leur portail, mais sans pour autant en  autoriser le téléchargement gratuit. Ainsi, pour ce qui concerne Deezer, on y accède via une application player couplée au navigateur du portable. Les titres musicaux  sont alors restitués sur la carte son du terminal, elle-même reliée via Bluetooth  à des  oreillettes, à un casque, ou à une  enceinte active. Je trouve au moins deux  points gênant à cela. D’abord cela n’ouvre pas la possibilité  de diffuser l’écoute vers plusieurs pièces en même temps. Ensuite le protocole Bluetooth dispose de nombreux profils, dont certains pas toujours supportés par les terminaux. Force est de constater que le profil a2dp, le plus souvent utilisé à la jonction entre un smartphone et une enceinte active, induit une dégradation par rapport à une qualité HiFi.
Gérer le son par un smartphone via Bluetooth, c'est utile. 
Mais sans ces enceintes actives horribles dont on nous inonde.
Et on peut faire mieux et pour moins cher avec une attitude DIY.
Nous avons déjà rendu compte compte de résultats encourageants. 
Mais à consolider avec ESP32-LyraT dans le volet expérimental.

Le WiFi dispose des meilleures capacités à distribuer le son

Avec le WiFi, on dispose d’une meilleure capacité qu’avec Bluetooth à distribuer le son sur l’ensemble de la maison. Par équivalelnce, on peut comprendre la distribution du son via le WiFi au travers d’une offre technologique assez large

Airplay

  • A l’origine, il ya eu la technologie AirPlay d’Apple, qui permettait de diffuser depuis un téléphone ou une tablette de marque Apple vers des enceintes réparties dans le domicile, ou vers sa télévision. N’étant pas utilisateur de produits de la marque Apple, je ne sais pas rendre compte de cette technologie. Mais à l’image de la marque, AirPlay, ça ne fonctionne qu’avec des équipements Apple, et c’est cher.
Nous ne retenons pas Airplay, bridé à la marque Apple.

Chrome Cast, Alexa Cast

  • Plus proche de nous, le technologies Amazon Alexa et Google Chromecast permettent de capturer la restitution musicale depuis son PC ou son Smartphone et de la distribuer va WiFi vers des adaptateurs répartis dans la maison. La première impression, c’est que çà doit être bine moins cher qu’Airplay, que çà doit être plus ouvert aussi à l’utilisation à partir des plateforme Linux ou Android. Mais en contrepartie, ces techniques de cast semblent assez difficiles à administrer « par sois-même ». Je ne serai pas surpris qu’elles conduisent vite à devoir se doter d’adaptateurs ou d’assistants vocaux propriétaires.
Nous ne retenons pas Chromecast ni Alexa Cast.
Le niveau d'abstraction est élevé.
On ne facilité pas l'implantation opensource et DIY.

DLNA, UPNP

  • Bien plus proche de notre objectif, il y a la technologie DLNA et UPNP, qui fait en sorte que des équipements lecteurs puissent accéder à du contenu stocké sur des équipement serveurs. L’avantage de ces technologies, c’est qu’elles sont accessibles en implémentation opensource, et sur linux en particulier. C’est une très donne chose. Reste à voir si c’est bien adapté à une diffusion temps réel, et pour cela rendez-vous dur le volet expérimental qui va suivre.
DLNA/UPNP est disponible :
- côté source LINUX avec pulseaudio & pulseaudio-dlna
- côté client  LINUX avec le package rygel.
DLNA est cité dans les documents ESP32, mais pas traité.
Premiers résultats mais à consolider dans le volet expérimental.

HTTP, RTP

  • Une autre alternative consiste à réduire encore le niveau d’abstraction et à miser sur une sur la couche transport, que ce soit en TCP, RTP et de relier lecteurs et serveurs au travers d’une URL.
- côté serveur (source) sur LINUX avec  icecast2 & darkice
- côté client  Linux avec un  navigateur chromium
- côté client sur ESP32 LyraT avec un exemple bridé HTTP et MP3.
Premiers résultats mais à consolider dans le volet expérimental.