Le Forum Indépendant de la Hifi et des Audiophiles

(07-19-2018, 06:56 AM)r11bordo a écrit : [ -> ]Ok pour tcpip, mais en audio, ce n'est pas l'udp qui est utilisé presque exclusivement ? 

Pourquoi en audio ce serait différent, en udp et non pas en tcp ? Tu as des infos là-dessus ?
Il y a un moyen de détecter si le transfert vers le streamer est en udp ou tcp ?
Cdt

*

(07-19-2018, 02:57 AM)Pascal64 a écrit : [ -> ]@ Volpone : je respecte tes positions mais le souci est qu'à force de marteler qu'il est strictement inutile d'optimiser le serveur, tu te mets à dos (façon de parler) tout ceux qui l'ont fait ou qui ont investi dans des serveurs de course.

Comment expliquer que deux logiciels sonnent différemment ?
Comment expliquer que certains entendent des différences avec les supports de stockages ?
Tu as lu comme moi que Seb et Guabasque préfèrent Audirvana upnp à Roon,
Que les Devialet boys trouvent que Roon Serveur sonne mieux avec une distribution Linux minimaliste sur leurs Macs, 
Que les amateurs de dual PC optimisent serveur et player ,
Que j'utilise une alim de course sur mon NAS
Que Totaldac, pink Faun, Roon (pour ne citer qu'eux) proposent des serveurs travaillés, 
Et pour autant que je sache, tous ne sont pas des buses dénuées d'oreilles.


Je fais partie de ceux qui portent ceinture et bretelles.
J'ai bien compris que la ceinture te suffit.
À chacun son truc, nous sommes sur un lieu d'échange, il faut accepter toutes les parties.
Pascal

@ loandsound : je suis bien d'accord, avant d'investir des K€ dans un streamer ou serveur, il faut se poser la question de savoir où ses deniers seront le mieux dépensés.
Mais puisque la question du topic est "streamer HDG", celà laisse supposer que le reste du matos est déjà HDG, qu'il y a un travail sur l'acoustique en passif ou actif etc

Pascal, est il possible dans tout cela de séparer ce qui est séparable, peut être, à savoir séparer les solutions où le dernier élément informatique est celui qui joue le role de source audio numerique débitant du flux audio vers un dac usb (et demande optimisation logicielle ET électrique certainement), et l’autre solution qui est que le dernier element informatique envoie du fichier sur une carte réseau selon les protocoles reseau (en demandant une optimisation liée à la pollution du réseau certainement, et pas qu’un simple filtre ou unique isolation galvanique qui ne bloque pas tout)

Désolé mais depuis toutes ces années, je crois bien que je n’ai jamais vu certains faire la différence, et c’est assez lourd pour pouvoir discuter puisque je pense sincèrement que ces deux solutions ne répondent pas aux mêmes problématiques même si elles partagent toutes deux un même type d’optimisation. C’est pas pour rien que j’ai vendu mon D1server et sa cubox en liaison usb et arrivée réseau: les deux besoins d’optimisation en meme temps (réseau, électrique sur la cubox, liaison usb en sortie de cubox) quand d’autres ne demandent que le soin du réseau (séparation électrique maximale et alim propre du dernier maillon réseau + dernier cable réseau  bien isolé / blindé) parce qu’elles ont déjà travaillé au mieux la partie audio de l’affaire en associant une passerelle réseau / audio à une solution audio numérique performante et alim performante. Après les protocoles de com spécifiques type roon ou air, qu’est ce que ça cache exactement comme différence de traitement?

Bref, si le dernier maillon maison est un lecteur audio débitant via un protocole audio vers un dac usb ou équivalent, oui tout doit être optimisé (et les modes bridge font cela en limitant au stricte rôle audio le dernier maillon et utilisant une liaison type réseau informatique pour sécuriser le transfert de fichier entre les deux, avec la pollution réseau éventuellement associée...). Si c’est un lecteur réseau où tout est déjà optimisé, il ne reste à prioiri qu’à soigner le réseau et rien ne dit que l’optimisation de l’amont qui s’entend ne soit rien de plus que la pollution generee sur le reseau qui s’entend.

Simple hypothèse de travail qui peut faire mal aux fesses de ceux qui ont mis des alim de course partout en ayant un lecteur réseau (pour limiter la pollution du réseau du coup peut être),  mais sont ils nombreux? Je pense qu’il y a plus de monde qui en effet, travaille ces optimisations parce que leur dernier maillon est un lecteur audio numérique maison débitant sur un dac usb, non? 

Et ça Volpone n’ira pas contre... donc peut être qu’au final tout le monde dit la même chose mais que tout le monde ne cible pas le souci au même endroit même si l’origine du souci est la même en fait, certain traitant à la source, d’autres à l’arrivée. Après qu’un traitement de fichier vers l’audio diffère à l’arrivée des cartes réseau de lecteurs réseau selon que le protocole de com soit roon ou upnp ou air de devialet.... des protocoles maison qui ont des latences différentes à l’arrivée, de la sollicitation logicielle et matérielle différente ou que sais je, mais à l’arrivée, c’est la faute de la partie conversion de fichier en audio numérique, pas faute à la transmission de fichier en amont, à priori comme ça vu de loin. 

Peut être que tout ceci est un tissu de conneries, c’est possible et c’est pas bien grave, en toute franchise j’en sais rien et je pense aussi que tous ceux qui optimisent à tout va les alim de leur réseau, ordi, bridge, n’en savent que dalle non plus, ils tatonnent comme les autres, sinon toutes ces conneries auraient déjà disparu au profit de lecteurs réseau recevant du fichier sans se faire influencer une seule seconde par ce qui se passe en amont. Ça peut faire mal à l’égo mais il faut l’admettre plutot que de penser qu’on influence les bits de fichiers qui traversent la planète sans perte jusqu’au dernier maillon recevant ce fichier informatique sous forme informatique

Mon humble avis, qui n’ira pas plus loin sur ce fil

Cordialement, Nico.

(07-19-2018, 09:02 AM)Nicoben a écrit : [ -> ]Bref, si le dernier maillon maison est un lecteur audio débitant via un protocole audio vers un dac usb ou équivalent, oui tout doit être optimisé (et les modes bridge font cela en limitant au stricte rôle audio le dernier maillon et utilisant une liaison type réseau informatique pour sécuriser le transfert de fichier entre les deux, avec la pollution réseau éventuellement associée...). Si c’est un lecteur réseau où tout est déjà optimisé, il ne reste à prioiri qu’à soigner le réseau et rien ne dit que l’optimisation de l’amont qui s’entend ne soit rien de plus que la pollution generee sur le reseau qui s’entend.

Pas bien compris
Dans les deux cas, tu as un serveur de fichiers distant qui envoie le fichier vers soit le lecteur audio maison soit le lecteur réseau du commerce. Tu sembles dire que dans le deuxième cas, l'optimisation du serveur ne soit pas nécessaire parce que le lecteur réseau est déjà optimisé, et qu'elle soit nécessaire dans le premier cas.  C'est là mon interrogation. Pourquoi, dans le premier cas, l'optimisation seule du lecteur audio maison n'est pas suffisante comparant au lecteur réseau ?

(07-19-2018, 02:57 AM)Pascal64 a écrit : [ -> ]@ Volpone : je respecte tes positions mais le souci est qu'à force de marteler qu'il est strictement inutile d'optimiser le serveur, tu te mets à dos (façon de parler) tout ceux qui l'ont fait ou qui ont investi dans des serveurs de course.

Comment expliquer que deux logiciels sonnent différemment ?
Comment expliquer que certains entendent des différences avec les supports de stockages ?
Tu as lu comme moi que Seb et Guabasque préfèrent Audirvana upnp à Roon,
Que les Devialet boys trouvent que Roon Serveur sonne mieux avec une distribution Linux minimaliste sur leurs Macs, 
Que les amateurs de dual PC optimisent serveur et player ,
Que j'utilise une alim de course sur mon NAS
Que Totaldac, pink Faun, Roon (pour ne citer qu'eux) proposent des serveurs travaillés, 
Et pour autant que je sache, tous ne sont pas des buses dénuées d'oreilles.


Je fais partie de ceux qui portent ceinture et bretelles.
J'ai bien compris que la ceinture te suffit.
À chacun son truc, nous sommes sur un lieu d'échange, il faut accepter toutes les parties.
Pascal

Bonjour Pascal,

Me sentant visé aussi par ta remarque, je tente d'y répondre...
J'ai un point de vue sur l'influence d'un streamer dans la chaîne. J'essaie de fournir des informations techniques qui expliquent pourquoi je pense ceci ou cela. Le but n'est pas vous convertir.

Je ne conteste pas les faits rapportés par les uns et les autres vis à vis des écoutes. D'ailleurs j'ai eu suffisamment de problèmes de pollution électrique et solutions testées pour être convaincu du problème.

Ce qui me gène plus c'est l'approche qui consiste à sortir des résultats sans essayer de séparer les variables. Je pense que dire j'ai changé de soft et c'est mieux ou moins bien sans autre détail sur la configuration n'apporte pas beaucoup d'infos pour avancer sur ce qu'il faut attendre d'un streamer HDG. Parce qu'on ne sait pas quoi influence quoi.
Dans tous les labo du monde, on ne change jamais un système complet pour évaluer des différences et pointer ce qui est bien ou pas bien dedans. Trop compliqué à interpréter...

Il se dégage de ce déjà long fil au moins quatre domaines qui peuvent expliquer en quoi un streamer change le son :

• le traitement numérique entre la source (le fichier) et la sortie du streamer (flux numérique) ;
  
• pollution électrique;
  
• problème de timing : jitter ou autre à la sortie du streamer
  
• autres effets généralement mal maîtrisés : CEM, effet passant par d'autre voies (MDI, ou autre effet non ou peu formalisé par la communauté audio).
  

Il me semble essentiel de séparer ces quatres domaines quand on caractérise un streamer alors que là vous rapporter des résultats en vrac et on ne peut pas discriminer.

Pour ne parler que du premier thème, il va de soit qu'entre diverses solutions et usages, on ne va pas du tout avoir le même résultat. Chacun sait-il au minimum ce qu'il en est  de son steamer sur ces points  ? Sur ce critère du traitement numérique on pourrait  répondre HDG =   "bit-perfect". Mais si je veux la convolution, du cross-over ou un simple volume, c'est plus possible et HDG aura une signification différente. Ce sera une solution non bit-perfect mais avec les meilleurs algos de traitements numériques...Finalement ce qu'on demande à un produit HDG c'est de réaliser les fonctions annoncées du mieux possible.
Sur ce critère, je suis d'accord avec vous qu'un DAC ne rattrapera aucun défaut.

Sur les autres critères je suis persuadé du contraire et on aura toujours le choix de miser sur le DAC ou sur le streamer  ou les deux pour le meilleur résultat.


Jacques.

Bonjour

@ Mr loandsound , Vous aurais-je manqué de respect pour que perso' vous m'affligiez de votre 'acrimonieuse ironie' ?...
un petit schemas peut être ?, pour la lecture ....
(c'est la 'modulation' du signal TTL électrique qui' 'exprime' les bits cf. précédent doc pdf I2S).




( en aparté pour vous Mr loandsound :'perso , avant de 'pisser' sur les copains, je prends toujours un temps, et je me reprends,
celà doit peut être s'appeller examen de conscience, Fairplay ou étiquette....,
tout ce qui permet de 'vivre ensemble', de façon courtoise et civilisée ...).
En aucune ,façon, je ne vous aurait refusé, courtoisement, de m'expliquer, détailler, documenter
(je le fait...) , nous sommes ici pour celà ?!, et n'oublions jamais que tous mérite respect..(n'est ce pas là le minimum ?!),,
et que même dissimulés par une fausse sagesse, les mauvais sentiments restent de mauvais sentiments ...')

Bien à vous,
courtoisement,
w :-)

