Recherche EtherRegen Uptone

[xlantchris]

Hello la team,

Si quelqu'un a un EtherRegen en rab, qu'il n'hésite pas.
Merci.
Belle soirée
Chris

[yy92]

Superbe switch avec une bonne alimentation c'est exceptionnel !

[Minh]

Une pierre indispensable de mon système. Bonne recherche.

[Nico-Macaron]

Une sacrée pierrade aussi 

[kondor001]

Vu que t'es mon voisin du ch'Nord je me permets de te donner deux liens qui te permettront de bien réfléchir avant l'achat et éventuellement faire des économies. On pourrait discuter aussi autour d'une bière bien sur...

Mesures EtherRegen par ASR

[mishelinka]

On est un certain nombre ici à ne pas prendre tout ce qu’écrit amirm d’ASR pour argent comptant. Il possède une vision (et une écoute) des choses très personnelles qu’il recouvre/habille toujours d’arguments techniques soi-disant indiscutables, comme c’est le cas ici par exemple avec cette conclusion: « Computer, networking and streaming architecture instructs us that an external switch cannot have any effects on an Audio DAC. » 
Je connais quelques personnes (ici et ailleurs) qui ne sont pas des « manches » en électronique/informatique et qui ne seraient pas forcément d’accord avec ça. Par ailleurs, j’ai eu de très nombreuses occasions depuis plus de dix ans d’écouter (seul et/ou à plusieurs) des appareils mesurés positivement ou négativement par ASR, et d’en tirer (à l’écoute) des conclusions allant totalement à l’inverse de celles du site. À prendre donc avec des pincettes ce qui vient de là-bas. La chose indiscutable qui y est écrite malgré tout (mais ça serait difficile de passer à côté) c’est que ce dispositif chauffe effectivement énormément… 

Quant à la vidéo, elle fait partie de la cohorte de toutes celles qu’on peut trouver sur le net et visant à nous prouver que nous autres « idiophiles » sommes vraiment des couillons prêts à gober n’importe quelle connerie (et à dépenser beaucoup d’argent) pour se persuader qu’on entend des trucs qui n’existent simplement pas. Circulez, y’a rien à voir, et surtout rien de nouveau sous le soleil, ça fait déjà de nombreuses années qu’on nous poste ces inepties sur les forums à intervalles réguliers. Merci de ne pas participer à ça en en rajoutant une couche… 

[kondor001]

Je ne lui dis ni d'acheter ni de ne pas acheter, j'ai juste essaye de contribuer à son information. C'est à lui de faire le tri...

Vu que tous les messages d'avant étaient plutôt encourageants vers l'achat c'est toujours bon à savoir qu'il existe aussi une partie de la population (minoritaire peut être...?!?) qui ne croit pas vraiment dans le "fruité du medium" de câbles ou dans les ampli "chauds" anciens ou "froids" modernes ni dans un switch audiophile.

Après, nous sommes d'accord,  toute information venant d'un forum ou de YouTube est à prendre avec des pincettes mais dans les deux sens: aussi bien pour les partisans de "tout à l'oreille" comme pour les partisans de "tout à la mesure".

Un juste milieu peut être...  (en récoltant beaucoup d'informations)

[mishelinka]

Pas de souci, je crois que j’avais bien saisi le sens (tout à fait honorable) de ta démarche concernant les mesures faites par ASR et visant à faire écho à un point de vue différent, mais pour ceux qui ne connaîtraient pas bien le site en question, il me semblait important de remettre les choses dans leur contexte, à savoir que ce qui est écrit là-bas ne fait pas l’unanimité… 
En revanche, pour la vidéo, pas d’excuses, comme dit précédemment, c’est une parmi des dizaines de vidéos pseudo  « objectivistes » qu’on voit refleurir régulièrement depuis que les forums existent. On a déjà longuement débattu de tout ça ici et il n’est pas/plus question que ce type de débat stérile redémarre. La prochaine fois, elle partira directement à la poubelle… 

Enfin, concernant les avis positifs donnés par des membres du forum, au moins, ils émanent de gens « identifiés » qui témoignent de leur expérience propre et en ça, ils sont pour moi plus crédibles que n’importe quel anonyme du net. C’est ça aussi l’avantage des forums…

[KIKIWILLYBEE]

Bonjour,

Svp ,
A propos du choix d’une technologie rsx , d’une implantation, d’un actif rsx. pour un équipement audio , et avant la recherche complexe des métriques au travers de WireShark sur un autre fil ; peut être pourrions nous nous interroger sur les aspects qui pourraient intervenir dans l’analyse des causes de détérioration de l’intégrité de notre flux réseau pour le streaming audio , et ainsi
Pourrions-nous résumer les ´bruits’ divers intervenant dans notre process de streaming audio : de qualité audiophile que les anglo-saxons acharnés du sujet à l’instar de AUDIOPHILSTYLE .us nomment SQ.
Et aussi pouvoir affirmer la non pertinence de certaines mesures…. ;-)

