UPnP - RAAT - SlimProto - ... ?

[n.d.b]

Un sujet pour savoir pourquoi les protocoles "sonnent" de manière différente.
Informaticiens demandés

Contexte
- par le passé en jouant sur le protocole AirTunes, j'étais arrivé à un niveau convaincant de stream en saturant le flux et jouant sur le buffer
- niveau battu par GoogleCast à l'arrivée des Chromecast
- niveau battu par UPnP diffusé par Audirvana
- niveau battu par SlimProto, LMS
Et Roon/Raat pas essayé

Donc il doit y avoir quelque part par construction du flux et du "dialogue" un truc qui fait que ça ne sonne pas pareil au final et ce sans upsampling, sans toucher à quoique ce soit.

Là on a SlimProto
https://wiki.slimdevices.com/index.php/S...P_protocol

A priori je ne vois pas ce qui peut changer. 
Ecoute, transfert, buffer, information retour du "où en est le lecteur" etc. Rien de vraiment différent de l'UPnP, si ? 

Y a-t-il quelque chose qui pourrait expliquer des changements ? 
- paquets ? 
- contrôle ? 
- tempo ? 

Qui a techniquement réellement comparé le fonctionnement de ces protocoles ?

[Nard]

Bonjour N.D.B,

Bien malin qui saurait dire vraiment pourquoi, et pourtant les logiciels, les protocoles ne sonnent pas tous pareils, c'est une évidence à l'écoute.

L'hypothèse qui rend le mieux compte du phénomène est celle du jitter logiciel et du bruit électronique. Selon les traitements, il y a plus ou moins de commutations de transistors, de latence et de bruit de phase.

Cela se propage d'un dispositif à l'autre et finit par s'entendre, impactant la transparence, la bande passante, la scène sonore...

[n.d.b]

(10-20-2020, 11:02 AM)Nard a écrit : Selon les traitements, il y a plus ou moins de commutations de transistors, de latence et de bruit de phase. 

La "charge" devrait être directement mesurable par la température de l'appareil ou du processeur. 
Tu crois que ça a été fait ? 

Ou anticipée par taille de paquets, éventuel checksum etc.

[Mousiki]

(10-20-2020, 09:15 AM)n.d.b a écrit : Un sujet pour savoir pourquoi les protocoles "sonnent" de manière différente.
Informaticiens demandés

Contexte
- par le passé en jouant sur le protocole AirTunes, j'étais arrivé à un niveau convaincant de stream en saturant le flux et jouant sur le buffer
- niveau battu par GoogleCast à l'arrivée des Chromecast
- niveau battu par UPnP diffusé par Audirvana
- niveau battu par SlimProto, LMS
Et Roon/Raat pas essayé

Donc il doit y avoir quelque part par construction du flux et du "dialogue" un truc qui fait que ça ne sonne pas pareil au final et ce sans upsampling, sans toucher à quoique ce soit.

Là on a SlimProto
https://wiki.slimdevices.com/index.php/S...P_protocol

A priori je ne vois pas ce qui peut changer. 
Ecoute, transfert, buffer, information retour du "où en est le lecteur" etc. Rien de vraiment différent de l'UPnP, si ? 

Y a-t-il quelque chose qui pourrait expliquer des changements ? 
- paquets ? 
- contrôle ? 
- tempo ? 

Qui a techniquement réellement comparé le fonctionnement de ces protocoles ?

Je ne suis pas technicien alors je vais peut être dire une ânerie mais si on compare Roon et UPNP, il semble que les différences de rendu ne soient pas les mêmes pour tous, car cela va de ténue à flagrante.

J'avance cette hypothèse :

- UPnP fonctionne sur une architecture de base mais chacun peut y apporter des services ou modifications, ce qui fait qu'entre chaque appareil l'implémentation peut changer et donc les différences de rendu UPnP entre deux appareils écoutés (en UPnP) devraient être différentes

- Roon si j'ai bien compris va fournir les API et de plus va fonctionner avec son transfert RAAT, donc quelque part toujours assurer le même rendu quelque soit l'appareil. (c'est en fait leur principe de base puisqu'ils valident soit le Roon ready soit le Roon tested)

On pourrait ajouter que le protocole UPnP n'est pas spécifique à l'audio donc sujet à questionnement sur sa stabilité "hifi" alors que Roon a été créé pour écouter la musique et rien d'autre.

[Nard]

Il est plus facile de mesurer la charge CPU ! Il existe aussi des logiciels d'analyse de code source à même d'évaluer leur efficacité, mais ce sont des outils de spécialistes.

Sans aller aussi loin, il est toujours intéressant de regarder les consommations de ressource de son Nas et de faire des comparaisons entre deux logiciels de lecture à périmètre identique. Celui qui consomme le moins a généralement le meilleur rendu

---

Cette explication rendrait d'ailleurs parfaitement compte du désavantage de Roon par rapport à UPnP, beaucoup moins gourmand

[n.d.b]

Pour airplay ou plutôt Airtunes, l'astuce était de profiter d'une porteuse plein débit (16/44) avec un buffer à l'émission. Le buffer à la réception est petit. Dès lors ouvert aux accidents. Pas de data integrity, pas de checksum, la porteuse émise faisait tout.

