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
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