Installation de poprock

[alfc81]

Merci

[Cellindo]

En numérique quand le bas est flou cela peut être un signe de jitter induit. Mais dans le cas d’un switch IP cela n’a pas de sens technique car les data ne sont pas synchrones liées à une base de temps. Les données arrivent parfois dans l’ordre, parfois dans le désordre et sont ré-agencées proprement au niveau du récepteur.
Les phénomènes que l’on entend sont plutôt dus aux alims et les perturbations apportées par celles ci, ainsi que la terre.

Pas trop la peine de s’épuiser sur ce sujet. Il y en a tellement d’autres à traiter en priorité.

[alfachris]

 Flou avec le HNE ? c'est un peu excessif quand même.....je n'ai jamais trouvé flou chez Patrice....le HNE est doux, là ok...mais perso ca me va 

[KIKIWILLYBEE]

Bonsoir …

..’

Mais dans le cas d’un switch IP cela n’a pas de sens technique car les data ne sont pas synchrones liées à une base de temps
..
‘
A propos du flux IP., ,
svp , .
Pour les réseaux il est aussi agi De Flux de données qui nécessitent une récurrence temporelle stricte , à guigue nulle (idéale) et encore sont dits isochrones , équivalents du flux de données (audio numérique) en temps réels, ( on parle aussi de flux à débit constant , ou bande passante garantie)…

(La largeur de la bande passante doit garantir un espace suffisant entre les différents sous ensemble du spectre : bande passante audio : filtre passe bas , Fc…, multiples du nombre de bits de quantification , des canaux 2 et définissant les débits nécessaires….(auxquels s’ajoutent trames tcp. ou et entêtes udp. …)...)

qualifier un rsx 8o2.3 se fait à l'aide de mesures sur _simple point ou RTT. (single Endpoint) : Round Trip Term ,
ou en _double point : variation entre deux intervalles pour la transmission et réception paquets ,
ainsi qu'une mesure de la bande passante égale a la définition de la capacité de saturation rsx. 'Paquet loss' ajoutera une information de qualité...

Avec 'Latence' ms-1, 'Delay' ms-1, 'Over all packet latency' en % il est possible alors d'évaluer le 'Network (ing) jitter' composé du 'Jitter constant': valeur consolidé moyenne de la variation de 'Delay' paquet à paquet , le 'Jitter dit transitoire' qui affectera un seul paquet égale aussi à 'la variation de delay à court terme' ayant pour causse essentielle la congestion des paquets ... ,
de même une latence non constante, delta ou variation de sur la latence ,
svp , est un rappel…

en résumé le NetWork(ing) jitter , ou guigue , est la variation du délai de transfert de l’information, due essentiellement aux délais de transfert variable entre deux noeuds du réseau : soit le delta de temps au point de mesure entre deux paquets partis simultanément …

Un réseau qualifié , par exemple pour la Voip , voix sous ip (transfert d’un flux audio. Voix , Numerique tps réel) devra afficher des tolérances 8o2.3 à :
15o a 2oo ms-1 de délai
2o ms-1 de guigue
-1% de paquets perdus
(Rappels svp : Le ´Over All paquet Latency’ et la bande passante peuvent aussi qualifier les Rsx 8o2.3. )….
on parlera alors de Qualité de Service : Qos ( postérieurement implémenté à 8o2.3 , cf. 8o2.II..etc.et SLA : Network service Agrément…).
Le MOS. est aussi une schématisation standard de la qualité sonore du réseau dans le cas du transfert de la voix humaine : 'Mean Opinion Score' , de 1 a 5 , 1-mauvais illisible, 2-médiocre et dégradé, 3-passable , 4-bon enfin 5-excellent….
Un réseau classique Voip normé svp. :´G.711´ .pour pcm 64 kbits-1 sera qualifié à 4.2 avec un délai : o.125 ms-1 ….
codage adaptatif , compression algorithmique spécifique normée : h.323 , adpcm…assistent aussi l’intelligibilité / taille du message sonore.
On parle aussi de Time sensitive Network , ou au Audio Vidéo Bridge , nécessitant donc un ensemble de précautions et services (8o2.II ..) pour une simple intelligibilité de la voix , et des flux audio ou vidéos ou html-mpeg-dash
Les éléments à retenir sont pour le NetWorking Jitter
Paquet Loss
Latency
Et Délay
Les causes en sont généralement
Une déficience des infrastructures ,
Congestion du réseau ou bande passante insuffisante
mauvaise gestion des arborescences de routage
Les classiques pollutions EMI/HF (bruits électriques , ESR. , courants de fuites , masses ...)
Une non Implementation des prioritérisation des adressages ip des en-têtes udp

