Le projet Tune, un concurrent à Roon, libre, gratuit et Français ?

[kole]

Ça picote dure....

[Steph44200]

La proposition musicale de Tune sous Fedora est excellente, j’y retrouve plus de plaisir et de laisser aller qu’avec Daphile en UPNP ou Squeezebox, toujours sur l’Eversolo A6.
Je lance un album, ne zappe pas, me surprend à lever la tête de mon écran, interpellé par un passage, une rythmique, un effet gauche droite :

Par exemple sur ce SACD :

[Mac Brehilt]

Bonjour, 

J'ai réalisé dans un boitier mini pc métal, un duo sur 2 nucs: audirvana et Tune sur Ubuntu studio. 
Chacun est alimenté par Teddy Pardo, le réseau est switché par silent angel bonn 8 sur alim teddy pardo, tous les cables alim, secteur, usb et rj45 sont réalisés par moi avec des matériaux THDG et blindés à souhait. 
Le boitier mini PC est mis à la terre.

Ce que je peux dire en terme de qualité d'écoute c'est que Tune me comble totalement. 
Autant audiravana est excellent, mais la présentation du soft est superbe chez Tune, et les possibilités de gestion de la bibliothéque bien supérieurs ( la seule remarque c'est de ne pas pouvoir faire défiler les pochettes avec le clavier + fléches sur pc, la barre de défilement vertical est trop fine pour être choppée facilement au doigt ou à la souris, notamment pour ceux qui ont un tremblement de la main ).

Pour ce qui est de la qualité sonore, le comparatif se fait avec audiravana, RJ45 vers EmmLabs NS1, puis Meitner Ma1 par fibre optique Lifatec, puis Goldmund Telos et enfin Apertura Variation Ultime. 
Pas de doute, le niveau sonore est superbe et me satisfait au point que je pense laisser audirvana ( SAV plus que moyen ) pour Tune sans l'ombre d'un doute, les dernières versions m'ont totalement convaincu. 

Merci Monsieur Renescence.

[FranckLeRouge]

Bienvenue dans le club de ceux qui possèdent encore des oreilles...et qui n'ont pas peur de le dire haut et fort.... 

[yacine]

Il y a maintenant un vrai choix pour tous les goûts et tous les budgets et Tune ne fait que proposer ce qu'il y a de meilleur à l'heure actuelle en ce qui concerne l'écoute de musique dématérialisée. On est en droit de préférer l'excellence....ou pas !
Tune devrait être prêt dans sa version finalisée avant la fin de l'année, même s'il faudra probablement lui pardonner quelques bugs résiduels pendant quelque temps...

[laguespa]

Voilà une excellente nouvelle

[Van Der Graaf Generator]

 !

[ThierryNK]

Bonjour

...

4) UDP CONTRE TCP - la question de ThierryNK, que fabien44 s'était engagé à
  me poser

Merci à tous les deux, la question méritait une réponse précise et pas une
formule. Je suis allé relire le code plutôt que de répondre de mémoire.

Tune ouvre des sockets UDP à sept endroits. SIX ne transportent AUCUN audio :

  - découverte SSDP (UPnP)
  - découverte mDNS (Bonjour)
  - annonce SSDP du serveur
  - découverte SlimProto
  - découverte des serveurs Tune distants
  - synchronisation d'HORLOGE entre zones groupées

Le septième est AirPlay, qui utilise RTP sur UDP. Ce n'est pas un choix de
Tune : c'est la spécification d'Apple. Aucun logiciel ne fait AirPlay en TCP.

Et surtout : le DLNA et l'UPnP, c'est-à-dire ce que la quasi-totalité d'entre
vous utilise, passent par du HTTP sur TCP. Même chose pour OpenHome, Chromecast
et la sortie USB locale.

Donc, ThierryNK : votre raisonnement sur UDP est juste sur le fond, et il ne
s'applique pas au chemin audio de Tune, sauf en AirPlay où personne n'a le
choix. Si un jour vous constatez une coupure sur un chemin DLNA, ce ne sera pas
un paquet perdu, ce sera un bug de ma part - et je le corrigerai comme tel.

...

La documentation de OOAT (protocole réseau de Tune... peut-être...) est décrit ici:

https://mozaiklabs.fr/docs/oaat

où l'on peut lire:

• Un flux UDP pour les données audio (du Contrôleur vers l'Endpoint, unidirectionnel)
  

Et plus loin

Pourquoi UDP pour l'audio
Les données audio sont à haut débit (PCM stéréo 24/192 = 9,2 Mbit/s), sensibles à la latence et tolérantes aux rares pertes de paquets lorsque le tampon est suffisant. UDP donne au protocole le contrôle du rythme des paquets, de la gestion du tampon, et évite le blocage en tête de file.
.

Non, les données audio sont sensibles aux pertes de paquets puisque la piste ne peut pas être reconstituée à l'arrivée s'il manque des paquets. Dans les applications temps réel où le récepteur "préfère" perdre des paquets plutôt que les redemander à l'émetteur, le récepteur "sait quoi faire" quand il manque des paquets (interpoler ou extrapoler une image en video par exemple)

Alors, comme renesenses l'a écrit, l'UPNP de Tune n'utilise pas le protocole réseau OOAT de Tune, parce qu'il faudrait alors que le lecteur UPNP dans le récepteur soit "compatible" avec OOAT, ce qui n'est pas le cas (renesenses l'a écrit, c'est du http sur TCP)

OOAT est alors peut-être un protocole réseau destiné à un usage futur, avec nécessité pour les "endpoints" (drives et lecteurs réseau) d'implémenter le logiciel de lecture ad hoc comme RAAT ou Qobuz Connect.

Je me demande alors simplement ce que fait la description de OOAT sur le site de Tune.

Je me doute bien que ce post ne va pas beaucoup intéresser la plupart des participants à ce fil.

[r11bordo]

Cela arrive les pertes de trames UDP sur un réseau local ? En rj45, il faut s'accrocher pour voir des trames s'évanouir... En wifi, je n'ai jamais mesuré.

[ThierryNK]

Hello Christophe 

Globalement et dans la durée en filaire 0.5% Max.

En wifi, cela monte à 1%, j’ai autour de 0.3% en Wifi malgré un réseau wifi maillé à base de ASUS XT12. 

De toutes façons, de mon point de vue, on choisit des specs qui ne vont pas poser de problèmes a priori.
D’où ma préférence pour TCP pour ce type d’applications.