Faut-il bichonner le serveur ? (et jusqu’à quel point ?)

[Vincent.]

Hello,
N’ayant pas d’USB dans mon système, je ne m'y suis pas intéressé jusque là et vos échanges m’y ont incité (on ne sait jamais...).
Comme je n’ai pas lu tout le fil, je ne vais peut-être rien vous apprendre. Mais perso, je me coucherai moins ignorant sur l'USB. Ça m’a rajeuni de presque 40 ans à l’époque où je jouais avec différents types de codages (NRZ, NRZI, Manchester…).
Dans le protocole USB, le flux numérique est codé en NRZI complété de 2 mécaniques pour le rendre plus robuste à la désynchronisation du récepteur : bit stuffing et séquences 'SYNC'.
En NRZI, le signal ne contient en effet pas l’horloge proprement dite, mais le codage permet au récepteur de rester synchronisé avec l’émetteur.
Partant de là, et sauf à dire que le simple ajout du mot de synchronisation dans le flux est suffisant au regard de la sensibilité des puces de conversion, on peut faire l’hypothèse que tout ce qui va perturber la chaîne et en particulier le récepteur (par rayonnement ou par conduction) aurait un impact sur le signal qui va être converti.
Et que la stabilité à court terme (bruit de phase) de l’horloge du récepteur est importante pour maintenir la bonne synchro avec l’émetteur (celle à long terme n'est pas utile ici).

Ressources :

• simplifiée et illustrée : http://arsene.perez-mas.pagesperso-orang...geNRZI.htm
  
• plus complètes : https://efreidoc.fr/L3/Communications%20...comnum.pdf et https://www.engineersgarage.com/signal-a...-part-5-6/
  

Extrait du deuxième document :

"Ce code a de nombreux avantages :  
- le signal de sortie n’est jamais nul (0 Volt), ce qui permet la détection de la présence ou non du signal
- il utilise un courant de transmission faible
- il diminue les changements d’états et par conséquent le taux d’erreurs.

Néanmoins, il n’élimine pas les longues suites de 0 ou de 1, gênant la synchronisation du signal. Pour ne plus qu’il y ait de déphasage entre l’horloge récupérée par le récepteur et l’horloge utilisée pour coder les informations, l’idée était de provoquer une transition pour chaque état (0 et 1), le code Manchester est né."

Edit : comparaison avec l'interface S/PDIF

Dans ma lancée, j'ai regardé d'un peu plus près le codage utilisé par le S/PDIF. C'est intéressant car il est codé en Manchester (ou biphase) qui lui, à la différence du NRZI utilisé par l'USB, incorpore l'horloge.
Ceci peut-il expliquer le surcroit de précautions à prendre  pour avoir une liaison USB qualitative ?

Voir le paragraphe 1.1 de ce document : https://www.st.com/content/ccc/resource/...431633.pdf

https://fr.wikipedia.org/wiki/Codage_Manchester

http://christianweissweb.fr/elecperso/So..._SPDIF.pdf

[Le dom]

@l’Arédien: je reviens sur ton premier post.
Quand tu parles de serveur à bichonner, il s’agit bel et bien d’un serveur au sens strict du terme? C’est à dire que tu comptes bien garder ton Metrum Ambre?
Je te demande cela car vu que c’est parti un peu dans tous les sens j’aimerai bien avoir la précision.

@ds21: normalement le streaming Qobuz est en UDP donc sans vérification d’erreurs.

[ThierryNK]

@ds21

Je peux te répondre partiellement...

Depuis Qobuz, c'est http qui est utilisé. Grâce à une manip assez simple mais que je ne dévoilerai pas ici, c'est un fichier Flac qui est transmis et que l'on peut télécharger.

En cas de différence à l'écoute entre Qobuz et piste locale (hors mastering différent), c'est du côté de la box et ses EMI transmises qu'il faut chercher, pas du côté de la piste.

Idem depuis UPNP.


Mais bon, une fois qu'on envoie un fichier Flac, Wave ou AIF, le lecteur de cette piste dans l'appareil audio planterait simplement en cas de fichier corrompu, et un seul bit erroné suffit.

Roon, NAA et LMS, je n'ai pas regardé et sniffer les paquets réseau, ce n'est pas une activité quotidienne. Mais si tu veux le faire, tu te trouves un logiciel gratuit pour sniffer le réseau, tu regardes ce qui circule entre les IP de l'ordinateur serveur et l'IP du lecteur ou drive réseau.

Amicalement

[Olivier]

De plus ce n'est pas parce qu'un protocole permet la ré émission de trame, qu'elle est utilisée... Mais sur nos petits réseau, c'est un faux débat.

[ThierryNK]

Post croisé avec celui de Le Dom....

UDP pour toi, quand Qobuz répond à une requête http avec transmission de fichier? Tu as vu cela comment?

Amicalement

---

Bon et puis après tout...

Installer Jriver

Lancer du streaming Qobuz

Regarder ce qui en train de jouer dans Jriver

Copier l'adresse http que l'on y trouve.

La coller dans un navigateur. Télécharger. Comparer.

---

Et merci à Vincent pour ces précisions!!

[Le dom]

Dans les rapport d’erreurs des lecteur tels que Audirvana:

rtsp-rtp-udp::audio/vnd.dlna.adts: DLNA.ORG_PN=HEAACv2_L2_320

Exemple:

https://community.audirvana.com/t/blocag...te/20397/2

Il me semble que Roon avec son protocole RAAT était passé au TCP mais ma mémoire me fait peut être défaut.

[Wildad]

Je me permets une incursion dans vos échanges pour dire que QOBUZ comme TIDAL encodent avec des protocoles qui leur sont propres les fichiers reçus des éditeurs. 


C’est peut-être un début de réponse.

[ThierryNK]

(02-22-2023, 05:59 PM)Wildad a écrit : Je me permets une incursion dans vos échanges pour dire que QOBUZ comme TIDAL encodent avec des protocoles qui leur sont propres les fichiers reçus des éditeurs. 


C’est peut-être un début de réponse.

Encodage, tu veux dire cryptage?

Non, pas Qobuz.

---

@le dom

Audivarna sait reconnaitre les appareils UPNP et communiquer avec eux. Mais le serveur n'est pas UPNP (j'ai une licence Audirvana).

