Vivid Audio Giya G3, puis Kii3+BXT, puis Magico S3 mkII dans une pièce dédiée

[jalucine]

Y a plus qu'à trouver une date. Je suis en vacances du 17 au 24 décembre, après c'est le w-e du 25-26 février.

[Pascal64]

Il y a belle lurette que l'on sait qu'une bonne alim apporte des différences audibles sur une source.
Le Wifi est accessoire car en aucun cas il ne pourra reconstituer (nettoyer, ranger, dépolluer employez les termes que vous voulez) ce qui a été perdu (pollué etc) en amont.

Pas de Air3 chez moi mais mon Mini optimisé met un boulevard à un Mac mini d'origine en USB
Tout les gars qui sont passés à une alim de bonne qualité l'attestent, que ce soit sur Mac mini, PC  ou sur NUC.

Les plus sceptiques peuvent se rendre chez Patatras qui vous expliquera mieux que moi l'efficacité de son réseau de batteries sur le serveur ET le player.

Ma porte est également ouverte si souhaitez réaliser des essais avec vos Devialets.

[ThierryNK]

(12-11-2016, 04:09 PM)Pascal64 a écrit : Il y a belle lurette que l'on sait qu'une bonne alim apporte des différences audibles sur une source.
Le Wifi est accessoire car en aucun cas il ne pourra reconstituer (nettoyer, ranger, dépolluer employez les termes que vous voulez) ce qui a été perdu (pollué etc) en amont.

Pas de Air3 chez moi mais mon Mini optimisé met un boulevard à un Mac mini d'origine en USB
Tout les gars qui sont passés à une alim de bonne qualité l'attestent, que ce soit sur Mac mini, PC  ou sur NUC.

Les plus sceptiques peuvent se rendre chez Patatras qui vous expliquera mieux que moi l'efficacité de son réseau de batteries sur le serveur ET le player.

Ma porte est également ouverte si souhaitez réaliser des essais avec vos Devialets.

Les "interférences électriques" ne passent pas en Wifi.

Ce que tu dis, et auquel je souscris, concerne les liaisons physiques entre ordinateur et DAC/Devialet/FDA

Amitiés

[Pascal64]

(12-11-2016, 04:46 PM)ThierryNK a écrit : Les "interférences électriques" ne passent pas en Wifi.

Certes mais ces fameuses interférences électriques moucatent le flux avant même qu'il ne soit envoyé par Wifi.

Demetrios l'a vérifié chez lui puis avec pda0
D'autres sur le fil Devialet ont également fait ce genre de constatations.

Dan Bellity, lorsqu'il avait créé la Rosita avait affirmé qu'il ne servait à rien d'optimiser le signal en amont.
Depuis j'ai l'impression que ce discours arrange bcp de monde 

[Demetrios]

Bonjour à tous,

Je tiens tout d'abord à remercier chaleureusement Pda0 pour son accueil dans son "antre" bien sympathique. Nous avons passé un excellent moment à la fois à tester mais aussi à écouter son système vraiment abouti, qui est un régal.
Pda0 a à peu près tout dit, petite déconvenue avec Dirac qui n'accepte pas l'utilisation d'un filtre conçu avec au autre ordinateur que celui (ou ceux) qui sont déclarés sur son propre compte sur le site Dirac. Pas très grave finalement pour écouter ce que nous avions à écouter, à savoir les différences entre les 2 Mac Mini ; peut-être aussi bien finalement, car c'était du flux "pur" sans altération logicielle supplémentaire.

Il est vrai que les 2 logiciels de lecture étaient différents. Autant en USB je perçois une différence sensible entre Jriver et Audirvana, autant j'ai plus de mal avec Air 3.
Si je me rappelle bien Jalucine avait constaté des différences entre Itunes et Audirvana qui l'ont amené à préférer Itunes. Chez moi c'est tout le contraire entre Itunes et Audirvana, ce dernier ayant ma nette préférence.
Je rappelle ici ce que Devialet m'a répondu sur Air 3 :

Cher Arnaud, 
 
Voici donc la réponse exacte ! 
 
AIR ne modifie pas le format des fichiers en cours de lecture.
Le format utilisé sera celui du fichier en cours de lecture si le lecteur utilisé exploite le mode exclusif (Hog Mode sur Apple et Wasapi sur Windows) ou, dans le cas contraire, le format par défaut du mixeur
Pour répondre à vos questions, oui, le lecteur utilisé aura une influence sur la qualité de lecture car c'est lui qui va configurer, d'une certaine façon, le format de fichier à utiliser par l'amplificateur.
En ce qui concerne le Direct Mode d'Apple, c'est une fonctionnalité spécifique d'Apple qui permet de récupérer directement depuis l'espace utilisateur les échantillons audio disponibles au niveau de la carte son (on gagne du temps et on évite des traitements éventuels sur ces échantillons audio).
Nous ne sommes pas compatible avec le Direct Mode d'Apple, c'est pourquoi certains utilisateurs rencontrent des problèmes lorsqu'ils l'activent. Ceci étant dit, aussi bien sur Windows que sur Apple, nous avons mis en place un mécanisme similaire, les échantillons audio sont envoyés directement depuis la carte son jusqu'à l'application AIR, sans aucun intermédiaire. Rassurez vous, même sans activer le Direct Mode, vous bénéficiez déjà de cette fonctionnalité.

