Un drive réseau a-t-il un impact sur la musicalité ??

[duf666]

d'autant plus que quelqu'un il y a quelques jours, sur un autre forum, m'a balancé ce truc sur les CS, accompagné de quelques autres énormités, insultantes envers les gens qui changent les CS, qui mettent de l'argent dedans

 J’ai 2 réponses qui ont été censurées/effacées, il n’y fait pas bon de critiquer les cablosceptiques…

[JosephN]

ah j'ai pas vu
ou j'ai oublié

tout récemment ?

---

on doit pas parler du même forum

[Olivier]

Personnellement, je répondrai "Oui" et "Non" !
Non : car un Drive réseau n'apporte rien au son dans la mesure où il ne fait que "transmettre" un signal, sans le modifier.
Oui : parce que la conversion N/A est sensible au bruit électrique (et c'est d'ailleurs mesurable et ASR l'a d'ailleurs démontré), et comme le Drive est en amont. Si ce dernier n'est pas bien isolé, il transmet sa pollution au DAC. Si l'isolation galvanique de l'entrée du DAC est bien fichue, l'impact du Drive est beaucoup moins évidente (j'en fait actuellement l'expérience).
Finalement, je serai donc très prudent sur cette question, qui de mon point de vue, dépend beaucoup de l'environnement.

[bbill]

j'apprécie cette réponse oui & non.. car elle couvre deux aspects du problème
et finalement, ce n'est pas évident de ne dire que "non" à tout puisqu'il y a aussi du "oui"
surtout si c'est un conseil d'achat.. le drive devrait être au minimum cohérent avec le dac !?

[Mario]

moi j'ai voté "Aucune idée" car je n'ai pas essayé.
par contre, quand je vois les prix des streamers sans DAC et le nombre de personnes qui en achètent, je pense qu'il se peut qu'il y ait une différence... mais pas sûr.

[KIKIWILLYBEE]

Bonsoir les Gars '!,
& Bon Week-End à tous .....'! ...


SVP,
un Drive est-ce un 'Streamer' .. ?

- En fonction des sorties numériques , ou de l'entrée numérique du 'DAC' ou Convertisseur il est possible d'observer , déjà'! , des diversités dans les formats disponibles ou non, ou même de capacités techniques : exemple l'I2s. qui permet une isolation du signal de clocking ...

- Et rappelons , svp ,
La fonction d’un lecteur réseau serai de distribuer un flux informatique , et éventuellement d’opérer une conversion de protocole , et un déplacement de couches ‘OSÎ’ ; extractions des paquets Ip. …(-> vers EXEMPLE un signal numérique bas niveau inter-chip. tel I2s , isolant le clocking et son/ses éventuels post-traitement(s) (PLL., Fifo-reclock, algorithmes, FPGA., CPLD , Chips ,DIR...) ., ou autre SPDIF/AES/USB2.o.UAC. ...)
Peut être , svp, pourrions nous supposer qu'Un bon lecteur réseau s’efforcera d’opérer de façon optimal ces fonctions :
le respect de l’intégrité des paquets ip. , au delà de la robustesse 8o2.3 et le respects du flux isochrone , le flux informatique à récurrence temporelle stricte , idéalement à guigue nulle .
Fameuse cette guigue ou jitter est le delta de temps dans la distribution des échantillons numériques, caractériser par délay et latence , mesurer en temps . et ainsi dresser de façon optimale le Soft et hardware de conversion de protocole, et de mutation du support physique de ce précédent ..

