"il ne peut faire tomber de l'eau" > En fait si, il peut faire tomber de l'eau, enfin ça dépend du protocole. Tous les protocoles asynchrones n'intègrent pas forcément un contrôle d'erreur, mais ils peuvent.
Pour rendre l'exemple plus précis, il faudrait de l'eau à la fraise (rouge) et à la menthe (verte) pour représenter les bits 0 ou 1.
B1, c'est l'ordi. Si le protocole a un contrôle d'erreur, la communication sera bidirectionnelle. Il va y avoir un autre bonhomme, appelons C pour "contrôleur" qui va contrôler que tout est bon sur ce qui arrive sur la table. Il va faire ce contrôle par paquets, par exemple par paquets de 16 verres. Tous les 16 verres, il vérifie que tout est bon et si c'est pas bon, il va dire à B1 : stop ! Ce paquet n'est pas bon , renvoie le.
B1 c'est l'ordi, il a le fichier d'origine, il va aller le relire pour renvoyer les bons bits jusqu'à ce que C soit content.
Après on s'en fout un peu puisqu’en pratique, aucun verre ne tombe jamais par terre.
Au passage, c'est C qui regarde s'il y a de la place sur la table et qui dit à B1 quand envoyer des paquets.
"la table elle est où? dans le pc ou dans le dac?" > en fait, il y a 2 tables. La première dont j'ai parlé, et celle que j'ai rajoutée pour décrire le protocole Asynch. Appelons les T1 et T2. T1 est la table dans laquelle pioche B1, c'est la mémoire de l'ordinateur, on s'en fout un peu. T2 est la table entre B1 et B2, c'est la mémoire du contrôleur USB du DAC.
Donc dans le PC on a : B1 et T1.
Dans le DAC on a : B2, T2 et C
Notez que C, le "gendarme" de la communication entre le DAC et l'ordi. Et C est dans le DAC. Le DAC est maître de la communication. C'est lui qui dit quand envoyer et, s'il y a contrôle d'erreur, c'est lui qui dit qu'est-ce qui n'est pas bon et quoi renvoyer. L'ordi est "esclave" du DAC.
"Imaginons un tremblement de terre, la table bouge beaucoup et bien qu'il y ait beaucoup de verre sur la table, le Dac n'arrive pas à attraper les verres à temps...." > alors tu n'auras plus de son et par contraposée, si tu as du son c'est que ta table n'est pas vide.
Il y a un cas classique ou une table peut se vider et ou ça s'entend (par une rupture du flux audio qui arrête/reprend et donc ça crachote grave) : c'est quand le buffer Asio est trop petit vs la charge CPU. Parce qu'en fait des tables (des buffer mémoire), il y en a des tonnes et des tonnes dans un PC et si vous écoutez en streaming, il y en a plein du serveur jusqu'à chez vous (dans le serveur, dans les routeurs, dans votre box). Le buffer Asio c'est une mémoire du driver Asio. En musique pro, vu qu'on mélange de la musique numérique et du live, il faut impérativement T2 ne contienne pas trop de verre sinon il y aura un décalage entre ce que joue le DAC et ce que jouent les autres instruments "temps réels", notamment tous les instruments live. En hihi, on s'en tape, c'est pourquoi il faut régler la tailler de ce buffer le plus haut possible.
"Que penser du coup de ceux qui chaines 2 ou 3 Mutec pour redresser le signal? Juste un comportement compulsif??" > c'est toujours difficile de généraliser. Remettre ne forme un signal spdif avant d'attaquer la puce du DAC est fortement recommandé mais c'est au DAC de le faire. Il est le mieux placé car au plus près. Remettre en forme un signal USB asynch, c'est totalement inutile. Donc, sauf cas particulier, l'ajout de boitiers entre le DAC et le PC ne sert strictement à rien. Si votre DAC a une mauvaise entrée, changez de DAC.
Après, il y a des gens qui entendent des différences avec ou sans boitier. Il y a aussi des gens qui entendent des différences dans les câbles, dans les soudures, entre un WAV et un Flac. Moi le premier d'ailleurs, j'entends des différences, mais je n'entends plus rien en aveugle. Le jour ou quelqu'un produira une mesure ou un ABX réussi à ce niveau, je changerai d'avis. Après chacun fait ce qu'il veut de ses sous, je ne fais qu'essayer d'epliquer le fonctionnement, convaincre les subjectivistes les plus acharnés, pour avoir maintes fois essayé, je ne fais plus depuis longtemps.
Je recommande à tous ceux qui entendent un truc qui va contre la théorie de faire un test en aveugle, personne ne risque rien en augmentant le champ de son expérience.
Pour rendre l'exemple plus précis, il faudrait de l'eau à la fraise (rouge) et à la menthe (verte) pour représenter les bits 0 ou 1.
B1, c'est l'ordi. Si le protocole a un contrôle d'erreur, la communication sera bidirectionnelle. Il va y avoir un autre bonhomme, appelons C pour "contrôleur" qui va contrôler que tout est bon sur ce qui arrive sur la table. Il va faire ce contrôle par paquets, par exemple par paquets de 16 verres. Tous les 16 verres, il vérifie que tout est bon et si c'est pas bon, il va dire à B1 : stop ! Ce paquet n'est pas bon , renvoie le.
B1 c'est l'ordi, il a le fichier d'origine, il va aller le relire pour renvoyer les bons bits jusqu'à ce que C soit content.
Après on s'en fout un peu puisqu’en pratique, aucun verre ne tombe jamais par terre.
Au passage, c'est C qui regarde s'il y a de la place sur la table et qui dit à B1 quand envoyer des paquets.
"la table elle est où? dans le pc ou dans le dac?" > en fait, il y a 2 tables. La première dont j'ai parlé, et celle que j'ai rajoutée pour décrire le protocole Asynch. Appelons les T1 et T2. T1 est la table dans laquelle pioche B1, c'est la mémoire de l'ordinateur, on s'en fout un peu. T2 est la table entre B1 et B2, c'est la mémoire du contrôleur USB du DAC.
Donc dans le PC on a : B1 et T1.
Dans le DAC on a : B2, T2 et C
Notez que C, le "gendarme" de la communication entre le DAC et l'ordi. Et C est dans le DAC. Le DAC est maître de la communication. C'est lui qui dit quand envoyer et, s'il y a contrôle d'erreur, c'est lui qui dit qu'est-ce qui n'est pas bon et quoi renvoyer. L'ordi est "esclave" du DAC.
"Imaginons un tremblement de terre, la table bouge beaucoup et bien qu'il y ait beaucoup de verre sur la table, le Dac n'arrive pas à attraper les verres à temps...." > alors tu n'auras plus de son et par contraposée, si tu as du son c'est que ta table n'est pas vide.
Il y a un cas classique ou une table peut se vider et ou ça s'entend (par une rupture du flux audio qui arrête/reprend et donc ça crachote grave) : c'est quand le buffer Asio est trop petit vs la charge CPU. Parce qu'en fait des tables (des buffer mémoire), il y en a des tonnes et des tonnes dans un PC et si vous écoutez en streaming, il y en a plein du serveur jusqu'à chez vous (dans le serveur, dans les routeurs, dans votre box). Le buffer Asio c'est une mémoire du driver Asio. En musique pro, vu qu'on mélange de la musique numérique et du live, il faut impérativement T2 ne contienne pas trop de verre sinon il y aura un décalage entre ce que joue le DAC et ce que jouent les autres instruments "temps réels", notamment tous les instruments live. En hihi, on s'en tape, c'est pourquoi il faut régler la tailler de ce buffer le plus haut possible.
"Que penser du coup de ceux qui chaines 2 ou 3 Mutec pour redresser le signal? Juste un comportement compulsif??" > c'est toujours difficile de généraliser. Remettre ne forme un signal spdif avant d'attaquer la puce du DAC est fortement recommandé mais c'est au DAC de le faire. Il est le mieux placé car au plus près. Remettre en forme un signal USB asynch, c'est totalement inutile. Donc, sauf cas particulier, l'ajout de boitiers entre le DAC et le PC ne sert strictement à rien. Si votre DAC a une mauvaise entrée, changez de DAC.
Après, il y a des gens qui entendent des différences avec ou sans boitier. Il y a aussi des gens qui entendent des différences dans les câbles, dans les soudures, entre un WAV et un Flac. Moi le premier d'ailleurs, j'entends des différences, mais je n'entends plus rien en aveugle. Le jour ou quelqu'un produira une mesure ou un ABX réussi à ce niveau, je changerai d'avis. Après chacun fait ce qu'il veut de ses sous, je ne fais qu'essayer d'epliquer le fonctionnement, convaincre les subjectivistes les plus acharnés, pour avoir maintes fois essayé, je ne fais plus depuis longtemps.
Je recommande à tous ceux qui entendent un truc qui va contre la théorie de faire un test en aveugle, personne ne risque rien en augmentant le champ de son expérience.
To be and not to be, that is the answer.