Première conclusion, le player a effectivement un effet sur la conception du flux audio.
Pour Pda0 : depuis que j'ai décoché l'accès au mode exclusif d'Audirvana, il ne plante plus jamais avec Air3.

Les tests réalisés chez Pda0 entre les 2 Mac Mini ont conclut aux mêmes résultats que ce que j'avais pu constater chez moi : http://forum-hifi.fr/thread-43-post-50173.html#pid50173
Pour ce test, il s'agissait de 2 Mac Mini identiques de 2011, l'un optimisé, pas l'autre, tournant sur la même carte SD contenant l'OS, Dirac et Audirvana : conditions identiques.

En résumé, c'est plus "propre", plus fluide, plus fin.

Ma conclusion :
le hardware et le software ont une influence sur l'élaboration du flux audio, avant qu'il ne soit transmis par Air3.
Jusqu'à preuve du contraire... :-)

Bien sûr le test réalisé chez Pda0 mérite d'être reconduit toutes choses égales par ailleurs pour ceux que ça intéresse. Quand à savoir pourquoi il y aurait une amélioration, ça, je le laisse à certains d'entre vous qui ne lâcheront pas le morceau...!

Je regarde mes dispos pour les week-end.

Bonne soirée.
D.

[ThierryNK]

Salut les amis 

Pour mémoire, quand on est en USB, et les essais ont été faits des dizaines de fois, on récupère ce qui sort en USB de Jriver, ou d'Audivarna ou de ce que vous voulez comme lecteur bit pefect, on re-écrit le fichier de départ à partir de cette sortie et on a exactement le fichier de départ.

Je veux bien que chacun "croit" à ce qu'il veut, mais peut-être faut-il de temps à autre étalonner ses croyances par rapport à la réalité. Il n'y aucune "mucatitude"   des données au départ.

Pourrait-on une seconde revenir à ce qu'il y a dans un fichier audio PCM:

- des entêtes pour dire comment sont rangées les données (flac, wave, AIF...)
- une série d'entiers

On est donc en train de parler du transfert d'entiers que l'on "emballe" de différentes manières suivant le protocole utilisé. On est loin de mettre en orbite un satellite...

En USB classique, il n'y a strictement aucune donnée d'horloge qui soit transmise. L'horloge côté DAC ou ordinateur ne sert qu'à faire demander et déclencher le transfert de nouvelles données de l'ordinateur vers l'appareil audio. Aucune audio là-dedans.

Il ne s'agit que de transférer des données. Et il ne s'agit PAS d'un flux audio, il faut réintroduire une horloge à l'arrivée pour faire du son. Pendant le transfert, les données sont en quelque sorte uniquement numérotées 1,2, 3 etc.

En Spdif et AES, ce n'est pas la même histoire. L'horloge audio est INCLUSE dans le signal qu'on envoie. Ce signal, avec son horloge audio est fabriqué côté source, drive CD, drive numérique,  carte son. Il s'agit là d'un réel flux audio.

Alors que fait AIR? Ce n'est documenté nulle part. Les réponses données à Démétrios ne sont en aucun cas pertinentes ni utiles. On les trouve ici: https://help.devialet.com/hc/fr/articles...ta-testing-

Citation :AIR ne modifie pas le format des fichiers en cours de lecture

Heureusement!! Ce serait donc un fichier, avec ses entêtes qui est transmis?

Citation :Pour répondre à vos questions, oui, le lecteur utilisé aura une influence sur la qualité de lecture car c'est lui qui va configurer, d'une certaine façon, le format de fichier à utiliser par l'amplificateur

Non, il n'y a qu'une seule et unique façon de représenter des données PCM, c'est l'ensemble des entiers dont je parle plus haut. Les différents pilotes, logiciels, etc, prennent ou pas un certain nombre de précautions pour extraire puis transmettre ces données et établir une liaison électrique et logique entre ordinateurs et appareils audio. Pour mémoire et par exemple, on est en présence d'entiers, et les premiers pilotes audio Windows, faisaient des conversion (inutiles) d'entiers vers des flottants, pour revenir à des entiers, avec quelques surprises à l'arrivée...