(07-19-2018, 09:41 AM)bz31 a écrit : [ -> ]

(07-19-2018, 09:02 AM)Nicoben a écrit : [ -> ]Bref, si le dernier maillon maison est un lecteur audio débitant via un protocole audio vers un dac usb ou équivalent, oui tout doit être optimisé (et les modes bridge font cela en limitant au stricte rôle audio le dernier maillon et utilisant une liaison type réseau informatique pour sécuriser le transfert de fichier entre les deux, avec la pollution réseau éventuellement associée...). Si c’est un lecteur réseau où tout est déjà optimisé, il ne reste à prioiri qu’à soigner le réseau et rien ne dit que l’optimisation de l’amont qui s’entend ne soit rien de plus que la pollution generee sur le reseau qui s’entend.

Pas bien compris
Dans les deux cas, tu as un serveur de fichiers distant qui envoie le fichier vers soit le lecteur audio maison soit le lecteur réseau du commerce. Tu sembles dire que dans le deuxième cas, l'optimisation du serveur ne soit pas nécessaire parce que le lecteur réseau est déjà optimisé, et qu'elle soit nécessaire dans le premier cas.  C'est là mon interrogation. Pourquoi, dans le premier cas, l'optimisation seule du lecteur audio maison n'est pas suffisante comparant au lecteur réseau ?