Cela ,
Afin de tenter une approche plus complexe , et plus près des réalités physiques ….
Et comprendre pourquoi les aspects qualitatifs exclus de fait un Wi-Fi. ( à l’exception du DRAFT. 7 , qui pour la qualité nécessaire pour les gamers , vidéastes … inclus une artillerie algorithmiques : quad band de multiplexages , intelligence dynamique de la gestion des liens . .. contraignant la latence , le délai , le ´Network Jitter’ ) et ainsi se rapprocher de la qualité de service nécessaire pour des applications dite ´TIME SENSITIVE’. Telles Audio Vidéo Bridge , AES67. (Dante. , RAVENNA. , LiveWire. …) , Aoip. , Voip. ….et bien sûr notre précieux .flux SQ. …..


En premier lieu :
nous pourrions citer les bruits relatifs au transport lui même : ceux donc associés au flux réseau 8o2.3
- Jitter : la fameuse et incontournable guigue ou : Variations dans le timing de la distribution des paquets audio. Ces fluctuations dans la synchronisation de l’horloge réseau dans un flux dit ISOCHRONE détériore l’intégrité des données, celle ci est évaluée globalement à l’aide de la statistique BER. Bit error ratio. Dans les environnements critiques celle ci doit tendre vers les 1o-12/1o-13 , soit un bit perdu tout les milliards ou dizaine de milliards de bits.
- Attachée aussi à la distribution des paquets et du flux la Latence : Retard dans le transfert des données audio. Si mal gérée, elle peut induire une perte de synchronisation (désynchronisation labiale / visuelle, effet d’écho). Évaluée en milli seconde, elle correspond à un double ping.
- De même pour le flux réseau on mesure le Packet loss. ou Paquets perdus , c’est une erreur de transmission : En cas de congestion réseau ou de mauvaise gestion des buffers, des fragments audio peuvent être perdus ou arriver hors séquence, générant des coupures ou des artefacts.
(Cf.MOS Mean. Opinion. Score. De l’Aoip./Voip. Déjà expliqué dans d’autres posts…svp.).


En second lieu :
les Bruits électromagnétiques et radioélectriques EMI HF , CEM. , ou encore RFI. ..
- EMI / RFI (interférences électromagnétiques et radiofréquences) : Les équipements audio connectés au réseau Ethernet peuvent être exposés aux interférences causées par des appareils électriques proches (wifi équipement domestique…) il faut éviter des câbles non blindés, et éloigner des réseaux sans fil voisins. Bien sûr émetteur massif multibandes d’émission HF. Et leurs interférences
- les bruits électriques touche surtout l’alimentation des équipements , nous relèverons les bruits sur le mode commun transmis par les masses et blindages , et le bruit différentiel relatif aux bruits du signal de la tension d’alimentation et la stabilité de celui,celle ci , ainsi après le PSRR. (Power Supply Réjection Ratio , exprimé en dB a une fréquence ou bande passante de référence ) ; on complètera la qualification de l’alimentation par le Ripple V.S-1 ou ondulation résiduelle. Bruits du mode différentiel…


Enfin ,
accessoirement les Bruits anthropiques ou inhérents à l’environnement..
• Composants de faible qualité : Les switchs réseau, routeurs et câbles Ethernet mal adaptés ou non blindés peuvent introduire des pertes, du jitter, ou des interférences.


Et svp …
Pour en revenir, sur Wireshark. et l’accès aux métriques rsx.8o2.3. ci dessous :

Latence. (TCP)
- Pour la latence, il faut capturer le trafic sur l’interface concernée et filtrer sur la session TCP cible (exemple: filtre « tcp » ou en précisant les IP).

