02-04-2019, 01:34 AM
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]](https://tof.cx/images/2019/02/03/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 ...
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:
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 ...