Alims linéaires NAS, switch, box...

[bbill]

(12-18-2017, 02:28 PM)JBert a écrit :

(12-18-2017, 01:56 PM)bbill a écrit :

(12-18-2017, 10:56 AM)JBert a écrit : il faut se poser la question du fonctionnement d'un réseau. La perte de qualité en passant par un routeur n'est pas due à des problèmes d'alimentation mais à des problèmes IP. IP n'est pas fait pour du temps réel, il y a des phénomènes de jitter, surtout en UDP.

il n'y a pas de problème de temps réel pour un lecteur réseau qui a un buffer.. le réseau n'est la que pour transférer des fichiers qui sont par definition exacts et "reçus" avant d'être utilisés

Euh... Si. Ce n'est pas que je veuille absolument vous contredire...

Il faut que le buffer de réception ne se vide pas entièrement. La plupart des buffers des équipements de réception sont notoirement insuffisants (quelques Ko) parce qu'ils coûtent cher en silicium et en gestion par les programmes. Lorsqu'il n'y a qu'un seul émetteur et un seul récepteur sur le réseau, ça passe. Lorsqu'il y a du trafic annexe, ça casse.

Je viens de vérifier sur un appareil qui a le bon goût d'avoir une console série. La taille par défaut du buffer RX est de 4k. Le programmeur est gentil, il a collé en dur une taille de 88Ko (je pense que c'est le maximum avant que ça déborde de a mémoire parce que c'est plutôt étrange comme valeur). Avec un flux correspondant à une qualité CD, ça fait 0,5s d'écoute dans le buffer de réception. Pas lourd en cas de congestion ou de routeur un peu léger.

je ne sais pas de quel lecteur réseau tu parles ??? tu parles bien de lecteurs réseau pour de la hifi ??

je n'ai jamais eu ce problème avec tous les lecteurs réseau hifi qui sont passés par chez moi... jamais

ps : de plus, parler de "temps réel", comme tu le fais, pour un réseau Ethernet n'a pas de sens...

[Pascal64]

(12-18-2017, 10:44 AM)Vincent. a écrit :

(12-16-2017, 05:14 PM)pda0 a écrit : Je viens d'en acheter une pour ma livebox, histoire de remplacer l'alimentation d'origine, mais sans grande conviction sur l'apport sonore de la chose, mais juste pour éliminer une alimentation à découpage du réseau.

Une piste intéressante.
Reste la question dans une config avec un isolateur Ethernet : l'alim linéaire est-elle encore nécessaire sur la box et/ou le switch ?

---

(12-17-2017, 10:09 AM)Pascal64 a écrit : ...
Pour le serveur, player ou le NAS, pour moi c'est une évidence : là il faut mettre le paquet.
Les alims de type Zerozone, bof. 
J'avais essayé sur mon NAS et le Mac mini...on est à des kilomètres de ce que peut donner une bonne alim - qui coute un bras. 
Exemples  : Uptone audio JS2 (Pda0), Clone Audio (chez moi), Mojo audio (Franz) ou Kenneth Lau (chez un forumeur) et Rose Audio (Demetrios)
...

Merci Pascal pour ces nouvelles références. Des boitiers joliment finis, mais très chers. Enfin je ne mettrais pas ce montant dans des alims linéaires qui dans leur conception interne sont assez "minimalistes".
J'ai envoyé un message à Rose Audio pour une alim double sortie, à suivre...

Aredien m'avait prêté son Étalon isolator, j'avais pu faire quelques essais :
A choisir entre un isolator ou une alim lineaire sur le routeur ... je prendrais les deux 
Mais l'étalon isolator doit faire 95% du boulot.

J'avais également testé l'isolator entre mon MAc et le Nas en liaison directe et c'était mieux sans.

@ Jbert : mes essais te font sourire, grand bien te fasse 

Il n'empêche que sur un Mac mini, l'alimentation est primordiale.
Comme sur un ampli d'ailleurs .... 

Et un SSD, ça claque ? Ben oui, comme mes artères, ça arrive un jour.
L'avantage de l'informatique est qu'on peut la sauvegarder, pour mes artères, c'est trop tard 

