Architecture
Cette page décrit comment le serveur Tune est construit : ses composants, son démarrage, ses modules et ses extensions. Pour une vue d'ensemble plus courte, voir le Guide technique.
Vue d'ensemble
- Un seul programme :
tune-server, écrit en Rust. Il s'appuie sur le moteur asynchrone Tokio et sur le framework HTTP Axum. - Un seul port (8888 par défaut). Il sert à la fois l'interface web, l'API
/api/v1, le WebSocket d'événements et les flux audio envoyés aux appareils (/stream/…). - Interface web : une application Svelte servie par le serveur. Elle dialogue avec le serveur par l'API et le WebSocket.
- Base de données : SQLite, intégrée au programme, ou PostgreSQL en option. Voir Architecture de la base de données.
- Audio : le décodage, le rééchantillonnage, les traitements et l'envoi vers les appareils se font dans le serveur, sans ffmpeg. Voir Pipeline audio.
Le dépôt et ses caisses
Le serveur est un espace de travail Cargo, c'est-à-dire un ensemble de bibliothèques Rust (« caisses ») compilées ensemble. Voici les principales.
| Caisse | Rôle |
|---|---|
tune-core | Le cœur : bibliothèque musicale, base de données, lecture, zones, sorties audio, découverte des appareils, services de streaming |
tune-server | Le serveur HTTP (routes de l'API, WebSocket, démarrage). Son point d'entrée ne contient aucune logique et appelle tune_server::run ; un autre programme peut ainsi reprendre le même démarrage avec ses propres extensions. |
tune-http-types | Types HTTP partagés entre le serveur et ses caisses de routes |
tune-stream-http | Les routes qui servent les flux audio aux appareils |
tune-streaming-http | Les routes des services de streaming |
tune-smart-http | Playlists intelligentes, collections intelligentes et recommandations à base de règles |
tune-output-api | Le contrat stable entre Tune et ses sorties audio : le trait OutputTarget, pour écrire une sortie hors du dépôt |
tune-plugin-runtime-wasm | Le moteur d'exécution isolé des extensions WebAssembly |
tune-cli | L'outil en ligne de commande tune |
tune-ffi | Une interface C pour embarquer le serveur dans une application (démarrer, arrêter, lire l'état) |
plugins/… | Les extensions livrées avec Tune (voir plus bas) |
sdk/ | Le kit de développement des extensions audio (espace de travail séparé) |
Une application de bureau, tune-desktop, vit dans le même dépôt mais hors de l'espace de travail du serveur. C'est un client léger de la même API.
Démarrage
Au lancement, le serveur suit cet ordre :
- Lecture de la configuration (
tune.toml, variables d'environnement) et mise en place du journal. - Réservation du port HTTP. Si une autre instance l'occupe déjà, le serveur s'arrête avant de toucher à la base. Lancé par le raccourci Windows, il ouvre d'abord le navigateur sur l'instance en place, si elle est de la même version.
- Pendant l'ouverture de la base et l'application des migrations, une réponse d'attente est servie sur le port.
- Ouverture de la base de données et application des migrations.
- Initialisation de l'état (zones, réglages, jetons des services), puis analyse automatique et surveillance des dossiers de musique.
- Remontage des partages réseau, puis enregistrement des sorties audio locales.
- Chargement des extensions.
- Découverte du réseau : SSDP (DLNA/UPnP, OpenHome) et mDNS (AirPlay, Chromecast).
- Tâches de fond, construction des routes, puis ouverture du service HTTP.
Modules du cœur
tune-core compte plus de quatre-vingts modules. Les principaux :
| Module | Contenu |
|---|---|
audio | Décodeurs, rééchantillonnage, DSD (DoP et conversion PCM), traitements (ReplayGain, égaliseur, convolution, crossfeed, dither) |
scanner | Parcours des dossiers, surveillance des changements, feuilles CUE |
library | Bibliothèque : recherche plein texte, pochettes, import, collections |
metadata | Métadonnées : MusicBrainz, Last.fm, empreintes, écriture des tags |
playback, zones | Lecture, file d'attente, enchaînement des pistes, zones et groupes |
outputs | Sorties : DLNA/UPnP, OpenHome, Chromecast, AirPlay, Squeezebox, BluOS, HQPlayer, OAAT, sorties locales |
discovery | Découverte des appareils (SSDP, mDNS) |
slimproto | Serveur SlimProto pour Squeezelite et les lecteurs Squeezebox, sans LMS |
streaming | Services de streaming, radios, podcasts |
upnp_server, upnp_renderer | Tune vu du réseau comme serveur multimédia UPnP, et zone par zone comme renderer UPnP |
db | Accès à la base : SQLite, PostgreSQL, migrations |
Événements
Les composants communiquent par un bus d'événements interne : n'importe quel module peut émettre un événement, et plusieurs consommateurs peuvent le recevoir. Le WebSocket /ws s'abonne à ce bus et aux événements de lecture, puis relaie le tout aux clients. Les noms d'événements, comme playback.track_changed ou library.scan.progress, font partie du contrat avec les clients. Voir Référence de l'API.
Extensions
Tune a deux systèmes d'extensions. Ils ne se remplacent pas l'un l'autre : le premier traite le son, le second ajoute des fonctions.
1. Extensions audio natives
- Elles traitent le signal : égaliseur, crossfeed, convertisseur de fichiers audio, Dé-ploc.
- Ce sont des paquets
.tuneplugincompilés pour une plateforme précise et signés. Une signature valide est obligatoire pour l'installation. - Une extension installée devient active au prochain démarrage du serveur.
- L'égaliseur est gratuit. Le crossfeed, le convertisseur et Dé-ploc demandent une licence Tune Premium. Crossfeed Pro est une extension Premium distincte.
- Elles s'écrivent avec le kit du dossier
sdk/et l'outilcargo tune-plugin(new,check,test,dev,pack).
2. Extensions WebAssembly
- Elles ajoutent des fonctions : par exemple le transfert de playlists entre services.
- Une extension est un dossier qui contient un
manifest.json(identifiant, version, permissions, routes, événements suivis, version minimale du serveur, mention Premium) et un modulemain.wasm. - Elle s'exécute dans un bac à sable, avec des limites de mémoire et de temps d'exécution. Elle n'accède pas directement aux fichiers ni au réseau : elle n'utilise que les fonctions que Tune lui ouvre, selon les permissions déclarées.
- Ses routes sont servies sous
/api/v1/plugins/{nom}/….
Extensions intégrées
Certaines extensions sont écrites en Rust et compilées avec le serveur. Elles se signalent à Tune au démarrage et peuvent ajouter des sorties, des zones ou des routes, servies sous /api/v1/ext/{nom}/…. Celles du dépôt :
- Bandcamp : recherche et découverte ;
- CD : lecture d'un CD audio sans l'extraire ;
- Entrée audio : capture d'une entrée USB (platine, S/PDIF, optique) diffusée en direct vers une zone ;
- Concerts (Premium) : concerts des artistes de votre bibliothèque ;
- Pont Roon (Premium) : import d'une archive d'export Roon ;
- DJ et Karaoké (paroles synchronisées).
Une extension intégrée peut rester inactive tant que l'utilisateur ne l'a pas installée depuis le gestionnaire d'extensions.