- Wireshark indique le temps d’arrivée de chaque paquet dans la colonne « Time ». La latence RTT (Round Trip Time) s’obtient en soustrayant le timestamp du paquet de requête

(TCP SYN, HTTP GET, etc.)
à celui de la réponse
(TCP SYN/ACK, HTTP OK, etc.):
$$
\text{latence} = t_\text{réponse} - t_\text{requête}
$$

- pour un affichage synthétique :

Menu « Statistiques → Conversations → TCP », où le RTT est résumé pour chaque stream.

- Il est aussi possible de tracer les RTT. Roubd time trip sur la durée en allant dans menu « Statistiques → IO Graphs » et en ajoutant le champ TCP delta (intervalle inter-paquet).

Perte de paquets (Packet Loss)
- La perte s'identifie avec les filtres d’analyse « tcp.analysis.retransmission » (retransmission de segment) et « tcp.analysis.duplicate_ack » (duplicate ACK après segment manquant).

- Wireshark signale les paquets perdus par l’alerte: le
« [TCP previous segment not captured] » lorsque les numéros de séquence TCP sautent de façon inattendue.

- Pour voir les pertes, appliquez les filtres :
- `tcp.analysis.retransmission`

pour les paquets retransmis
- `tcp.analysis.ack_lost_segment` pour les ACKs associés à une perte.

Notre Jitter (Variation temporelle inter-paquet # delay. )

- Le jitter TCP n’est pas calculé nativement par Wireshark comme pour RTP, mais vous pouvez l’estimer . ; Exportez les timestamps des paquets TCP (colonne à ajouter : `tcp.options.timestamp.tsval`), puis calculez la variance des intervalles d’arrivée (delta entre chaque paquet) sur Excel ou un script dédié. (Ce dont je ne dispose pas , dsl ,) . Le jitter correspond à des fluctuations du délai inter-paquet, causés par problèmes de queue, congestion ou traitement. Cela en fonction de la qualité de l’infrastructure, des débits sollicités, de la puissance CPU. Des actifs …

- En option, vous svp , pouvez visualiser les deltas sur
Menu : « Statistiques → Graphiques IO » pour repérer les pics et la régularité des arrivées.

Sources svp :

To Find Network Latency in Wireshar | PDF - Scribd ;
https://www.scribd.com/document/78238660...n-Wireshar

Examining Packet Loss Using Wireshark ;
https://www.linkedin.com/pulse/examining...ejith-raju

Jitter values for TCP Streams in Wireshark? ;
https://stackoverflow.com/questions/9530...-wireshark

Troubleshooting Latency, Packet Loss, and Jitter Using ... : https://www.linkedin.com/pulse/troublesh...nune-nxaof

TCP Segment Loss in Wireshark: Expert Tips and Tricks - PacketSafari :
https://packetsafari.com/blog/2022/12/27...-wireshark

Detect TCP Delays with Wireshark .;
https://www.youtube.com/watch?v=e_iS4DfLCEM

Jitter value for an RTP stream ; https://www.reddit.com/r/wireshark/comme...tp_stream/
[8] 7.5. TCP Analysis https://www.wireshark.org/docs/wsug_html...lysis.html

Jitter calculation in Wireshark ;
https://stackoverflow.com/

…
Bien à vous,
Cordialement,
W ;-).

[Steph44200]

@LeFaucon : Ton message n’apportant rien à ce sujet, il est désapprouvé (modéré)

Extrait de la charte :

Interdictions :

Sont interdits :
- les propos interdits par la loi ou contraires à l’objet de ce forum(racisme, xénophobie, piratage, pédophilie, pornographie, sectes ou assimilés, envoi de courriers non sollicités [spam], non respect de la propriété intellectuelle, insultes, etc…). Ceci par le biais de messages ou d'images (avatars, signatures, etc).
- Les grossièretés en tous genres.
- tout écart de bonne conduite : nous acceptons que les membres ne soient pas d’accord, sous réserve que les échanges restent respectueux des idées, ressenties, et des personnes. Notamment, toute expression de mépris quel qu’il soit.
- toute critique gratuite, propos diffamatoires, ou portant atteinte à une personne physique ou morale. Une critique ou un litige exposé doit être fondé et argumenté avec des preuves.