Double carte réseau : transparence "absolue"

[lamouette]

"J'suis commme ndb, lu mais pas suivi car : "faire du neuf avec des vieux trucs déjà testés : pas possible !"
Ca me rapelle mon experience avec l'Amanero, tout le monde croyais l'avoir réellement testée, sauf que c'est plus compliqué que ça

[phile]

(09-27-2020, 02:25 PM)Nard a écrit : Un bridge, c'est pour créer un sous-réseau physique (même réseau logique). A cette fin, on peut utiliser un PC ou un Nas avec deux cartes Ethernet. Dans les préconisations du fil CA, le sous-réseau est dédié à la connexion streamer

Top ! Merci pour le rappel Nard.

J'avoue que je ne pige pas trop ton "sous-réseau".
J'ai fait un connexion / bridge au sens où il est décrit ici par ex : https://www.windowscentral.com/how-set-a...windows-10
De fait, je viens de controler les ip & masque de sous-réseau du NUC & du PC : chacun a son adresse ip (même réseau, celui du routeur), et le masque masque de sous-réseau (truc standart : 255.255.255.0). Donc... pas de "sous-réseau" dans ma config.
A noter qu'étant novice : pas d'ip fixe, je laisse faire le routeur (DHCP). 

@ lamouette :
ouai... c'est tjs comme ça : tu relèves le niveau => et hop : les spé sont largués et directement te prennent pour un zinzin 

[Nard]

C'est transparent au plan logique donc même adressage.
Par contre, cela crée un espace de collision distinct. Ce n'est plus guère utilisé en informatique puisque les switchs préviennent également des collisions, sauf si on veut inspecter ou trafiquer les trames avec le PC bridge.

En audio, on peut utiliser le bridge pour isoler un sous-réseau d'une autre façon qu'avec un switch, mais cela n'empêche pas de cumuler les deux afin d'accroître l'isolation, et on peut même encore ajouter des MI 1005 (ce que je fais à la maison)

[phile]

Hello Nard,
tu parles du Bridge dans le sens où tu l'entends ou bien tu parles de ma cofig ?

MI-1005 : j'ai testé sans => pas d'influence notable...

