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

[pda0]

Oui, et il se trouve que j’ai ressorti la Chromecast la semaine dernière et finalement si ce n’était le problème de micro-coupures dès qu’on est au dessus de 44kHz, je pense que c’est un choix qui se défend mieux que bien.
J’ai essayé avec la borne wifi à côté de la Chromecast sans réussir à éliminer les coupures hélas…

[KIKIWILLYBEE]

Bonsoir les Gars ,
et Bon Week-End à tous,

Svp ,
je me permets cette intervention à Propos de 'DANTE' ... :
DANTE. et RAVENNA. sont effectivement des 'protocoles' de communication réseaux du monde pro , que l'on peut trouver à la fois dans les studio's broadcast , mais aussi dans les solutions de sonorisation , et sonorisation multi site : il est par exemple implémenter dans les solutions pro telles YAMAHA. de la console , jusqu'a la salle de concert , avec toutes les possibilités de communications des dépendances , pouvant entourer un tel environnement ...ou il serait plus questions de traiter six, douze , vingt quatre , Quarante huit , cent vingt huit voix stéréo .... qu'une seule voix stéréo... : avec les limites de bandes passantes ou débits induits ..
Ils s'appuient sur la norme 'AES67'. , qui répond aux problématiques spécifiques de l'Audio-Over_IP. (Aoip) , ou aussi de l'AVB. Audio Video Bridging , et s'approche de la problématique similaire de la Voip. , Voix et Téléphonie sur IP.
En effet l'expérience à démonter que la distribution de la voix sur réseau ethernet , d'autant plus nos précieuses oeuvres post punk' ou notre flux appelé 'SQ.'... , ne se faisait pas sans difficultés , et posait rapidement des difficultés d'intelligibilité , au fur et à mesure de la distribution ou de la complexité du réseau ethernet , qu'il soit local : LAN , ou Global WAN ...
(En rappel , SVP les gars , le réseau ethernet , s'appuie et défini par le modele OSI, voisinant ou co-defini par le modele TCP-IP, il est défini par la norme Source IEEE8o2.3 (abrégé 8o2.3) , et ses sous définitions... pour le Wi-Fi par exemple IEEE8o2.11 , etc et services IP ...)
Cette expérience a définie un critère d'évaluation qualitative de l'infrastructure réseau , s'appuyant sur l'intelligibilité de l'audiogramme transporté : le MOS. , qui est une recommandation défini par l'IUT. (International Telecommunications Union) organisme de standardisation de l'industrie telecom/reseau . Ce score allant de UN a CINQ , de mauvais, médiocre à excellent .
Celà à démontré , que le transport INTEGRE , d'un AUDIOGRAMME (ou Vidéo-gramme : bien que le cas soit different car dépendant de la couche IV ou applicative et du MPEG/DASH Dynamic Adaptative video Streaming over HTTP : algorithmes video spécifiques dans un navigateur HTML...), demande des précautions , et nécessites stratégies et compléments sur les couches II et III transport et protocoles .duréseaux TCP/IP. (ou 8o2.3)..
Les causes étudiées , en sont le 'Networ(ing) Jitter'. ou : gigue réseau . En effet notre flux SQ. sur 8o2.3. est un 'FLUX ISOCHRONE'. : un flux a récurrence temporelle stricte ; et qu'une 'guigue' importante influera négativement sur l'intelligibilité finale de notre audiogramme ou flux SQ. C'est pour celà que l'on trouve des solutions de Voip. , D'Aoip. , d'AVB. répondant aux besoins des infrastructure Réseaux dites 'TIME SENSITIVE' , auxquelles répondent les options commerciales professionnelles standardisées : RAVENNA. et DANTE...(LimeWire)
Ces standards commerciaux , s'appuient donc sur des extensions des couches II et III , à la fois standard de la Voip. ou des services protocoles de TCP/IP. telle la commune Qos (Qualité de Service), et propriétaires , intégrés conformément à l'infrastructure à ressources déportées TCP/IP. , sur les postes terminaux sous forme de licences software (Virtual Soundcard) ou de hardware spécifiques (CPLD. FPGA.) , en répondant aux besoins pro. : 128 Canaux stéréo 24/192.
En résumé Ce précédent NERWORK JITTER. (guigue réseaux) sera responsable d'une distribution hiératiques des paquets IP. , à un débit inconstant , irrégulier , causant différents types de dégradations, d'irrégularités de congestions du flux isochrone . Celles-ci , svp., nuisibles pour un flux 'SQ' , mais aussi (exemple) pour la voie au travers de la téléphonie sur réseaux : 'voie sous IP' : VoIP., mais aussi pour l'Audio, la Video broadcast , Gaming ou le Studio ... (Ce NETWORK JITTER. , apprécié avec un 'diagramme de l'oeil' sur un analyseur telecom tcp-ip) , ou 'vec des logiciels de monitoring reseaux tels Wireshark , SolarWinds , Cisco Management , PRTG...) .

