"Nettoyage/amélioration" Internet amont des lecteurs réseau

[jacko]

... il ne faudrait pas trop s'éloigner su sujet du thread ...

Je ne vois pas en quoi on s’éloigne du sujet du thread. Parce que, dès qu’on parle de possibles erreurs, on est en droit de se demander s’il n’existerait pas des technologies qui diminuerait le taux d’erreurs, et là, il y a de quoi discuter dans ce thread, il me semble.

Titre du thread "switch audiophile ?"

Tout ce qui attrait aux protocoles sont des généralités.

[jacko]

D'ailleurs

donc stop au HS retour sur le sujet (enfin pour autant qu'il y en ait encore un )

[ds21hcfr]

Bonjour,

Dans le lien : https://fr.m.wikipedia.org/wiki/Protocole_UPnP il est dit que c’est UDP/IP au lieu de TCP/IP qui est utilisé pour UPnP.

Or, il me semble qu’en UDP, il n’y a pas nécessairement systématiquement de renvoi de paquets erronées car dans certains cas les contrôles type "bit de parité" ne sont pas forcément activés. Ce qui fait que le flux transporté pourrait se trouver ne plus être bitperfect.

Cdlt.

Facultatif en IPv4, obligatoire en IPv6.

Comme je disais précédemment : Beaucoup de réseaux locaux sont encore en IPv4.

Et je rajouterais que beaucoup de streamers n’acceptent pas l’IPv6.

Mais pour revenir à ma remarque précédente (également) que vous semblez vouloir ne pas prendre en compte et éluder.

Dès qu’on parle de possibles erreurs (comme en UDP), on est en droit de se demander s’il n’existerait pas des technologies qui diminuerait le taux d’erreurs, et là, il y a de quoi discuter dans ce thread, il me semble.

Cdlt

[haskil]

Bonjour,

Dans le lien : https://fr.m.wikipedia.org/wiki/Protocole_UPnP il est dit que c’est UDP/IP au lieu de TCP/IP qui est utilisé pour UPnP.

Or, il me semble qu’en UDP, il n’y a pas nécessairement systématiquement de renvoi de paquets erronées car dans certains cas les contrôles type "bit de parité" ne sont pas forcément activés. Ce qui fait que le flux transporté pourrait se trouver ne plus être bitperfect.

Cdlt.

Ce qui est aisé à vérifier. Outre que certains DAC indiquent cela. Il est possible, mais il faut alors avoir un intégré HC, envoyer un flux DTS en ethernet filaire ou wifi et constater s'il sera décodé ou va crépiter (conseil : baisse le niveau de l'ampli, les tweeters n'aiment pas du tout)... le coeur du DTS ne supporte pas la moindre altération.

[ds21hcfr]

Bonjour,

Dans le lien : https://fr.m.wikipedia.org/wiki/Protocole_UPnP il est dit que c’est UDP/IP au lieu de TCP/IP qui est utilisé pour UPnP.

Or, il me semble qu’en UDP, il n’y a pas nécessairement systématiquement de renvoi de paquets erronées car dans certains cas les contrôles type "bit de parité" ne sont pas forcément activés. Ce qui fait que le flux transporté pourrait se trouver ne plus être bitperfect.

Cdlt.

Ce qui est aisé à vérifier. Outre que certains DAC indiquent cela. Il est possible, mais il faut alors avoir un intégré HC, envoyer un flux DTS en ethernet filaire ou wifi et constater s'il sera décodé ou va crépiter (conseil : baisse le niveau de l'ampli, les tweeters n'aiment pas du tout)... le coeur du DTS ne supporte pas la moindre altération.

Pourquoi cela crépiterait-il ? Si il y a un bit par-ci par-là qui est erroné, cela ne modifierait que quelques échantillons sur des dizaines (voir des centaines) de milliers par seconde, pas de quoi générer un crépitement, mais de la distorsion plus certainement.

Cdlt

[boXem | audio]

Comme je disais précédemment : Beaucoup de réseaux locaux sont encore en IPv4.

Et je rajouterais que beaucoup de streamers n’acceptent pas l’IPv6.

Mais pour revenir à ma remarque précédente (également) que vous semblez vouloir ne pas prendre en compte et éluder.

Dès qu’on parle de possibles erreurs (comme en UDP), on est en droit de se demander s’il n’existerait pas des technologies qui diminuerait le taux d’erreurs, et là, il y a de quoi discuter dans ce thread, il me semble.

Cdlt

On pourrait commencer par étudier avec des données tangibles la nécessité ou non de réduire le taux d'erreur sur un réseau domestique.
Si c'était le cas (j'en doute mais c'est un à priori),
* on pourrait se poser la question de trouver la cause de ces erreurs. Et je ne pense pas que les horloges ou les alims des switches seraient montrées du doigt.
* ou alors tout simplement se demander si les technos permettant de gérer ce genre de problème n'existent pas déjà sur des produits on ne peut plus standard.

[haskil]

Ce qui est aisé à vérifier. Outre que certains DAC indiquent cela. Il est possible, mais il faut alors avoir un intégré HC, envoyer un flux DTS en ethernet filaire ou wifi et constater s'il sera décodé ou va crépiter (conseil : baisse le niveau de l'ampli, les tweeters n'aiment pas du tout)... le coeur du DTS ne supporte pas la moindre altération.

Pourquoi cela crépiterait-il ? Si il y a un bit par-ci par-là qui est erroné, cela ne modifierait que quelques échantillons sur des dizaines (voir des centaines) de milliers par seconde, pas de quoi générer un crépitement, mais de la distorsion plus certainement.

Cdlt

SI bien sur, car le coeur du DTS des origines ne supporte même pas à la lecture avant son décodage que l'on touche le niveau sonore dans le lecteur informatique employé.. . La lecture doit être bit perfect sinon il se produit ce qui se produit quand on lit à travers un lecteur sur ses sorties analogiques stéréo et un ampli stéréo un des rares CD DTS publiés (Patricia Barber à Paris, par exemple ; ou des pistes sur certains disques tests de la NRDS ou de Prestige audio) : des crépitement haute fréquence Ce test d'un signal DTS est utilisé pour vérifier facilement ce point comme l'avait indiqué voici fort longtemps un spécialiste sur HCFR...

[ds21hcfr]

Sauf que tout votre argumentaire sur les switchs (audiophile ou non) est basé sur le fait qu’avec le protocole TCP/IP (au sens large) tout est bitperfect, ce qui n’est pas toujours le cas, donc il faut remettre tous les argumentaires à plat.

Cdlt.

[indien29]

Certains Hifihistes ont un don certain pour trouver des problèmes là ou il n'y en a pas, et ne pas s'occuper des sujets essentiels qui eux font l'écoute, ça me surprends toujours

Sans doute parceque c'est plus compliqué de s'occuper des vrais sujets et déjà, de les appréhender ?

[ds21hcfr]

Je n’ai pas de switch audiophile sur mon installation (et je ne suis pas prêt à investir la dedans).

C’est simplement une question d’honnêteté intellectuelle qui me fait réagir. Tout n’est pas aussi évident que HCFR voudrait nous le faire croire.

Cdlt.

[haskil]

Sauf que tout votre argumentaire sur les switchs (audiophile ou non) est basé sur le fait qu’avec le protocole TCP/IP (au sens large) tout est bitperfect, ce qui n’est pas toujours le cas, donc il faut remettre tous les argumentaires à plat.

Cdlt.

Je n'ai pas d'argumentaire particulier sur les switch, outre que le fait que je sais qu'ils fonctionnement parfaitement en faisant ce pour quoi ils sont faits et que je comprends pas sur quels éléments tangibles jouent une version "audiophile'.

Le DTS traverse un flux ethernet en restant intégre à sa sortie dès lors qu'il est lu en bit perfect par le logiciel de lecture.

Et c'est ainsi que :

Fichier DTS lu par Itunes sous MAC et envoyé en Airplay aérien comme filaire via switch - protocole ethernet maison Apple, comme RAAT est un protocole ethernet maison Roon -, ou en UPnP depuis Audirvana est décodé à la sortie... si tu baisses le volume dans Itunes, il ne l'est plus.. C'est pas ethernet qui merde alors, c'est le player qui casse le bit perfect dès que tu touches au niveau.

En revanche, le même fichier lu avec Itunes volume à fond dans Windows 7 ou Vista (à l'époque!) en Airplay : bit perfect conservé. Si envoyé depuis la prise HDMI de l'ordinateur : pas de décodage du DTS... car le signal envoyé sur les sorties HDMI passent pas les couches son de Windows (pas de Kernel ou Wasapi possible avec Itunes) alors que le son envoyé en réseau ethernet par Airplay outrepasse la couche son windows...

Toux ceux qui font du traitement logiciel - convolution par exemple, correction paramétrique - dans leur ordinateur Mac, PC ou Linux n'envoient pas un signal bit perfect dans le réseau... mais le réseau transmettra lui en bit perfect le signal qu'il a reçu en entrée à travers le switch.

C'est juste une histoire de vérification simple à la portée de tous.

[jacko]

Chez moi :
Jriver
Mise en cache de l'intégralité du morceau avant lecture
Tout problème quelque soit sa nature résolu

A part le gapless qui va alors dépendre de la taille du fichier et du temps nécessaire pour sa mise en cache.
Mais comme le gapless ne m'intéresse pas ...

[jacko]

AMHA, la vrai question est de savoir comme le steamer, renderer etc. va gérer le flux de données, plus que la problématique des éléments hardware qui composent le réseau.

[ds21hcfr]

AMHA, la vrai question est de savoir comme le steamer, renderer etc. va gérer le flux de données, plus que la problématique des éléments hardware qui composent le réseau.

Encore faut-il que le streamer, renderer, etc ait reçu des données correctes en UDP.

Cdlt.

[haskil]

Chez moi :
Jriver
Mise en cache de l'intégralité du morceau avant lecture
Tout problème quelque soit sa nature résolu

A part le gapless qui va alors dépendre de la taille du fichier et du temps nécessaire pour sa mise en cache.
Mais comme le gapless ne m'intéresse pas ...

Le gapless m'étant nécessaire obligatoirement pour l'écoute de musique, je n'ai pas mis en fonction la copie dans le cache. Et aussi parce que le boss de Jriver dit que cela ne joue pas sur la qualité sonore et qu'il a implanté cette fonction parce qu'on la lui demandait.

En tout cas, ça résout éventuellement des problèmes : mais si tu corriges paramétriquement par exemple : il met quoi en mémoire cache ? Le signal corrigé ?