Note de ce sujet :
  • Moyenne : 3.15 (13 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
Classé Audio SIGMA 2200i
Merci Smile
Bon tu vois je rentre d’une journée de visite marathon chez deux audiophiles qui charient du lourd, et je remets en route le Classé sur les Marten dans le bureau, musique de chambre et difficile de critiquer le résultat quand on ne va pas trop chatouiller le bas avec des musiques « #grasses », et encore... vu l’usage de panneaux GIK derrière les enceinte le compromis passe bien. Et le cat5e au cul du Waversa qui donne une aération qui paie dans cette configuration.

Et quelques essais réseau en extérieur différents et intéressants du coup, qui montrent une fois n’est pas coutume que quand le système est aboutit, l’absence de blindage paye sur les cables réseau proche du streamer, le bout de cat5e peut être le plus naturel, aéré, face à des cables à pas de prix. Ça peut montrer aussi l’apport conséquent d’un bon switch audiophile, ce qui est entièrement compatible avec l’usage de cables simples. Cela peut aussi montrer l’apport d’un dispositif passif unique (pas moins cher par contre...) à savoir le principe d’Entreq, une marque qui propose des cablages non blindé de grande qualité sonore, avec un principe de drain vers une terre locale. En l’occurence l’usage d’un cable éthernet Entreq entre streamer et la prise murale du réseau, cable traversé par un drain de masse connecté à une terre « virtuelle » montre un naturel de restitution saisissant qui met un peu en avant les aspects artificiels des autres dispositifs que l’on peut mettre à la place.

Cordialement, Nico.
Du transistor, du tube, de l’hybride…. Des petites, des grosses…. Tout démat.

Ventes  à venir ou en cours (MP si intéressé pour en discuter): panneaux acoustiques GIK,  Modulation RCA 1877Phono Silverdart, Cables HP Coincident Statement bicablage 3m, Enceintes Scanspeak Maxima, Ayon Odin, Kinki EX-M7
Répondre
Bonsoir,

juste pour ma compréhension (en bossant professionnellement dans le traitement du signal), est ce qu'il serait dit qu'un signal binaire serait "meilleur" dans sa transposition audio suivant la qualité du câble Ethernet (cad sur un protocole purement data corrigé en CRC-32) qui alimente un DMR (le 2200i ici en l'occurence) ? (désolé si j'ai mal compris).

Pour en revenir côté Audio, l'aération musicale est très franche après 2 jours de lecture continue avec une progression sensible ... de fait on est sur un classe D pour avoir un tel comportement (absent des FDA purs précédemment testés).

Un vrai bonheur, du coup d'ici qql. semaines (après rodage complet) nous iront chatouiller 2 de mes meilleurs potes et leurs config, pour mettre le Classé face à un Krell DuoXD et des panneaux Magnepan 20.7, et surtout un ensemble Lavardin MAP+C62 sur des Utopia Scala v2 ... j'espère faire découvrir à ces deux (fous) toulousains aficionados de l'analogique tout l’intérêt de ces Classe D / FDA sur un flux numérique.

Cdlt.
Répondre
(02-03-2019, 11:33 PM)a_romeo_fr a écrit : Bonsoir,

juste pour ma compréhension (en bossant professionnellement dans le traitement du signal), est ce qu'il serait dit qu'un signal binaire serait "meilleur" dans sa transposition audio suivant la qualité du câble Ethernet (cad sur un protocole purement data corrigé en CRC-32) qui alimente un DMR (le 2200i ici en l'occurence) ? (désolé si j'ai mal compris).

Tu as bien compris ... En tant que pro du traitement du signal, une idée pour expliquer ce bazarre ?
Serveur & Réseau : QNAP HS-453DX avec LMS, Cat5 1attack, switch Aqvox SE, Hdplex 200
Electroniques & Enceintes : Nano Player V4, Farad Super 3, Job INT & Atohm GT2
Ficelles : Ocellia Référence Silver, Audioprana Ag, LH Audio, TWL 7+, BlackNoise
Répondre
Réseau
La couche réseau Ethernet implante la correction de transmission (mais pas de data) via des codes correcteurs d'erreur (un CRC-32 Ethernet), en UDP/IP ou TCP/IP ... en ce sens, les trames arrivent toujours correctes au final (elles peuvent être réémises en cas de perte ou d'erreur non corrigeable.). Ethernet garantit donc que le paquet/trame reçu est correct. Son contenu n'est pas vérifié (cad que s'il est mauvais à l'émission, il le sera à la réception ... pas plus/pas moins).

DLNA
Ici nous sommes dans un monde UpnP, cad que le protocole DLNA est encapsulé dans des trames Ethernet : la data des trames est elle même un protocole, avec sa propre gestion d'erreur.