A moins que...

On peut voir écrit sur la page où la réponse a été donnée à Demetrios:

Citation :Air est un protocole de transmission du flux audio

Ah bon, ce n'est plus un fichier?

Alors de 2 choses l'une:

- ou bien cette affirmation est exacte, et AIR est un protocole qui intègre l'horloge audio depuis l'ordinateur, et on est bien en présence d'un "flux audio", et tout devient possible y compris en Wifi comme différences entre logiciels, OS, Hardware, alimentations, etc

- ou bien elle est erronée, et AIR ne transfère que des données, sans aucune horloge audio, et dans ce cas, quelle que soit le logiciel, le hardware, les alimentations, etc, il n'y a aucun différence dans les données transmises en Wifi (ou sur ethernet ou sur USB d'ailleurs).

En passant, on peut aussi lire sur la page en question, le problème des sboings et autres bruits blancs, qui reprend la question du hardware réseau défaillant.

C'est bien pour toutes ces raisons (délirantes) que j'ai abandonné l'ordinateur en liaison directe avec des appareils audio. Quand on transfert un fichier complet et que toute l'audio est faite à l'arrivée, lecture/transfert en I2S au DAC, comme dans une bonne vieille platine CD, on  oublie très très vite toutes ces questions surréalistes qui certes occupent les forums et permettent de vendre des tas de câbles USB, mais si on se rappelle ce qui se passe vraiment, c'est juste affligeant.

Toutes ces questions me semblent juste équivalentes à se les prendre et se les taper sur bord du trottoir. Hummmm, que c'est bon quand ça s'arrête.

Amitiés

[Demetrios]

Bonsoir Thierry,

Merci pour ton post éclairé.

Mon expérience : avec la même source Mac Mini, il y a des différences de restitution entre la transmission Air3 par wifi et par RJ45.
C'est indiscutable.

Si je suis ton raisonnement, j'en conclus donc que nous sommes dans le cas de ta première hypothèse, Air transmet un flux audio.

Ce raisonnement est-il juste ?

Amitiés,
D.

[Bear]

(12-12-2016, 11:43 PM)Demetrios a écrit : Bonsoir Thierry,

Merci pour ton post éclairé.

Mon expérience : avec la même source Mac Mini, il y a des différences de restitution entre la transmission Air3 par wifi et par RJ45.
C'est indiscutable.

Si je suis ton raisonnement, j'en conclus donc que nous sommes dans le cas de ta première hypothèse, Air transmet un flux audio.

Ce raisonnement est-il juste ?

Amitiés,
D.

Bonsoir Arnaud,

Dans le cas que tu évoques, ne serait-ce pas plutôt la pollution éventuelle de la connexion RJ-45 par des interférences HF (RJ-45 étant supposé galvaniquement isolé selon la norme) qui serait la cause de cette différence ?

Avec un USB asynchrone, et un protocole Ethernet (WiFi et RJ-45 ) qui est asynchrone par nature, je ne vois pas Devialet se mettre à compliquer les choses pour mettre un signal d'horloge sur une transmission de paquets qui est simple par ailleurs...

[ThierryNK]

Bonsoir

A la question de Demetrios, je suis absolument incapable de répondre, il faudrait savoir ce que fait AIR d'une part, et connaitre les raisons qui font (ou faisait si cela a été corrigé) partir en vrille l'interface réseau.

Les moyens de contournement de ce dernier problème, par les uns et les autres, reviennent à éviter que d'autres informations que des données audio arrivent sur l'interface, alors qu'il n'y a strictement rien d'anormal à recevoir du "broadcast" (message envoyé à tout le monde sur le réseau) de la part d'un serveur DHCP ou autre.

Les 2 questions, AIR d'un côté, interface réseau de l'autre, me semblent liées, impossible de trouver des raisons à des différences à l'écoute, sans avoir des specs précises des 2.