Non ce n’est pas ce que j’ai voulu dire: je dis que dans les deux cas l’optimisation de la partie serveur est la même, et que potentiellement l’optimisation de cette partie serveur n’est peut être nécessaire qu’à cause des perturbations qu’elle engendre sur le réseau, et que donc elle est peut être remplaçable par une optimisation du réseau juste en amont du lecteur audio maison ou du lecteur réseau du marché. 

Je dis que dans les cas majoritairement décrits par Pascal, on parle en fait d’optimiser le lecteur audio (celui qui débite en usb ou spdif ou ce qu’on veut vers un dac), Et en amont c’est de l’optimisation réseau (et libre à chacun d’optimiser la partie réseau en travaillant directement sur tous les éléments en amont, nas, serveur d’un bridge, alims.... mais n’est ce pas alors évitable par une dépollution réseau efficace juste en amont du lecteur audio (et c’est sur cette efficacité qu’il peut y avoir débat alors). Dans le second cas, le lecteur audio est déjà optimisé, on ne travaille pas dessus.

Puisque totaldac est pris en exemple, si je ne dis pas de bêtise il s’affaire depuis longtemps à faire un nas dépollué bien alimenté, un routeur dépollué bien alimenté, un cable éthernet filtré blindé à mort, ça c’est sa partie serveur, c’est de l’optimisation réseau pour éviter le transfert de pollution au lecteur que ça plaise ou pas, c’est valable pour tout lecteur audio maison ou lecteur réseau du commerce. Et là on est dans l’informatique, on optimise pas le serveur pour avoir des bits plus velus, au mieux on se sert de ce serveur pour externaliser sur un matos informatique des fonctions qu’on ne veut pas effectuer sur le lecteur audio car ça limite la perf du lecteur audio (principe du bridge, dont le but est d’optimiser le lecteur audio en fait, pas le serveur!).
Ensuite il optimise une cubox qui est reliée en usb à un reclockeur, c’est le lecteur audio, MPD a sa préférence, réglage des timings, latences .... optimisation d’alim de la cubox, optimisation de la liaison usb en sortie avec un filtre usb maison, c’est une optimisation de lecteur audio... et malgré tout cela il suffit de remplacer le cable usb par un autre  pour changer la restitution, même avec le reclockeur sous fpga en aval, signe que l’optimisation du lecteur audio et la pollution qui se véhicule via la liaison usb n’est toujours pas anodine et maitrisée, usb classe 2 ou pas (ok à valider en avegle si tu veux la liaison usb qui fait son son ).

En clair, parler d’optimiser un serveur c’est:
- parler de dépolluer le réseau éthernet (et plusieurs moyens existent, complémentaires ou redondants et c’est un objet de débat / essais...: nas et autres élémenst du reseau sous alim linéaire, routeur dépollué, filtres, isolateurs, cables à blindages variables, différents.... )
- parler d’externaliser des fonctions informatiques sur le serveur dans le but d’améliorer la perf du lecteur audio (fonction bridge par exemple, mais aucun impact audio lié au serveur, c’est le lecteur audio qui bénéficie de ne plus effectuer certaines fonctions, c’est le lecteur audio qui est optimisé, allégé....)

Cordialement, Nico.

(07-19-2018, 08:49 AM)phile a écrit : [ -> ]

(07-19-2018, 06:56 AM)r11bordo a écrit : [ -> ]Ok pour tcpip, mais en audio, ce n'est pas l'udp qui est utilisé presque exclusivement ? 

Pourquoi en audio ce serait différent, en udp et non pas en tcp ? Tu as des infos là-dessus ?
Il y a un moyen de détecter si le transfert vers le streamer est en udp ou tcp ?
Cdt

Je n'ai pas vraiment de docs là dessus, à part Google who is my friend.
Je crois que les dispositifs fonctionnant en tcp pour de l'audio sont les drives Audio Over IP tels que Rednet & consorts. Même pas sûr, et n'étant pas encore en congés, point le temps de vérifier mes dires ... 

Merci Nicoben, cette fois j'ai bien compris ton discours.
Mais je n'insiste plus sur le thème "en avegle". Apparemment c'est déjà gravé dans la tête de certains ... 

Hello ! :-),