Bon, cf ci-joint schéma de la config utilisée
[/url][url=https://ibb.co/RhNVnyP]
j'espère que c'est plus clair... 

Remarques en vracs (et donc diff avec le "bridge d'il y a 3ans" donc je cerne un peu/mal les contours....) :
- on stream => donc flux audio UDP = flux 1-way
  déjà vu sur ici et là : chaque élements sur le trajet réseau influe sur le rendu. Moins on a de maillons mieux c'est.
  dans cette config : on flirte avec le niveau "1 seul élement" : le flux réseau des fichiers de musique se réduit à NUC vers lecteur via USB.
  Sur ce trajet-réseau unique des fichiers de musique :
  => on n'utilise pas le port RJ45 du NUC (vu comme bruité sur NAS etc...) ; bcp de config avec lecture réseau utilise le port RJ45 vers le lecteur (meme des serveur de courses : erreur ! faut passer via USB via adaptateur... Juste mon avis.
  => l'adaptateur USB-Et a montré son efficacité : bcp moins bruité via RJ45 (testé sur NAS perso, + moult autres personnes usant un NUC)
- pas de connection SATA entre disque de stockage et CM (SATA identifié comme assez bruité par je sais plus qui je ne sais plus où...). C'edt pq j'utilise HDD externe via USB (en sus c'est cheap)
- pendant lecture, UPNP interface sur le réseau ces 3 liaisons : A / B / C
  l'appli de controle intervient sur la liaison A/B
  les fichiers transistent sur C
  au milieu, Minim sur NUC fait le lien.
  => on ne mélange pas les choux et la carottes !   
C'est là qu'est la diff avec le Bridge d'il y a 3ans (enfin d'après ce que j'ai cru comprendre du Bridge "ancien"...) 

Si c'est pas clair, c'est normal. Pour moi aussi c'est pas clair le "pourquoi la musique est-elle si claire ?" 
Cdt

[bbill]

(09-27-2020, 04:31 PM)phile a écrit : Moins on a de maillons mieux c'est.
  dans cette config : on flirte avec le niveau "1 seul élement" : le flux réseau des fichiers de musique se réduit à NUC vers lecteur via USB.

cela existe déjà, c'est juste comme mettre "dans un boitier connecté" le serveur, le stockage et le lecteur réseau (la partie droite de ton dessin) mais ce genre d'assemblage n'a jamais fait de révolution... on en revient à la qualité des éléments assemblés dont ton adaptateur usb-e et son alim

[Nard]

Phile,

La particularité de ton bridge, c'est qu'une des deux interfaces Ethernet passe par un port USB. A cela près, c'est ce qu'on fait depuis des années.

Par ailleurs, il n'y a que les radios qui streament en UDP, pour des raisons de temps réel, sinon c'est TCP (il faudrait arrêter avec cette légende récurrente. Eh oui, il y a bien contrôle de trames).

Enfin, c'est dommage de gâcher l'isolation galvanique apporté par le FMC avec une masse commune due à l'unicité de l'alim routeur et Nuc, sauf si ce sont des rails indépendants avec des bobinages secondaires distincts

[lamouette]

et si le "à part celà " avait son importance?
Voilà que je me mets à défendre phile qui m'avait emmerdé à propos du fx802 ou qa100, je ne sais plus

[zaurux]

2 éléments à rajouter qui peuvent être utile... et merci pour ce post !
Il faudrait que j'ouvre un fil sur mon installation pour éviter le multipostage.. mais j'ai pas encore trouvé le temps.. 

J'ai bricolé un système qui fonctionne pour ma configuration Roon + HQP, en essayant de privilégier une interface pour Roon et une autre pour HQP.
Une carte principale en IPV4 (IPV6 non installé) et l'autre pour HQP (IPV4+6, l'ipv6 permettant de communiquer en UDP avec l'Allo USBridge).
Roon envoie à HQP comme si c'était un autre PC sans créer de bridge via widows (ouvert à toutes les applis).
D'ailleurs c'est souvent le cas car si on veut utiliser certains filtres en DSD, il faut une machine de guerre en core i9. 

Bref c'est pas mon cas.
Donc sur mon NUC, j'ai à la fois mixé la priorisation des cartes réseau :
https://www.tech2tech.fr/comment-changer...indows-10/




Et choisi la carte dédiée à Roon avec ForceBindIP dans le script de lancement d'AO3 "custom shell" (Audiophile Optimiser).
ForceBindIP permet de lier n'importe quelle application Windows à une interface ou une adresse IP spécifique.
D'ailleurs, je faisais pareil sans AO à partir d'un même fichier batch pour lancer mes applis. 

Code :

@echo off
REM Created by: Highend-AudioPC
REM https://www.highend-audiopc.com
Title "Launching custom shell..."
@echo off
echo Launching custom shell...
ping -n 3 127.0.0.1 -w 1000 >nul
start /HIGH "Fidelizer" "%Systemdrive%\Windows\fidelizercore.exe"

ping -n 3 127.0.0.1 -w 1000 >nul

start /HIGH "HQPlayer" "%Systemdrive%\Program Files\Signalyst\HQPlayer 4 Desktop\HQPlayer4Desktop.exe"

start /HIGH "RoonServer" "c:\ForceBindIP\ForceBindIP64.exe" 192.168.1.89 %userprofile%\AppData\Local\RoonServer\Application\RoonServer.exe
exit

[phile]

Merci Zaurux pour le topo sur ta config double-carte sur base Roon.

J'ai tenté de tester ta config avec priorité à tel carte sur l'autre... bug... j'y reviendrai un autre moment car avec carte réseau interne + adaptateur ca semble pas aussi simple... Et puis le Classé buggue aussi qd on touche au réseau sans l'avoir déconnecter du réseau au préalable... je verrai ca à un autre moment.
Finalement, je suis revenu sur ma config standard : double carte en pont, fait par Win10. Tout simple.

donc sur ce, ta copie d'écran m'a donné l'idée de voir ce qui se passe avec Minimserver.
Roon+HQP est différent de Minimserver ! 
Minim on ne peux pas lui dire :
- réception via cette carte
- envoi via cette carte
car il n'y a qu'un seul programme qui fait les 2 : javaw.exe (derrière lequel est Minim).
Il y a peut-être qqchose à faire sur la partie immergée de l'iceberg, mais là je ne sais pas faire, hors de ma portée actuellement)
 => cf ci-dessous

Néanmoins, avec un stockage des fichiers sur HDD via USB, cela revient quasi au-même j'ai l'impression, d'après les données du moniteurs de ressources, car :
- l'ip 0.33 est le lecteur : uniquement de l'envoi des fichiers de musique
- l'ip 0.16 est la tablette : envoi d'info qd j'interviens sur l'appli pour regarder un album pd une lecture en cours. Cet envoi d'info est ponctuel et lié à action sur l'appli. Sinon, une fois qu'on a lancé la lecture d'un album la qté d'info envoyée vers la tablette se résume = 0 (écran tablette en veille)

Bref, dans ma config, on peut voir 2 choses :
Point de vue global du traffic réseau :
- l'adaptateur qui ne sert qu'à envoyer la zik vers le lecteur (1)
- le port RJ45 servant à discuter avec le web (processes internes Win10) & ponctuellement via l'appli sur tablette
Point de vue traffic réseau limité à Minimserver (javaw.exe) :
- il ne fait qu'envoyer des données vers le lecteur (pd lecture), via adaptateur.
- il n'utilise le port RJ45 (commun à Win10 & co) que pour envoyer infos vers l'appli, et uniquement si on touche à l'appli.

C'est, je trouve, un comportement assez "sain" (si si, osons le mot   ), qui laisse à penser qu'il n'est pas étranger au très bon rendu. (ca c'est la "spécial dédicace" pour Pascal64 qui ne veut pas entendre parler de techno pure&dure sans savoir si ya effet sur le rendu   ).

Aparté / (1) : zéro feedback du lecteur ; est-ce là la preuve d'un transfert UDP, sans rétro-controle ?! controle de parité, soit, mais on verrait un pti chouilla d'info en retour non ? là c'est 0)

@ lamouette : ah... désolé si je t'avais emmerdé. Je n'ai plus souvenir... fx802 & QA100, ca remonte à si loin.. J'espère que j'avais eu tord  

@ bbill : pour revenir sur ton post et vs amélioration : l'adaptateur semble clé et faudrait le modifier... lui coller une horloge PinkFaun, sans aucun doute !   (dommmage que trop $$$, je laisserai ca à qqun d'autre)

[zaurux]

(09-27-2020, 05:01 PM)bbill a écrit : . on en revient à la qualité des éléments assemblés dont ton adaptateur usb-e et son alim

Je suis d'accord. A un moment, il faut savoir (aussi) réutiliser ce que l'on a en stock.
C'est pour ça que j'ai testé l'adaptateur USB avec en amont un iSilencer et un iDefender (coupure du 5v et connexion d'un 5v en provenance de ma shanti).
Comme ils disent chez iFi Audio (que j'avais contacté), ça reste de l'usb.
Donc l'usb fonctionne dans les meilleurs conditions et pour le fun, la même puce ethernet (ASIX) est utilisée dans l’adaptateur et l'Allo.

Je ne sais pas ce qu'en pense @Nard, mais j'ai désolidarisé l'usb du NUC, et de l'Allo également avec un filtre Med005 sur le RJ45.
Sauf que je viens de penser que la Shanti alimente l'USB et l'Allo et que l'ensemble partage la même masse (prise sur les 2 boitiers prévus pour).
Aucun souci de masse, à priori, mais du coup le filtre galva Med parait inutile.. et pourtant.