Les points "durs" sur lesquels s'appuyer, c'est que du transfert de données, sans horloge, c'est très robuste, que cela se vérifie aisément, et que d'éventuelles données perdues de temps en temps (si pas de vérification à l'arrivée, ni rappel des données non reçues, contrairement à tcp/ip sur ethernet), ne peuvent en aucun cas expliquer un comportement "systématique" et permanent sur les écoutes. Cela commencerait à se savoir si quand on imprime une page d'Asterix on récupère du Marguerite Duras 

Le second point dur, c'est que la "fabrication" d'un flux audio (avec horloge), et donc temps réel (spdif, AES, AIR??) est lui soumis à des tas de paramètres, comme simplement la latence et la taille du buffer où sont stockées les données avant d'être couplées à une horloge. Cette question existe de manière naturelle côté DAC, mais elle existe aussi côté source dans le cas de la fabrication d'un flux audio.
Pour mémoire, les drivers   "ASIO" ont été conçus, entre autres, pour gérer des questions de latence. https://en.wikipedia.org/wiki/Audio_Stream_Input/Output
A ASIO a succédé WASAPI, qui est fait pour du flux audio temps réel, comme on peut le voir ici https://en.wikipedia.org/wiki/Technical_...chitecture

A l'arrivée, les pauvres utilisateurs Windows d'USB, se retrouvent avec des drivers faits pour de l'audio temps réel avec horloge, alors qu'il n'y a aucun temps réel et aucun flux audio en USB!! Et qu'aujourd'hui encore, ils sont à comparer ce qu'ils obtiennent en fonction de drivers USB!!!

Côté Mac, les choses sont sans doute faites proprement côté système et USB, bien plus proprement que sur Windows, mais comment est couplé AIR à ce système, aucune idée.
Ne pas utiliser tous les outils natifs de OSX conçus par des dizaines de développeurs Apple, de la part de 1 ou 2 ingénieurs Devialet, me semble juste symptomatique du terrible NIH https://fr.wikipedia.org/wiki/Not_invented_here 

Je suis tout à fait d'accord avec Bear pour dire que cela aurait été furieux de faire du flux audio au lieu du transfert de données. Mais pour des personnes comme Jalucine qui utilisent Devialet depuis longtemps, il semble y avoir eu un changement radical de AIR à un moment, au moment où AIR a pu s'interfacer avec n'importe quel logiciel audio et devenir une "carte son" plus ou moins standard.


Une petite remarque, sans aucune acrimonie pour Bear. Quand tu as parlé sur un autre fil des "ressources informatiques et réseau" nécessaires pour AIR, je n'ai pas voulu réagir en direct. Mais extraire les données d'une piste audio, même en 24/192, c'est une fraction de pourcentage (je veux dire qq chose comme 0.1%) d'un seul coeur d'un processeur actuel, et du 24/192, c'est au pire 1.2 Mo/s, 10 Mbps, loin des 54 Mbps d'un Wifi G. Et pour du 16/44, c'est 150 Ko/s, 1,2 Mbps. Alors un superculateur pour lire une piste audio, non!! 

Pour que dans ce mxxdier, un utilisateur lambda s'y retrouve, bonjour! et je comprends finalement très bien tous ceux qui disent que la démat c'est le bxxdel.

Ah oui, il existe d'autres protocoles réseau qui fonctionnent très bien, AES67, https://en.wikipedia.org/wiki/AES67 utilisé par NADAC, et le protocole propriétaire Roon, https://roonlabs.com Les 2 fonctionnent sans aucun malaise.

Implémenter Roon et offrir un abonnement Roon à leurs clients, serait peut-être un moyen de sortir de tout ça par le haut.

Amitiés

[Bear]

(12-13-2016, 12:20 AM)Bear a écrit :

(12-12-2016, 11:43 PM)Demetrios a écrit : Bonsoir Thierry,

Merci pour ton post éclairé.

Mon expérience : avec la même source Mac Mini, il y a des différences de restitution entre la transmission Air3 par wifi et par RJ45.
C'est indiscutable.

Si je suis ton raisonnement, j'en conclus donc que nous sommes dans le cas de ta première hypothèse, Air transmet un flux audio.

Ce raisonnement est-il juste ?

Amitiés,
D.

Bonsoir Arnaud,

Dans le cas que tu évoques, ne serait-ce pas plutôt la pollution éventuelle de la connexion RJ-45 par des interférences HF (RJ-45 étant supposé galvaniquement isolé selon la norme) qui serait la cause de cette différence ?

Avec un USB asynchrone, et un protocole Ethernet (WiFi et RJ-45 ) qui est asynchrone par nature, je ne vois pas Devialet se mettre à compliquer les choses pour mettre un signal d'horloge sur une transmission de paquets qui est simple par ailleurs...

Arnaud,

Je pense qu'en réalité tu as raison et que Devialet a mis dans AIR, coté Mac, les ressources de transformation du fichier audio en flux audio, simplement par manque de ressources pour ce faire au niveau de l'ampli. C'est ce gap qu'ils sont en train de combler avec la carte qui va fournir un 'player' DLNA sur l'ampli.

Si je me remémore correctement mes échanges avec le développeur de AIR au printemps passé, AIR a été développé et testé avec comme objectif de bien fonctionner avec iTunes. C'est sans doute la raison pour laquelle Jalucine en est content.

Il me semble à ce stade qu'il est urgent d'attendre la nouvelle carte avant de se lancer dans la transformation des MacMini. Car une fois le Devialet équipé d'un lecteur DLNA, tout ceci ne sera plus qu'un mauvais souvenir