Et donc : .Dans des conditions d’un traffic donné , la qualité du réseau 8o2.3 sera évaluée en :
-disponibilité,
-débit ,
-délais de transmission,
-Gigue ,
-taux de perte de paquet TCP. etc .....Pour le 8o2.3 (le réseau Ethernet) Avec :
-'Latence' ms-1, (méthodes TRACEROUTE. ou NIRSOFT.) : +/- un double ping , relatif a la distance et l'infrastructure (EXEMPLE : atténuation -dBM-1)-> pb Wi-fi )!
-'Delay' ms-1,
-'Over all packet latency' en %
alors il nous est possible,
SVP,
d’évaluer le 'Networking jitter'

et pour rappel… la norme de qualité , pour le 8o2.3 est :
de
.2o à 3o nano seconde 1o-9 S-1 pour le delay,
.>1% de 'paquet loss',
.et >+/-15o milli seconde 1o-3 S-1 pour le 'over all packet latency '.

(mais aussi d'autres indicateurs tels que le RTT. : Round trip time ,
et le CT. : Connexion time,
TTFB. : Time to first bit
...)

(Les définitions seraient :
- la latence : c’est le temps nécessaire pour un aller retour , entre le pintd’entree défini : Switch par exemple et Endpoint. Est aussi égal au ‘ping’ x 2 ou RTT. Paquet Internet Grouper , Round Time Trip ; même un débit élevé !!! ne garantit pas une faible latence , Lag et délai sont synonymes facteur 1\2 de la latence , exprimée en milli seconde
- TTTL Time to live. Durée de vie d’un paquet , nécessaire pour déterminer le nombre de noeuds , ou savoir si un paquet. tourne en Boucle ..
- Guigue : il s'agit de la variation du temps de latence. Au plus la gigue est proche de 0, au plus le temps de latence a la même valeur et est donc stable.: cf flux ISOCHRONE à récurrence temporelle stricte . Il est possible de distinguer Jitter instantané et Jitter constant ..et of course moyen…
- Perte de paquets Ceci est souvent défini comme un pourcentage de paquets qui sont perdus dans une fenêtre de temps donnée. La perte de paquets affecte directement la qualité audio - des petits paquets perdus individuels n'ayant presque aucun impact jusqu’ aux pertes d'éclatement consécutives qui provoquent une coupure audio complète.)

Dans le cadre du streaming audio de qualité ….
-nous est disponibles des outils de métrologie dédiés pour évaluer et qualifier la précision temporelle des réseaux : de la couche physique du modèle OSI , s’appuyant sur les Normes et standard de IEEE.8o2.3 ; à l’exemple soft de SolarWind ou WireShark … , ou autres consoles hard d’analyses de Trame Tcp/ip Tektro , Keysight…. au travers de Digital Interface ou a l’instar des Switch ´s de Phy., afin de passer de la couche physique à la couche logique) et produire un Diagramme de l’œil pour analyse de la précision temporelle des trames Tcp/ip et ainsi qualifier l’infrastructure ‘?
, en deçà d’une certaine qualité temporelle : Délais , Latence , Jitter moyen , jitter à courte terme , paquet loss , Over all paquet Latency…) , le message sera incompréhensible….

(nos expériences ont exposées que :
- Si on souhaite un flux audio de qualité : dit SQ. , il est nécessaire de déployer une stratégie de mise en œuvre Ad minima sur la couche physique : par exemple en soignant mode commun et différentiel de celle ci : mise à la terre , blindage , alimentations linéaires etc …)
et donc aussi et nos autres découvertes familières au travers de protocoles spécifiques : RAAT Roon lab , Diretta , et ce jour la présentation des nouvelles options pro. Ravenna/dante et aussi redites avec administration l2/l3 : Qualité de services, Qos , Qos diff , Spanning tree , Gestion des priorités udp : paquet, Tronc Ip etc …