[0000]

(12-18-2017, 10:56 AM)JBert a écrit : Le RPi est incapable de gérer le réseau sans jitter important (parce que le truc est partagé avec l'USB et la flash) et que sa mémoire tampon interne est ridicule. Vous courez déjà à handicap.


Personnellement, j'investirais plutôt dans un switch manageable de niveau 3 (et un beaglebone à la place du RPi puisqu'il a une vraie mémoire eMMC et une vraie interface ethernet). Mais vous faites ce que vous voulez.

Intéressants ces points. Tu peux développer ?

- Pour le premier point, RPi3 + DigiOne ne sort pas l'audio par USB. Ce dernier n'est pas utilisé.

- Spéc comparaison :

Citation :Built specifically for the new Pi 3, the Broadcom BCM2837 system-on-chip (SoC) includes four high-performance ARM Cortex-A53 processing cores running at 1.2GHz with 32kB Level 1 and 512kB Level 2 cache memory, a VideoCore IV graphics processor, and is linked to a 1GB LPDDR2 memory module on the rear of the board.

Source : https://www.raspberrypi.org/magpi/raspbe...enchmarks/

Citation :BeagleBone Black: AM335x 1GHz ARM Cortex-A8
32 KiB L1 D/I cache, 256 KiB L2 cache, 512 MiB DDR3 RAM

Source : https://panthema.net/2013/pmbw/Beaglebon...35x-512MB/

- eMMC vs microSD : il me semble le support n'a aucune influence. Une fois démarré, il n'y a plus d'accès au microSD, tout le besoin pour l'audio est chargé en RAM.

[KIKIWILLYBEE]

Bonjour !

A priori l'avantage de l'Emmc, est bien sur sa rapidité,
mais aussi sa stabilité, pour celà il est ôssi possible
d'opter pour une cléf,usb, ou un DD.
Le SBC Allo SPARKY, comme l'Odroid C2 ...
disposent d'un port eMMC. Encore est il possible de trouver
des devices HAT Audio compatibles avec le Sparky, plus difficile pour
l'Odroid , encore plus impossible su un Beaglebone.
Pour le reste ne pas oublier que les OS Linux,
et les softs RPI sont optimisés flux audio (ARCHPILE),
(ces offres sont pléthore, dynamiques et soutenus, même user-friendly sur RPI : ubuntu, mpd ...
De même pour l'offre GPIO_AUDIO, soit particulièrement l'offre ALLO :
interface WM88o4, horloges NDK, regulateurs LT et celà à vif prix !.....)
Bien à vous,
cdlt,
w :-)

[Jacques92]

(12-18-2017, 10:56 AM)JBert a écrit : avant d'investir dans des alimentations linéaires (et pouvoir se chauffer avec elles, c'est la saison), il faut se poser la question du fonctionnement d'un réseau. La perte de qualité en passant par un routeur n'est pas due à des problèmes d'alimentation mais à des problèmes IP. IP n'est pas fait pour du temps réel, il y a des phénomènes de jitter, surtout en UDP. Sur la VoIP, c'est une plaie à corriger et on n'y arrive pas toujours. Sur les réseaux domestiques, c'est pareil. Si on veut que ça fonctionne raisonnablement bien, il faut non seulement activer de la QoS, mais qu'elle soit prise en compte à tous les niveaux (y compris au niveau des routeurs, ce que ne font pas les switches intégrés des routeurs de madame Michu).