Dans le cas de protocoles normaux TCP (non tweakés), il y a data integrity
- le data émis correspond au data reçu
- si anomalie (checksum), alors demande du récepteur à l'émetteur d'envoyer un data corrigé
- la réponse de l'émetteur peut-être longue
- d'où l'intérêt d'un gros buffer en réception

On se rend compte à l'usage qu'il n'y a pas beaucoup de tempo entre le début de remplissage du buffer à la réception et l'émission de musique. Si correction de data il y a, elle porte sur ce qui est en buffer, mais c'est peut-être raté sur le départ. Là je comprends qu'il puisse y avoir un problème.

Mais si le data en buffer est bien corrigé au fur et à mesure. Alors ce qui est en buffer est "parfait" et tout repose sur le récepteur. Ce qui explique la différence de rendu entre les différents récepteurs ou players.

Y a-t-il des infos sur les checksum et correction de data de chaque protocole TCP évoqués ? (SlimProto, RAAT, UPnP...)
S'ils zappent le data recovery, on doit pouvoir le repérer quelque part non ?

---

En fait je sépare 3 choses :

- l'intégrité du data. Normalement un protocole TCP/IP le garantit, mais les tweaks possibles
- la transmission asynchrone. Là les horloges du récepteur font la différence. Dans le cas d'AirTunes il me semble qu'on forçait le flux, il était isochrone, ça dépendait donc de l'émission, mais je ne sais plus trop...
- la gestion de l'alimentation

Ces 3 éléments doivent faire la différences entre les players, fonction du protocole employé.

Et là en sortant les paramètres asynchrones (ils le sont tous je pense) et l'alimentation utilisée, on doit bien pouvoir isoler l'influence du protocole, en particulier sur l'intégrité du data en buffer final, non ?

[mélaudiophile]

(10-20-2020, 09:15 AM)n.d.b a écrit : Un sujet pour savoir pourquoi les protocoles "sonnent" de manière différente.
Informaticiens demandés

Bonne question. malheureusement je ne suis pas informaticien, par conséquent mon opinion n'est pas forcément valable. 

pour moi, il n'y a pas transport simple et direct des bits vers le DAC comme on verserait du vin dans un verre, il y a un traitement du signal et mise en forme, ce qui permet une EQ pour obtenir le son désiré.

Pour exemple de cette théorie il y a Roon. Vers le début du fil sur Roon, voici ce que j'écrivais: j'ai trouvé le son légèrement plus "plein" que J River sur certains morceaux avec un peu plus de grave, je soupçonne une EQ car j'ai en gros le même équilibre entre Foobar et J River. D'autre part le niveau est légèrement plus élevé, ce qui avantage lors des comparaisons.


Je n'étais pas le seul à avoir entendu une différence, mais ça s'est arrêté là, les amateurs de Roon sont très satisfaits, et pourtant j'ai lu qu'avec les versions le son changeait....
je suppose que chaque concepteur cherche à rester le plus linéaire possible et que Roon a voulu se démarquer, car sinon comment arriver à vendre cher quelque chose qui est gratuit chez les autres (foobar par exemple) ou pas cher (J River) si c'est exactement pareil (hormis le réflexe conditionné : cher =meilleur).

j'ai cité Roon car c'est avec lui que j'ai entendu une différence spontanément, sans la chercher, sur certains morceaux très bien dotés en graves le son est devenu un peu gênant avec mes enceintes qui n'en manquent pas (je suppose que sur des biblios ou des colonnes à petits boomers ça compense - et c'est fait pour ça?) et j'ai commencé à comparer, sinon jusque là dans mon esprit les seules choses qui pouvaient changer étaient l'ergonomie ou les possibilités.

[n.d.b]

Alors il y a un moyen très simple de découvrir s'il y a une EQ ou le moindre changement de bits : le MQA

Pour avoir fait tous les essais possibles, y compris Leedh Processing, dès le moindre changement de bits sur le data, le MQA ne peut plus être décodé en final par un DAC MQA.

C'est super intéressant ça, parce que n'importe quel logiciel tricheur pourrait appliquer une correction aux fichiers normaux et pas aux MQA et que l'utilisateur ne retrouvant pas "le son du logiciel" avec le MQA en déduire que le MQA est mauvais. Or on peut ne pas apprécier le MQA pour ce qu'il est (compression), mais pas pour la manière dont il sonne. Il sonne normal, quand je fais une comparaison entre un fichier high Res local et le même en MQA local, ce n'est pas sur le "caractère général" que se fait la différence. Ils sonnent de manière identique. Ca se joue sur des micro détails.

[Nard]

Quand nous streamons Qobuz ou Tidal, c'est en protocole RTCP sous TCP/IP. L'intégrité des données est donc garantie (ce n'est pas le cas quand on streame des web radios).

Il n'y a pas, que je sache, d'EQ sur les flux envoyés. Par contre, les interfaces des logiciels de lecture peuvent éventuellement faire un padding en 24 bit qui n'est pas nécessairement composé de zéros, ce qui peut avoir une incidence.

Toutefois, on est généralement bit perfect, sauf à faire volontairement de la convolution. Les différences de rendu, sur un même matériel, s'expliquent alors par les performances des logiciels