Pour revenir sur La Qos. (Qualité de service) : implémentée dans 8o2.3, couches OSI 2 et 3 ( (L2./L3.) : au dessus de l'infrastructure , dans le protocole IP = 'service protocol'.).
Celà pour apporter une solution simple à cette dérive temporelle , et a été historiquement rendue nécessaire avec le déploiement d’infrastructure Voip.
Cette Qos , apporte une solution au enjeux de qualités réseaux et administre simplement (ressources limitées) : l’ordonnancement du traffic par une sensibilité au délai et latence : introduisant des priorités par gestion des en-têtes UDP. des paquets TCP. (TCP-IP.) ; et une mise en forme du traffic (traffic shaping) a l’aide d’algorithmes facteur du débit avec dilution de traffic ou gestion de jetons de priorité..ou aussi gestion de flux entre vlan par tris et consolidations des tables .
Ces actions simples contraignent ainsi délais , latence …
et introduisent un premier niveau simple qualité dans l’infrastructure ip et la transmission de paquets ….
et conformement , de nouveau , à l'architecture a ressources déportées TCP/IP , incluent dans les ressources des actifs de commutations SWITCHS/Routeurs

Ensemble nous avons appris que Le premier niveau d'optimisation se fera sur la couche matérielle : une infrastructure cuivre ou optique : pour la vitesse (plus la débit normalisé est élevé , plus la latence et le délai seront faibles , exclure donc les Wifi à forte latence..)
l'usage de la fibre optique isole le mode commun, et la transmission des interférences EMI/HF. et de leurs harmoniques par le blindage ;
Ces 'parasites' ou interférences sont causes de pertes d'informations etc ..
Autre optimisation du réseau possible en hardware ; que nous avons découvert avec un reclocking appuyé par des horloges OCXO.25Mhz internes ou externe (oscillateurs simple, double fours a bain d'huile thermostaté....) à très faible bruit de phase (précision temporelle à très court terme ) de la trame rsx. ip. Nous savons aussi que La puissance CPU. des actifs réseaux (fréquences , cpu, ram...) influence positivement , par sa capacité de traitements rapides delais et latence ...

Le dernier niveau d'optimisation, , pourrait être au travers de l'administration des couches L2/L2+/L3 avec choix , mise en services paramétrages des 'services protocoles' proposés par IEEE8o2.3 : les extensions 8o2.Ii Qos. et Qos .Différentielle , 8o2.IAS : Audio Video Bridge, RSTP, NAT. etc .....Jusqu'au niveau ultime : un tronc , chemin ip. défini à hautes priorité udp. : 'Trunck IP.'
Le CDN : content delivery networking , est aussi. Un outil puissant de gestion du trafic réseau, s’appuyant sur l’analyse dynamique du contenu du flux et des paquets
(Rappels et conclusions : Certains proposent des traitements (algorithmes , formats, buffers, 'Asynchronisation' ..) sur protocoles IP. optimisation rsx. (réseaux) spécifiques : AES67 pour les studios avec DANTE, RAVENNA (Limewire) , ou en domestiques exemples Roon labs et RAAT. , HQP. Signalyst. & NAA. ou encore DIRETTA ;...
Avec HQP et Roon , sur TCP-IP. . Vous utilisez des services protocoles propriétaires (NAA.+RAAT.) , traités par les ressources cpu. : des Host ou Core ...,
ou encore le choix d’infrastructures Optiques SFP/SFP+ )
......

svp :
à votre dispo.,
pour des détails , et questions .(ou décodage lol '! ;-) ) ...),
Bien Cordialement ,
W .;-).

https://kadiska.com/fr/quest-ce-que-la-l...a-reduire/
https://fr.wikipedia.org/wiki/Qualité_de_service
https://en.wikipedia.org/wiki/Audio_Video_Bridging
https://en.wikipedia.org/wiki/AES67
https://en.wikipedia.org/wiki/Mean_opinion_score
https://en.wikipedia.org/wiki/Comparison..._protocols
https://www.malekal.com/latence-reseau/

pour le Monitoring :
https://kadiska.com/fr/meilleurs-outils-...ce-reseau/
https://www.solarwinds.com
https://www.wireshark.org

https://fr.wikipedia.org/wiki/Time-Sensitive_Networking
https://fr.wikipedia.org/wiki/Modèle_OSI
https://en.wikipedia.org/wiki/Voice_over_IP

https://fr.wikipedia.org/wiki/Qualité_d%27expérience
https://www.youtube.com/watch?v=k0wLoHYC8IQ
https://en.wikipedia.org/wiki/Dynamic_Ad..._over_HTTP

https://www.thomann.de/fr/rme_digiface_dante.htm
https://www.levenly.com/fr/a/19054/xilic...o-qr1.html

[Papytechnofil]

Gloups! Non merci....

Je plaisante bien sûr! Merci beaucoup Kkwllb

[Lulu_Dovic]

Merci Kiki

[Fredouille40]

Salut mon Willy !

Merci pour avoir détaillé ce que peu d'entre nous auraient eu le courage de faire. je vais le chercher une boite de doliprane et, je reviens plus tard. Après avoir digéré, essayé d'assimiler toutes ces notions.

J'aime cette approche factuelle, il faut juste que je traduise.

A peluche.

Schussss

Fred

[Skyscratch]

La facilité avec laquelle @Kikiwillybee nous décrit les strates et niveaux d’optimisation informatique montre bien que tout est question de point de vue   … merci à lui encore une fois !
Je n’ai ni les moyens ni le temps de faire avancer la cuisine du Forum ( avec un F majuscule, loin de toute supériorité mais avec une entité propre qui vaut probablement plus par ses échanges que beaucoup de réseaux vides de sens  …). Malgré tout, je le parcours et lis depuis des mois maintenant et en arrive à l’étape d’un serveur dédié … ( après mon A26 dont je suis ravi chaque jours, Jplay IOS moins par son manque de stabilité).
Soyez rassurés ( ou pas ) ,à priori, pour qui sait lire avec un petit peu de recul, vous êtes TOUS plus ou moins alignés et finalement chacun expérimente juste avec son expérience perso, son bagage technique et surtout sa subjectivité   ! 
Si @Olivier peut s’essouffler avec le temps, il tente de garder la distance nécessaire à la vie démocratique du Forum et c’est à lui que nous devrions adresser nos encouragements…
Pour en revenir au sujet, ce soir je suis triste de voir @Pascal64 quitter le Colisée car il a partagé et ouvert des portes que d’autres n’ont juste que continué d’enfoncer   … ( Diretta, …) 
Cela étant dit … j’écoute le dernier Dominique Fils-Aimé en rêvant d’un serveur Fanless alimenté avcec une Reddo ou carrément une Sean Jacobs, d’une isolation par pont optique renforcé d’un switch avec port SFP … 
Tout ça avec une machine aussi discrète que possible, électriquement et de manière audible pour palier au bruit généré par mes 2 chérubins mangeurs de placages d’Heresys   ) …

[Olivier]

Il faut rendre la paternité de Diretta, plus à LeDom qu'à Pascal! Ceci étant dit, il a effectivement beaucoup partager sur beaucoup d'autres thèmes.

[Le dom]

@ KIKIWILLYBEE:

Bravo et merci pour cette belle synthèse.

---

Tout comme Skyscratch, je suis très peiné par le départ de Pascal64 de ce forum.

[renan]

Fred,
pour revenir sur Dante que j'utilise sur mon systeme tout les jours, il a un certain avantage comme le dit "clairement" kiki sur le controle du Jitter reseau (?).
Ces protocoles sur RJ45 developpé pour les pro comme AVB ont largement anticipé ce que faite Diretta. Soit réguler le flux avec des paquets plus petits et plus reguliers qui ne saturent pas le systeme.

Sur ce plan là , il y a certainement un intérêt à passer par ces protocoles comme Dante. Perso j'en suis très content et je trouve qu'il est maintenant plus facile d'optimiser le flux rj45 que le flux usb. J'ai beaucoup essaye en usb sans obtenir les meme resultats.

Par contre, Dante:
- c'est du 48 ou 96 KHz max et ça certains bloquent psychologiquement sur le fait de ne pas aller au Dsd. Mais c'est normal si tu as un DAC qui sonne mieux en upsamplant tout en Dsd. Donc chacun voit midi à sa porte
-Dante n'immunise pas le signal des merdes electriques car il utilise le meme reseau que le reste. Tu peux optimiser le QOS ou creer un sous reseau si tu reste sur le meme switch bruyant tu tranportes tes merdouilles avec Dante aussi.
J'en ai fait l'experience en intercalant un switch sfp/rj45 à pas cher mais sur alim linéaire. Ce switch va sur 2 interfaces dante un pour le grave et un l'aigu. L'aigu est direct sur un compression à 110dB de rendement donc tout s'entend. Et bien mon switch Vimin pas cher me met du souffle que je n'ai pas avec mon switch aqvox SE. Si je met aussi l'aqvox apres le vimin ca supprime le bruit aussi.
Donc entre parenthese le switch aqvox se son effet s'entend clairement. C'est sur que pour convaincre monsieur tatillon, il faudrait que j'intercale le Dlink non modifié à la place de l'aqvox pour voir s'il ne fait pas pareil. Mais bon je n'ai pas eu le temps et ma tendance Boudhiste me dit que la vie est courte et qu'il est inutile d'essayer de convaincre des gens qui n'en ont pas envie 

Bon donc Dante ya bon l'horloge et le cadencage mais ca à les meme pb de remontes emi rfi que le reseau classique.

---

Et pour Pascal, oui je trouve regrettable que la tension soit montée au point qu'il parte.
J'espere qu'une fois calmé il pensera à revenir.

[pda0]

J’espère aussi. C’est toujours dommage de voir quelqu’un partir pour des échanges anodins. C’est un forum et c’est normal que tout le monde ne soit pas du même avis.