Le déroulé d'un échange avec le Sigma est le suivant:

- il s'agit pour simplifier d'une requète (un message) XML envoyée par le DMC (Controler, l'appli Lumin, DS Audio etc.) qui va indiquer au DMR (le Classé, qui est un pur DMR, cad pas un DMP/Player autonome, il a besoin d'un DMC) d'appeler le DMS (Serveur DLNA, cad le NAS etc.)

- le DMR intègre (pour simplifier) un "mini-serveur" HTTP qui attend des commandes de contrôle distant

- Il renvoit au DMC un message XML en retour

Une requête de commande à un format un peu long mais intelligible (dans une certaine mesure):
eg. pour connaitre le statut du Sigma (s'il est en lecture, en pause etc.):

Requete= "urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID></u:GetTransportInfo></s:Body></s:Envelope>' http://sigma2200i:10184/MediaRenderer_AVTransport/control

Elle est envoyée depuis le DMC (l'appli Lumin etc.) mais on peut l'exécuter en fait depuis n'importe quelle machine Linux avec une commande curl:

curl -H "Content-Type: text/xml" -H 'SOAPACTION: urn:schemas-upnp-org:service:AVTransport:1#GetTransportInfo"' -XPOST -d '<s:Envelope xmlns: s="http://schemas.xmlsoap.org/soap/envelope" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding"><s:Body><u:GetTransportInfo xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><InstanceID>0</InstanceID></u:GetTransportInfo></s:Body></s:Envelope>' http://sigma2200i:10184/MediaRenderer_AVTransport/control

On obtient un message en retour "Pause_Playback" (en pause, en attente de lecture):
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><u:GetTransportInfoResponse xmlns:u="urn:schemas-upnp-org:service:AVTransport:1"><CurrentTransportState>PAUSED_PLAYBACK</CurrentTransportState><CurrentTransportStatus>OK</CurrentTransportStatus><CurrentSpeed>1</CurrentSpeed></u:GetTransportInfoResponse></s:Body></s:Envelope>

Tout ceci pour introduire le fait que le monde DLNA/UpnP est un monde "informatique" ... avec une application type UpnP Inspector on voit toutes les commandes/états du Sigma:

[Image: bc82ff76f94c15c60bf9c359fef847f1.jpg]

Lorsqu'on veut lire un morceaux de musique:

- DMC interroge le statut du DMR
- DMR retourne statut + Ok
- DMC envoi les paramètres du fichier à lire (nom, localisation=adresse HTTP sur le serveur DLNA, paramètre de lecture etc.)
- DMR recoit la commande, et génère un appel sur le DMS via un message XML etc.
- DMS retourne un statut de fichier trouvé/disponible etc.
- DMR retourne Ok au DMC si fichier trouvé et échange possible avec le DMS
- DMC envoi commande read
- DMR retourne Ok si commande initiée ...

Ensuite le Sigma est autonome une fois l'ordre de lecture lancé (on peut arrêter l'appli Lumin etc. le Sigma continue de lire ...)
- DMR va ensuite interroger le DMS en spécifiant le fichier, la position etc.
- DMS/DMR procédent à des échanges continus de message qui englobe la donnée utile ... cad le fichier audio "en petits bouts"

L'échange entre le DMS et le DMR se fait sur la base du protocole DLNA, qui encapsule les donnnées du fichier audio (WAV, MP3 etc.) dans des trames DLNA, elles-mêmes dans des trames Ethernet ... DLNA et Ethernet implantent donc une correction de flux à 2 niveaux ... 

Le protocole DLNA côté données utiles ne sait traiter qu'un nombre limité de type de fichier: Flac, Wav, MP3  ...

En simplifiant (car là aussi le protocole DLNA prévoit que le décodage peut être fait soit au niveau du DMS soit au niveau du DMR s'il ne sait pas faire ...) il faut bien considérer qu'entre le DMS(NAS) et le DMR(Sigma) ce n'est pas un flux "audio" PCM qui est échangé ... mais un flux binaire de données représentant le fichier audio par bout successifs (en simplifiant beaucoup ...). 

En ce sens, hormis des pertes de paquets qui demanderaient des réémissions plus  lente que la capacité des buffers (les chips Ethernet intègre bien sûr des buffers de 64 à 256 Ko en général sur du 100/1000) il n'y a pas de pb.

Problèmes sur la restitution du Classé en DLNA ?
Le Classé étant un DMR implantant la fonction de décodage de flux (qui d'ailleurs ne sait pas traiter le DSD) il n'y a pas de pb relatif à la perturbation du PCM au niveau de la couche de transport, car il n'y en a tout simplement pas à ce niveau (à l'inverse d'une entrée cinch numérique en provenance d'un lecteur externe).

Le flux numérique représentant le fichier streamé est corrigé de par les protocoles en jeu, à l'arrivée le flux streamé est décodé pour produire le PCM qui va alimenter le DSP puis la chaine D/A etc.

Donc dans le cas présent, sauf problèmes de configuration réseau induisant des latences (demandes de réémission de paquets Ethernet à une fréquence supérieure à la lecture de trames des buffers en réception), et par conséquent du "jitter" (mais ce n'est pas exactement celà), il ne peut y avoir de corrélation "réseau". 

Par contre: comme toute entrée, le port Ethernet est un vecteur de perturbations radio-électriques ... 

En cas de mauvais blindage ou mauvaise mise à la masse commune du chassis dans l'architecture du Classé, et si on utilise des câbles avec des prises blindés ou avec une masse dédiée sur un des fils (rappel Ethernet n'utilise de 4 fils sur les 8 d'une prise RJ45 ... certains appareils/switch mettent à la masse les 4 fils inutilisés ... ce qui est hors spécification), alors il peut y avoir des remontées de masses ... et des perturbations.

Mais on est à ce moment là dans une problématique commune de perturbations non pas de la chaîne numérique du Classé en amont du DSP mais des étages suivants PCM/I2S jusqu'à l'analogique en sortie ... De même s'il y a des fréquences qui remontent par des masses, et qui sont non filtrées en sortie, alors elles impacteront le signal sonore restitué sur les enceintes ...

Si donc problème il y a, il est à chercher peut être à ce niveau concernant les masses ... de fait (dans une problématique avec une solution uniquement DLNA) = on utilisera un câble réseau sans masse (ca ne veut pas dire sans blindage/feuillard !) cad connecteurs non blindés, on peut même câbler en sertissant les deux RJ45 avec seulement les 4 fils utiles (1-2 et 3-6) comme cela on est certains que rien ne remontera par là ...

Ensuite ce n'est qu'un problème habituel de gestion des perturbations classiques s'il y a (qui ne sont pas lié au réseau Ethernet ...) cad

- on ne raccorde pas le Classé à une masse commune à l'habilitation
- on filtre le secteur pour éviter des remontées essentiellement par le neutre (rappel, le neutre c'est la masse du transfo Enedis moyenne/basse tension au bout du réseau ...) = un filtre passif fera très bien l'affaire (pour ceux qui veulent vraiment s'isoler = un groupe tournant 240v/240v ... mais amène d'autres nuisances "sonores" pour le coup lol)

etc. etc. d'autres sont bien meilleurs que moi pour lister les solutions de filtrage classiques ...

Cdlt.

Ps: même si (très) long, j'ai volontairement simplifié, en particulier les notions fichiers, format, conteneur et codec ...
Répondre
Tout cela semble bien résumé (si on peut appeler ça un résumé Big Grin). Aucun lien avec le classé à proprement parler car les constats se font d’une source audio réseau à une autre (avec des sensibilités différentes je pense). C’est en effet le bruit qui semble mis en cause dans tous les cas, en particulier les courants de fuite des alim à découpage des éléments du réseau (et du secteur autour), avec des résultats à l’écoute qui donnent avantage à des solutions de type switch optimisé coté alim (batterie ou alim linéaire) mais aussi coté horloge comme si la gigue du circuit cadençant les données éthernet entrant dans le lecteur réseau avait un impact sur la gigue finale du signal audio retranscrit (ou ces efforts sur les circuits ont un impact sur le bruit).

Bref, si l’usage d’un cable à 4 fils seul réglait le souci entier, ce serait bien... à essayer...
Du transistor, du tube, de l’hybride…. Des petites, des grosses…. Tout démat.

Ventes  à venir ou en cours (MP si intéressé pour en discuter): panneaux acoustiques GIK,  Modulation RCA 1877Phono Silverdart, Cables HP Coincident Statement bicablage 3m, Enceintes Scanspeak Maxima, Ayon Odin, Kinki EX-M7
Répondre
C’est un essai qui ne doit pas coûter bien cher...
Ce que je remarque régulièrement avec les câbles RJ blindés est une atténuation des hautes fréquences. S’il s’agissait uniquement de la HF issue de la pollution électrique venant de certaines alimentations, cela ne ferait pas de mal. Mais ce que j’ai constaté chez moi est que cela coupe également la HF du signal.
Pas d’explication technique pour tenter d’expliquer ou justifier ce constat. Mais ce constat me semble être plutôt solide au vu des nombreux essais réalisés jusqu’à aujourd’hui.

Pour le système Entreq, c’est vrai que le résultat est impressionnant. Après, distinguer ce qui relève du seul câble Ethernet et ce qui relève du système complet (entre 30k et 40k de budget câbles) est compliqué à discerner. Le gain de ce système de câbles reliés à différents boîtiers de terre repose à mon avis sur l’isolation complète du système. Ôter ne serait-ce qu’un câble Ethernet Entreq pour le remplacer par un autre ne crée-t-il pas un biais qui va au delà de la simple substitution d’un câble Ethernet ?
Je n’ai pas la réponse mais j’ai bien peur que la note pour avoir juste l’effet escompté du câble RJ soit vraiment salée...
Mais ça marche admirablement bien, c’est clair !
Répondre
L'explication est certainement électrique. Parce que pour ce qui est des pertes de paquets réseau udp ou tcp, sur un réseau local filaire, c'est presque impossible.
Serveur & Réseau : QNAP HS-453DX avec LMS, Cat5 1attack, switch Aqvox SE, Hdplex 200
Electroniques & Enceintes : Nano Player V4, Farad Super 3, Job INT & Atohm GT2
Ficelles : Ocellia Référence Silver, Audioprana Ag, LH Audio, TWL 7+, BlackNoise
Répondre
(02-04-2019, 09:43 AM)r11bordo a écrit : L'explication est certainement électrique. Parce que pour ce qui est des pertes de paquets réseau udp ou tcp, sur un réseau local filaire, c'est presque impossible.
Pas impossible, mais fort improbable, surtout pour notre usage.
Répondre
Il n'y a pas d'horloge en Ethernet ... il s'agit d'un signal modulé à 100 ou 250 Mhz suivant le débit (10/100 ou 1000). C'est un signal CSMA/CD (Carrier Sense Multiple Access / Collision Detection ). 

C'est donc un signal d'intervalle fixe (on introduit des transitions au milieu de chaque intervalle i : un front montant quand la donnée ai vaut 0 et front descendant quand elle vaut 1). Les tensions sont de l'ordre de -2V à +2V à l'émission; compte tenu de l'atténuation, elle sont au minimum de -0,7V à +0,7V à la réception. La valeur du signal est égale à 0 Volts, ce qui permet de limiter les pertes dues à la résistance électrique du câble (la puissance dissipée par le câble est P=U²/R=0 Watts).

Ce signal est parfaitement filtré en émission/réception de sorte qu'il est exclus toute perturbation pouvant remonter par le signal Ethernet lui même ... 

Donc, au risque de le répéter: les seuls perturbations possibles seront celles provenant du blindage raccordé à un connecteur blindé qui générerait des perturbations sur la masse du boitier du Classé ... ces perturbations n'induiront aucune modification dans le flux audio numérique, uniquement des impacts sur la chaine analogique en sortie.

Mais ce n'est ni plus ni moins qu'un pb similaire à celui de n'importe quelle entrée, si un lecteur audio remontait sur la masse du cinch des perturbations ce serait identique ...

Vous noterez que le Classé est fourni avec un dongle Ethernet, ce qui laisse à penser que les entrées RJ45 libres sont bien à la masse ... d'où qu'un cable Ethernet "parfait" devrait être avec les 2 paires utiles raccordées de bout en bout, et les 2 autres paires rebouclées sur le Classé lui-même ... 

Mais là on va très très loin alors même que les perturbations remontent plus classiquement par le secteur etc.

Cdlt.
Répondre
Oui certes, mais lorsqu’on passe via un switch ou un hub, que se passe-t-il entre le signal entrant et sortant ?

Les switchs semblent avoir un impact sur la qualité du son sortant du DAC, et à iso qualité d’alimentation dudit switch. Alors l’horloge ne joue-t-elle pas un rôle quand même ?

Ces horloges n’equipent d’ailleurs pas que des répartiteurs dits audiophiles.
Répondre


Sujets apparemment similaires...
Sujet Auteur Réponses Affichages Dernier message
  DAC R-2R vs Sigma-Delta ? JJS 12 1,695 01-04-2024, 07:11 PM
Dernier message: JJS
  HOLO AUDIO MAY LEVEL 2 vs AUDIO-GD R-7HE MK3 joel.h 19 5,804 11-26-2023, 12:44 AM
Dernier message: mélaudiophile
  dac AUDIO-GD pour ampli AUDIO-GD ? régis 22 12,474 04-14-2021, 01:26 PM
Dernier message: jean-luc
  DAC R2R contre delta/sigma ... bretonfou 15 9,308 12-31-2020, 11:07 AM
Dernier message: marius30
  Extracteur Convertisseur HDMI vers HDMI Audio 1080P SPDIF Optique RCA L-R Audio Adapt chakiwi 7 16,995 12-03-2016, 01:34 AM
Dernier message: Charon

Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)