Youpee ! , Svp à votre Sagacité, (projet).....?
avec mise en oeuvre de 'RTP ' like Voip :
http://www.crazy-audio.com/projects/rasp...tribution/
tandis-que les radios (broadcast.) utilisent un 'codec' spécifique (like Voip).
https://www.digigram.com/audio-over-ip/
et :
https://thelinearsolution.com
...?
Merci,
bien à vous,
w :-)

J'entend bien messieurs vos développements sur les pollutions réseau et autres qui peuvent fausser les constatations.
Je constate qu'on a pas encore le c** sorti des ronces à propos de toutes ces histoires 

Mon installation est sans réseau donc isolée mais je ne ferais pas de commentaires ici car le cas a été largement traité sur les topics Macs.

Les dual Pc que je connais sont également isolés du réseau car bridgés 

D'ici quelques jours je rendrais visite à mon ami Guabasque pour voir ce que son Nucleus + carte streamer MSB a dans le ventre (son réseau est optimisé selon la technique Swensson avec LPs1 sur le switch)
il entend déjà des différences entre RAAT et UPNP ... BZ31, tu nous prêtes ton bandeau ? 

Et pis ...
Si on ne veut pas se casser les neurones, il reste la solution du tout en un comme Aurender & Co.
C'est cher (haut de gamme ?) et fonctionne direct out of the box.

@Jacques : non, je ne te visais pas   , même indirectement. 
Désolé si tu l'as pris en tant que tel.

@Paulw qui a reçu des noms d'oiseaux en MP... diantre !  les gars, la hi-fi n'est qu'un amusement, un loisir, une passion dévorante pour certains mais restons courtois dans nos querelles de clochers.