Simplement parce que les control point UPNP ne voient pas le serveur Audirvana. Il faut utiliser l'application dédiée Audirvana. Il y sans doute une surcouche logicielle qui permet au serveur Audirvana de communiquer avec les appareils UPNP.

Serveur Audirvana - couche ad hoc UPNP - Renderer UPNP

Mais cette couche logicielle ne peut sans doute être vue que de l'application Audivarna.

Je pense que Damien n'a pas envie de s'emm.... à dépanner ses utilisateurs qui utiliseraient d'autres control points. C'est sage!!

Amicalement

[Pascal64]

(02-22-2023, 05:46 PM)Le dom a écrit : @l’Arédien: je reviens sur ton premier post.
Quand tu parles de serveur à bichonner, il s’agit bel et bien d’un serveur au sens strict du terme? C’est à dire que tu comptes bien garder ton Metrum Ambre?
Je te demande cela car vu que c’est parti un peu dans tous les sens .....

Salut Dom, 
En fait le sujet déterré par Steph était clos depuis longtemps.
A l'origine nous avions parié une bouteille de champ que l'effet d'une alim lineaire sur son mini PC serait audible (ou pas). 
A l'époque, les Roon's boys colportés par Volpone avaient inventé l'histoire du serveur distant bruité , ce qui était une franche rigolade 
Et comme la difference était sans appel, et bien j'ai bu une coupe à sa santé 
Donc oui il faut bichonner son serveur.

Le cas des Aurender ou autre Innuos utilisés en USB est différent car il n'y a pas de passage par le réseau / Switch & Cie

[pda0]

@wildad: merci du retour sur Grimm vs Aurender, mais à 13000€+ chacun de ces serveurs/streamers me parait cher…