Un jitter buffer hardware ,ou en soft et services ip. Une Qos optimisant les arbres de routage , prioritairisant les entêtes udp , facilitant le trafic avec La fragmentation des paquets (LFI ) et une bande passante garantie réduisent la guigue réseau. Un tronc ip dédié. est aussi possible.
Ou
L’utilisation d’alimentation à faible bruit ou power Supply réjection ration élevé , est une norme pour le bon fonctionnement des actifs réseaux ou tout produits audio numérique.
Ou
l'isolation Galvanique,
Ou
Des Actifs puissant avec tps cpu faible ,
Ou
Vitesse réseaux élevée,
Ou
Le découplage des puces cmos pour un meilleur fonctionnement , et aussi autres options de tweak's , comme le super filtrage DC....
Ou
De même une extrême vigilance des schémas de masse est nécessaire pour éviter le voyage de EMI HF . Très nuisibles au clocking
Ou
L’usage d’oxco (ou reclocking PLL, FIFO RECLOCK...) de la trame IP. sur les cartes , actifs , réseaux , convertisseurs , permet aussi d’ajouter à la précision et constance du flux.
Et.
L’administration soft , le routage des actifs réseaux, Qos , Qosdiff.& extensions services 8o2.Ii, l’utilisation de Vlan , de trunck ip, l’administration L2/L3 .permettent aussi d’améliorer les constantes et valeurs du réseau et flux ip ….
Les outils tels Solar-Wînd. , Cisco Mngt., Wire-Shark.. ... permettent un monitoring soft ,
qui peut être en métrologie révélé par un 'diagramme de l’œil .' sur trame ip pour visualiser les constantes et niveaux de bruits ..

Etc …
Bla bla-bla-bla


Bien à vous,
Courtoisement,
W :-).

[Olivier]

Personnellement, je ne comprend pas pourquoi faire un pont avec un DAC qui n'est que deux modules SFP (ou SFP+) avec un morceau de cuivre au milieu ! Ce n'est pas un pont optique !
Il faut prendre un AOC, ou deux modules avec un bout de fibre.

[KIKIWILLYBEE]

Yes Sir ;-)'!

[poprock]

(01-12-2024, 11:03 PM)alfachris a écrit :  Flou avec le HNE ? c'est un peu excessif quand même.....je n'ai jamais trouvé flou chez Patrice....le HNE est doux, là ok...mais perso ca me va 

Ah, difficile de trouver les mots justes pour exprimer un ressenti.

Je vais essayer de préciser ma pensée :
Mon expérience de cascader en optique les 2 Meraki me rappelait le HNE avec son pont optique 
avec disons plutôt un grave un peu mou, dans le sens "pas si bien tenu" que lorsqu'on a introduit le câble DAC à la place du pont optique dans l'équation.
Le HNE avec le câble DAC a retrouvé un équilibre souverain. C'est mon opinion; d'autres qui n'ont peut être pas un système aussi révélateur que le mien dans le bas ne ressentiront pas les mêmes sensations

---

aujourd'hui, je conserve toujours les deux Meraki en cascade derrière ma FreeBox mais câblés en RJ45



j'utilise pour l'instant et pour faire mes essais une alim HDPLEX 500 très utile avec ses réglages variables de 3,5v à 15v
les Meraki acceptent entre 5v et 12v et le son s'adoucit vers 5v à 9v. Le mieux est pour moi la position 5v pour les deux

[Olivier]

Et si tu relies tes switchs en RJ45, as tu le même resultat ou est ce différent qu'avec le cable DAC ?

[poprock]

@olivier
j'ai bien sur mis le câble DAC dans l'équation Meraki en lieu et place du pont optique > Vite retiré, son dur

[Nouk33]

(01-13-2024, 10:42 AM)poprock a écrit : j'utilise pour l'instant et pour faire mes essais une alim HDPLEX 500 très utile avec ses réglages de 3,5v à 15v
les Meraki acceptent entre 5v et 12v et le son s'adoucit vers 5v à 9v. Le mieux est pour moi la position 5v pour les deux

Salut Poprock, 

J'ai perso aussi deux Meraki tweakés ( un côté box et l'autre côté système ) mais relié en fibre Sfp de 20m et les deux montés sur des Hdplex 200w et comme toi le meilleur résultat est obtenu en les alimentant en 5V