(Pour nos équipements , ce que permets les technologies domestique est une précision temporellle à court terme , cf. Bruit de phase , et Allan Variance de l’orde du dixième de pico seconde 1o-12 ( x.E-13.) pour les équipements les mieux dotés. , en deçà pour des éléments + commun (1oo E-12 1ooo E_-1" pour du Crystek CCHD, NDK ...) (un équipement de labo hp keysight agilént aura une précision supérieure à 25 1o-15 S-1, 1o-16 sur l'ISS. , 1E-18 Dernier PRIX NOBEL de physique.).

-L’autre partie de la fonction serai la conversion de protocole , accompagnant souvent un changement de couche OSI (format physique) .
Cela serait un process informatique . A l’exemple de la conversion d’un flux réseaux 8o2.3 rj vers l’USB 2.o audio . Ce process consomme du temps CPU. et peu aussi altéré l’échantillon par perte d’information , mais en fonction de la performance de l’algorithme de conversion introduire ou non logiquement delay et latence corrélé au temps CPU. De plus ces protocoles ne sont pas dotés de correction d’erreurs . La perte de bit , serai definitive. ? ; (si ce process est dépendant d'un chip , il devait être dépendants de ses propres spec.s et performances : i n'y a pas de composants parfaits ?)
Il faut donc supposer un process durci , et rapide (capacité CPU. Dédiée ) pour préserver l'intégrité de l’échantillon et minimiser delay et latence, ou variation de la latence source de guigue , IDEM. : le flux audio_numerique resterai un 'Flux Isochrone' : TIME SENSITIVE...?
Cette guigue introduirai une imprécision temporelle dans le 'flux isochrone' ou sa constance , et cela devrai se traduire par une imprécision de l’image stéréo ,ou holographique et de la juste localisation des différents pupitres et instruments : effet brouillon

Pour introduire quelques Arguments probables pour le 'OUI' ...???!!!...
(cela ne serait donc pas d'une 'transparence' et d'une immunité absolues)

Puis;
Notre réseau semblerait donc avoir plusieurs maux aussi ?, introduisant, svp , le
: NETWORK(ING) JITTER .

Celà altèrerai l’intégrité des données et paquets tcp et adresses ip, et corromprai donc l’intégrité des fichiers ou flux transmis mais aussi de leurs références temporelles . (Il serai visualisable dynamiquement sur un analyseur de trame TCP/IP par le 'diagramme de l’œil', et caractériserai les différents niveaux de bruits, par sa latence , les délais et les pertes de paquets ou les variations de latence …. ?
(perte paquets, retard, latence). Un 'ping' A/R. vers la source... ou des outils d’administration tel Solarwind,PRTG Network Manager , Wireshark ,Cisco mngt ... permettrait ces évaluation et mesures . ?

Ces mesures seraient soit : 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 ).
une mesure de la bande passante égale a la définition de la capacité de saturation rsx. 'Paquet loss' ajouterai aussi une information de qualité...?

Avec 'Latence' ms-1, 'Delay' ms-1, 'Over all packet latency' en % il serait alors possible d'évaluer le 'Networking jitter' composé du 'Jitter constant': valeur consolidé moyenne de la variation de 'Delay' paquet à paquet , le 'Jitter dit transitoire' qui affecterai un seul paquet égale aussi à 'la variation de delay à court terme' aurai pour causse essentiellement la congestion du réseau…?

la norme de qualité , et devrai être pour les rsx 8o2.3 sont de 2o à 3o nano seconde 1o-9 S-1 pour le delay, 1% de 'paquet loss', et +/-15o milli seconde 1o-3 S-1 pour le 'over all packet latence'. ?

(Une Qos 8o2.Ii I3E accesible par administration simple des actifs permettait de maintenir ou améliorer les tolérances; de même par une gestion locale hardware du temps et un serveur de synchronisation NTP rtp dcsp TXCO ou OXCO et GPS maintenant les délais de trame tcp/ip dans les 2o nanoseconde;
aussi une Gestion des arborescences d’adressage et des priorités des entêtes UDP IP assignées de 56 à 58 pour les plus hautes, et Zero au minimum; comme aussi des actifs réseaux puissants LOW LATENCY ou spécifiques à l’exemple des switchs Gamers , ou Voip .; EXIT le wi-fi; le etc source de latence , et de variations de débits ; la fibre optique serait une option comme encore la définition d’un tronc d’adressage unique tcp_ip '( trunk ip ...?)


(peut être faut il rappeler, SVP :
qu' Il est communément admis , que les alimentations smps standards de nos équipements soient de qualité mauvaises à médiocres , et les paramètres de qualité électriques de ses alimentations sont du même acabit : courants de fuites , Ripple V/T-1 ou ondulation conséquences du hachage du courant , ou le taux d’ondulation expression harmonique du ripple ....
C’est pour cela que dans nos environnements Audi Numériques les alimentations linéaires s’imposent. A faible bruit elle proposerons un mode différentiel avec un ripple négligeable, couramment à l’aide de ldô’s LT 3o42 mieux 3o45) . Cela permet de proposer une tension de référence précise et régulière idoine pour le bon fonctionnement des puces CMos). La gestion du mode commun par transformateur s, filtrage LC….évite la transmission via les masses et courants de fuites des pollutions EMI/HF. qui se caractériseront plutôt par des erreurs de clocking ..)

concluons SVP,
ces alimentations: polluent réseaux électriques et informatiques, et notamment par une pollution EMI HF : 'Electromagnétiques à hautes fréquences, et ces 'parasites'... , résidus de hachage.., et leurs abondantes harmoniques. , produits par la redondance de ces alimentations , sont supposés être à l’origine d’une altération des données et références audio numériques .et en partie source du Network(intg) jitter...

Pour l’étude de cas , je reviens toujours en exemple sur les technologies dites
'Network time sensitive ', à l’exemple de la voie (humaine) où téléphonie sur réseau VOIP , ou pour les studios l’Aoip audio Over ip , et sa norme AES67.
L’Aes67 , contrôle de protocole Ip l’usage de l’audio broadcast s’effectue à l’aide de Fgpa et algorithmes sur cartes Propriétaires hardware ou avec une carte son logicielle ASIO tels / Livewire , les jetons Dante. , les licences Ravenna.
Cette techno. Permet de contenir la latence des infrastructures Ip. et d’y véhiculer des infos de clocking ….
Sans travail sur la couche protocole IP : spanning tree , trunk ip. , Qos., 8o3.II , NTP., AES67…il est possible de déployer at home des stratégies d’optimisation de l’infrastructure Ip. : qualité des câbles , chasse aux interférences EMi-HF . Fibre optique FO et cage SFP-gbic , courants de fuite , isolation, gestion des masses , et même un reclocking low phase noise OCXO. Permets de contenir la latence de la trame Ip.
Diretta , RAAT , HQP. Introduiraient aussi un contrôle du flux ip. ...

…pour re introduire le sujet svp ….


....
bla bla bla ...
Bien Cordialement ,
W ;-).

[Olivier]

Kiki GPT ! :-)

[fred03]

En fait KIKI n'existe pas, KIKi c'est lui...   SVP',,*¥∆✓

[Amoulsolo]

Hello, de mon côté, j’observe que la sortie USB de mon mac mini reliée à mon dac VS la sortie numérique de mon lecteur réseau reliée à mon dac ont un niveau de performances suffisamment proches pour qu'il n’y ait aucunes différences audibles entre ces deux solutions de lecture.


Le plus important étant le résultat en sortie de dac, force est de constater qu’il n’y a pas trop lieu de se compliquer l’existence côté « drive ».

[Olivier]

Ce qui est important, ce n'est pas la qualité de la sortie du drive, mais la qualité de l'entrée du dac ! Si ton dac a une entrée USB "pourave", tu ne supporterais pas le Mini en direct.