De mon côté, ayant un bon petit réseau avec des NAS et routeurs un peu partout dans la maison, j'ai fait pas mal de test.
Oui le jitter sur réseau Ethernet est important. Toutefois, là, on est encore dans le transfert asynchrone informatique de fichier (même s'il contient un audiogramme), Le jitter (au sens littéral) ne pose absolument aucun problème. Ce qui compte c'est que le fichier soit transféré plus vite que le DAC le consomme. La mémoire tampon (correctement paramétrée) annule complètement de jitter. En cas de problème on n'a aucunement affaire à des problèmes de distorsion mais tout simplement à des blancs dans la reproduction de la musique. C'est donc très facile de tester.
J'ai réussi à reproduire ces blancs en saturant le réseau avec de l'injection de données à haut-débit en broadcast. Et il a fallu mettre le paquet. Même le transfert de plusieurs gros fichiers plus un flux TV HD en parallèle n'ont pu venir à bout de mon lecteur Raspberry / MPD. Donc en théorie oui, la perturbation est possible, en pratique, les débits élevés et un paramétrage correct du lecteur MPD font qu'il n'y a aucun problème.
Aussi, regardez simplement ce que fait une simple Raspberry avec le logiciel Kodi en cinéma HD. L'image est parfaitement fluide. Alors avec de la musique...
C'est juste un retour d’expérience avec ma config sous Linux / ALSA / MPD et transfert via NFS. Maintenant s'il existe des configurations hard/soft qui sont sensibles à ce ce type de problèmes c'est juste qu'elles sont mal conçues. Autant passer à quelque chose qui marche sans se prendre la tête sur son réseau.
En Wifi par contre, j'ai déjà eu des blancs...
Ceci dit, les autres solutions que tu proposes, si correctement paramétrées, fonctionneront aussi parfaitement, voir même mieux si les flux sont mieux gérés.

(12-18-2017, 10:56 AM)JBert a écrit : Inutile. Ethernet est filtré et remis à la terre dans toutes les prises RJ45.

Filtré contre les problèmes de HF peut-être bien. Mais contre les parasites du secteur et les courants de défaut je pense que non. Les masses sont interconnectées via les blindages de câble RJ45 : les courants de défaut passent dedans. Et même sans cela, ca passe quand même. J'ai pu le constater dans mes enceintes et en analysant le schéma interne des prises RJ45 de la Raspberry ainsi que le câblage des PHY. J'avais expliqué sur l'ancien forum bleu comment j'avais galéré avec ces saletés de courants parasites. Tout mon réseau balançait ces parasites dans mon lecteur réseau. J'ai sauvé le tout en mettant toute la chaîne en flottant par rapport à la terre.
Dans un réseau domestique, la plupart des appareils ne sont pas reliés à la terre (routeurs en boîtier plastique, NAS en boîtier plastique, box en boîtier plastique) et tout fonctionne avec des alims à découpage à deux balles. Ca génère des courants de découpage et du 50Hz en pagaille qui, faute de pouvoir être évacués localement (pas de connexion à la terre), viennent s'additionner dans le seul maillon relié à la terre : la chaîne HIFI. Dans ces conditions, un isolateur bloquera tout et empêchera ces courants de passer et polluer la chaîne. En foutant tout en flottant j'ai fait comme un isolateur. Mais une solution locale à chaque élément du réseau domestique fera aussi sont petit effet en diminuant la production de ces parasites.

Jacques

[JBert]

(12-18-2017, 02:43 PM)bbill a écrit :

(12-18-2017, 02:28 PM)JBert a écrit :

(12-18-2017, 01:56 PM)bbill a écrit :

(12-18-2017, 10:56 AM)JBert a écrit : il faut se poser la question du fonctionnement d'un réseau. La perte de qualité en passant par un routeur n'est pas due à des problèmes d'alimentation mais à des problèmes IP. IP n'est pas fait pour du temps réel, il y a des phénomènes de jitter, surtout en UDP.

il n'y a pas de problème de temps réel pour un lecteur réseau qui a un buffer.. le réseau n'est la que pour transférer des fichiers qui sont par definition exacts et "reçus" avant d'être utilisés

Euh... Si. Ce n'est pas que je veuille absolument vous contredire...

Il faut que le buffer de réception ne se vide pas entièrement. La plupart des buffers des équipements de réception sont notoirement insuffisants (quelques Ko) parce qu'ils coûtent cher en silicium et en gestion par les programmes. Lorsqu'il n'y a qu'un seul émetteur et un seul récepteur sur le réseau, ça passe. Lorsqu'il y a du trafic annexe, ça casse.

Je viens de vérifier sur un appareil qui a le bon goût d'avoir une console série. La taille par défaut du buffer RX est de 4k. Le programmeur est gentil, il a collé en dur une taille de 88Ko (je pense que c'est le maximum avant que ça déborde de a mémoire parce que c'est plutôt étrange comme valeur). Avec un flux correspondant à une qualité CD, ça fait 0,5s d'écoute dans le buffer de réception. Pas lourd en cas de congestion ou de routeur un peu léger.

je ne sais pas de quel lecteur réseau tu parles ??? tu parles bien de lecteurs réseau pour de la hifi ??

Eh oui. Je ne donnerais pas le type parce que j'ai dû faire du retro dessus et que je n'en ai normalement pas le droit.

Citation :je n'ai jamais eu ce problème avec tous les lecteurs réseau hifi qui sont passés par chez moi... jamais

ps : de plus, parler de "temps réel", comme tu le fais, pour un réseau Ethernet n'a pas de sens...

Pour Ethernet, ça n'a pas de sens. Pour l'application, ça en a un. Et c'est bien pour cela que TCP/IP utilise deux mécanismes de QoS différents. Ça fait cataplasme sur une jambe de bois, mais ça fait son boulot raisonnablement. Enfin, ça le fait pour des switches L3, pas pour les switches à 3 francs 6 sous qui sont L2.

De toute façon, si on veut éviter ce genre de problème, on ne prend pas un réseau Ethernet avec TCP/IP par dessus.

Cordialement.

---

(12-18-2017, 06:10 PM)bz31 a écrit :

(12-18-2017, 10:56 AM)JBert a écrit : Le RPi est incapable de gérer le réseau sans jitter important (parce que le truc est partagé avec l'USB et la flash) et que sa mémoire tampon interne est ridicule. Vous courez déjà à handicap.


Personnellement, j'investirais plutôt dans un switch manageable de niveau 3 (et un beaglebone à la place du RPi puisqu'il a une vraie mémoire eMMC et une vraie interface ethernet). Mais vous faites ce que vous voulez.

Intéressants ces points. Tu peux développer ?

Le CPU des RPI utilise le même bus USB (il n'en a que deux de mémoire, un host et un device) pour ses quatre ports externes et le réseau ethernet qui est en fait au cul d'un convertisseur USB/Ethernet. C'est n goulot d'étranglement car l'USB ne sait pas gérer les interruptions et l'électronique fait du polling. Ce n'est pas vraiment efficace (ça marche, mais côté performance, ça tire beaucoup sur le CPU).

[bbill]

(12-18-2017, 01:56 PM)bbill a écrit : je ne sais pas de quel lecteur réseau tu parles ???

(12-18-2017, 10:56 AM)JBert a écrit : Eh oui. Je ne donnerais pas le type parce que ..

aahhh oui, c'est donc un cas particulier !

[JBert]

(12-18-2017, 08:16 PM)Jacques92 a écrit :

(12-18-2017, 10:56 AM)JBert a écrit : avant d'investir dans des alimentations linéaires (et pouvoir se chauffer avec elles, c'est la saison), il faut se poser la question du fonctionnement d'un réseau. La perte de qualité en passant par un routeur n'est pas due à des problèmes d'alimentation mais à des problèmes IP. IP n'est pas fait pour du temps réel, il y a des phénomènes de jitter, surtout en UDP. Sur la VoIP, c'est une plaie à corriger et on n'y arrive pas toujours. Sur les réseaux domestiques, c'est pareil. Si on veut que ça fonctionne raisonnablement bien, il faut non seulement activer de la QoS, mais qu'elle soit prise en compte à tous les niveaux (y compris au niveau des routeurs, ce que ne font pas les switches intégrés des routeurs de madame Michu).

De mon côté, ayant un bon petit réseau avec des NAS et routeurs un peu partout dans la maison, j'ai fait pas mal de test.
Oui le jitter sur réseau Ethernet est important. Toutefois, là, on est encore dans le transfert asynchrone informatique de fichier (même s'il contient un audiogramme), Le jitter (au sens littéral) ne pose absolument aucun problème. Ce qui compte c'est que le fichier soit transféré plus vite que le DAC le consomme. La mémoire tampon (correctement paramétrée) annule complètement de jitter. En cas de problème on n'a aucunement affaire à des problèmes de distorsion mais tout simplement à des blancs dans la reproduction de la musique.

Pas forcément. Les équipements évolués peuvent estimer ce qui manque.

Citation :C'est donc très facile de tester.
J'ai réussi à reproduire ces blancs en saturant le réseau avec de l'injection de données à haut-débit en broadcast. Et il a fallu mettre le paquet. Même le transfert de plusieurs gros fichiers plus un flux TV HD en parallèle n'ont pu venir à bout de mon lecteur Raspberry / MPD. Donc en théorie oui, la perturbation est possible, en pratique, les débits élevés et un paramétrage correct du lecteur MPD font qu'il n'y a aucun problème.
Aussi, regardez simplement ce que fait une simple Raspberry avec le logiciel Kodi en cinéma HD. L'image est parfaitement fluide. Alors avec de la musique...

Tant que vous restez seuls sur le brin ethernet, ça fonctionne à peu près. Mais c'est tout. Avec un flux HD encodé sans perte de chrominance, vous êtes à la limite de l'interface réseau des RPI2 ou 3. Dans une autre vie, j'en ai eu plusieurs milliers dans la nature pour ce genre d'application chez des clients.

La gestion du réseau était folklorique.

Citation :C'est juste un retour d’expérience avec ma config sous Linux / ALSA / MPD et transfert via NFS. Maintenant s'il existe des configurations hard/soft qui sont sensibles à ce ce type de problèmes c'est juste qu'elles sont mal conçues. Autant passer à quelque chose qui marche sans se prendre la tête sur son réseau.
En Wifi par contre, j'ai déjà eu des blancs...
Ceci dit, les autres solutions que tu proposes, si correctement paramétrées, fonctionneront aussi parfaitement, voir même mieux si les flux sont mieux gérés.

(12-18-2017, 10:56 AM)JBert a écrit : Inutile. Ethernet est filtré et remis à la terre dans toutes les prises RJ45.

Filtré contre les problèmes de HF peut-être bien. Mais contre les parasites du secteur et les courants de défaut je pense que non.

Bien sûr que si. Transformateurs, selfs de mode commun, diodes de clamping et j'en passe. Tout peut-être intégré dans les connecteurs (Wuerth propose de très bonnes choses maintenant, on n'est plus contraints d'utiliser des filtres externes).

Citation :Les masses sont interconnectées via les blindages de câble RJ45 : les courants de défaut passent dedans. Et même sans cela, ca passe quand même. J'ai pu le constater dans mes enceintes et en analysant le schéma interne des prises RJ45 de la Raspberry ainsi que le câblage des PHY. J'avais expliqué sur l'ancien forum bleu comment j'avais galéré avec ces saletés de courants parasites. Tout mon réseau balançait ces parasites dans mon lecteur réseau. J'ai sauvé le tout en mettant toute la chaîne en flottant par rapport à la terre.

Masses ou terres ? Ce sont les terres qui doivent être connectées. Pas les masses. Et si un courant passe dans une terre, c'est qu'il y a un défaut quelque part (ou que vous êtes branché sur deux pieux de terre différents).

Citation :Dans un réseau domestique, la plupart des appareils ne sont pas reliés à la terre (routeurs en boîtier plastique, NAS en boîtier plastique, box en boîtier plastique) et tout fonctionne avec des alims à découpage à deux balles. Ca génère des courants de découpage et du 50Hz en pagaille qui, faute de pouvoir être évacués localement (pas de connexion à la terre), viennent s'additionner dans le seul maillon relié à la terre : la chaîne HIFI. Dans ces conditions, un isolateur bloquera tout et empêchera ces courants de passer et polluer la chaîne. En foutant tout en flottant j'ai fait comme un isolateur. Mais une solution locale à chaque élément du réseau domestique fera aussi sont petit effet en diminuant la production de ces parasites.

Objection

Le fait d'être en flottant n'empêche pas les parasites de passer (sinon, on ne pourrait faire aucune mesure en chambre anéchoïde sur la CEM conduite, les chambres étant flottantes). En revanche, un transformateur d'isolation tout venant a une fréquence de coupure basse qui apporte une certaine immunité.

[Jacques92]

Bonsoir JBert,

Citation :Transformateurs, selfs de mode commun, diodes de clamping et j'en passe. Tout peut-être intégré dans les connecteurs (Wuerth propose de très bonnes choses maintenant, on n'est plus contraints d'utiliser des filtres externes).

Jetez un petit coup d’œil au schéma interne d'une prise RJ45 équipée de transformateurs HF. Vous serez surpris de la connexion des masses.

Citation :Masses ou terres ? Ce sont les terres qui doivent être connectées. Pas les masses. Et si un courant passe dans une terre, c'est qu'il y a un défaut quelque part (ou que vous êtes branché sur deux pieux de terre différents).

Je parle de connexion entre les masses et la terre. Sur les appareils, la masse électrique est connectée sur le boitier qui est lui même connecté à la terre.  Le moindre filtre secteur ou des capacités parasites entre composants sous tension et boitier ramènent des courants parasites vers la terre, la quelle est reliée au neutre plus loin comme notre "régime de neutre" le montre.

Cdlr. Jacques

[JBert]

(12-19-2017, 02:15 AM)Jacques92 a écrit : Bonsoir JBert,

Citation :Transformateurs, selfs de mode commun, diodes de clamping et j'en passe. Tout peut-être intégré dans les connecteurs (Wuerth propose de très bonnes choses maintenant, on n'est plus contraints d'utiliser des filtres externes).

Jetez un petit coup d’œil au schéma interne d'une prise RJ45 équipée de transformateurs HF. Vous serez surpris de la connexion des masses.

Je ne les connais pas toutes, mais les WE que j'utilise quasiment tous les jours sont câblées correctement. Je ne vois pas ce que vous leur reprochez.

Citation :

Citation :Masses ou terres ? Ce sont les terres qui doivent être connectées. Pas les masses. Et si un courant passe dans une terre, c'est qu'il y a un défaut quelque part (ou que vous êtes branché sur deux pieux de terre différents).

Je parle de connexion entre les masses et la terre. Sur les appareils, la masse électrique est connectée sur le boitier qui est lui même connecté à la terre

Si la masse électrique est connectée au boîtier, il y a déjà un problème de conception (c'est même un défaut rédhibitoire pour une certification sécurité électrique). Si vraiment on ne peut pas faire autrement, on connecte la masse à la terre au niveau de la jonction de terre sur la prise d'entrée, jamais au niveau du boîtier parce qu'en cas de court-circuit, le potentiel du boîtier peut monter assez haut en raison de la résistance parasite entre prise de terre et boîtier vis à vis de celle entre le boîtier et le défaut.

Théoriquement, tout ceci est au même potentiel. Théoriquement, parce que lorsque la terre est utilisée pour un gros courant de défaut, ce n'est plus vrai. C'est pour cela qu'en CSA, vous avez l'obligation de connecter le boîtier au plus près du connecteur de terre de la prise et que vous partez en étoile depuis la terre de la prise pour connecter le cas échéant les masses.

Citation :Le moindre filtre secteur ou des capacités parasites entre composants sous tension et boitier ramènent des courants parasites vers la terre, la quelle est reliée au neutre plus loin comme notre "régime de neutre" le montre.

Cdlr. Jacques

Théoriquement, certainement. Dans la pratique, vous êtes plusieurs ordres de grandeur en dessous de ce qui pourrait être gênant. Même en utilisant un analyseur de secteur de type Hameg qui crache 800 mA sur la terre, cela ne perturbe pas le réseau Ethernet si vous avez fait tout ce qu'il fallait et que la terre est la même des deux côtés.

Bien cordialement.