"Bits are bits" ...

[renardeaux]

Certains prétendent que la couleur du chat témoigne de son caractère. Je tiens moi que ma petite chatte qui voit son pelage légèrement se tâcher de blanc à un miaulement avec des feulements plus profonds.

[Candide]

On peut considérer comme vraies certaines assertions qui ne concernent pas pourtant des faits bruts. 

Si l audiophile x dit le composant a sonne mieux que le composant b, l assertion vraie est:

S il n a pas d intérêt materiel à promouvoir a sur b, x a vraiment perçu une différence euphonique entre a et b. 

Si vous êtes d humeur badine, une petite chanson sur la vérité statistique:

95 fois sur cent,
La chatte s'emmerde en miaulant
Qu elle nous teste ou nous conteste
C est pas tous les jours 
Qu on lui dévide les croquettes.

[renardeaux]

(11-29-2017, 02:35 PM)Candide a écrit : On peut considérer comme vraies certaines assertions qui ne concernent pas pourtant des faits bruts. 
Si l audiophile x dit le composant a sonne mieux que le composant b, l assertion vraie est:
S il n a pas d intérêt materiel à promouvoir a sur b, x a vraiment perçu une différence euphonique entre a et b. 

Ou ses sens l'abusent, ou il dit ce qui lui passe par la tête voire entre les oreilles

(11-29-2017, 02:35 PM)Candide a écrit : Si vous êtes d humeur badine, une petite chanson sur la vérité statistique:
95 fois sur cent,
La chatte s'emmerde en miaulant
Qu elle nous teste ou nous conteste
C est pas tous les jours 
Qu on lui dévide les croquettes.

On ne s'occupe jamais assez gentiment des petites chattes, ne crois-tu pas

[Candide]

Ce qu on perçoit est fourni par nos sens à notre conscience. La perception peut être réelle et abusée. 

Je viens de me faire extorquer des croquettes par un felis catus Linnaeus femelle insatiable. Ai essaye de caresser et me suis pris un miaou furibard, du genre pas ce soir. Il y en a, parait il, qui sont reconnaissants:

https://m.youtube.com/watch?v=X6uIrnvIFbo

[renardeaux]

Boby est un maître.
À l'aune de qui pourrait se mesurer parfois certains de nos échanges.

[Morbius]

Salut,


 alors je débarque et je n'ai pas lu les 42 pages. Juste la première et les dernières.
 Je vais probablement faire des redites mais est-ce bien grave, vu qu'apparemment ça a dérivé sur les matous pour une raison mystérieuse. Encore un coup du chat de Schrodinger ?

 Il y 2 niveaux d'erreurs dans un signal numérique : celui qui fait perdre des bits (cas 1) et celui qui n'en fait pas perdre (cas 2) et qui se contente d'amocher la tête du signal qui, au lieu d'avoir de beaux carrés, se met à ressemblé à ça (graphe de gauche) :



 On appelle ça du bruit ou du jitter, c'est quasi la même chose, le jitter est juste une façon de voir le bruit sous l'angle temporel.

 Le cas 1 ne concerne pas la hifi, aucun bit n'est perdu par une liaison USB, coax ou optique. Si vous avez une carte son a entrée numérique, vous pouvez le démontrer par un test simple : jouez un wav sur une sortie numérique, enregistrez-ce via une entrée numérique, mettez ce que vous voullez de bit perfect entre les deux (un converto USB => spdif, 5 m de câble pourri), comparrez les fichiers : identiques sur toute la lignes.

 Le cas 2 est plus complexe. Oui, en entrée de la puce d'un convertisseur, un signal numérique bruité (que le bruit soit du pur parasite ou du jitter) influence ce qui sort du converto (donc le signal analogique, donc le son). Les puces y sont plus ou moins sensibles selon leur type mais elles y sont toutes sensibles. Des mesures le prouvent.

 Ok, oui mais ... Oui mais ce qui sort de votre PC n'est pas le signal donné au convertisseur.

 Il existe plusieurs façons de remettre un signal numérique en forme : la PLL par exemple, dont le fonctionnement est fort bien expliqué par Jipihorn.

 Dans le cas de l'USB asynchrone, le signal est plus que remis en forme par le DAC : il est construit par le DAC. Il ne dépend que de la qualité du DAC, pas de celle du PC en amont, comme le montrent les mesures du premier post de ce topic.

 Le signal USB entre le DAC et le PC est un flux de données pures, par paquets, son horloge est celle d'un contrôleur USB et n'a aucun rapport avec l'audio.

 Tentative d'analogie avec des verres d'eau : imaginez 2 bonhommes B1 et B2.

 B1 (le PC) prend des verre d'eau sur un table pleine de verre d'eau.

 B2 (le DAC) reçoit les verres que lui donne B1. Il se synchronise sur B1, c'est à dire que si B1 va vite, B2 va vite, si B1 est lent, B2 est lent.

 A chaque foi que B2 reçoit un verre, il le verse dans un entonnoir au bout duquel il y a un tuyau qui part vers le bas. Quand on verse un verre dans l'entonnoir, il met exactement 1s à se vider par le tuyau.

 Le but du jeu : avoir un flux d'eau continu dans le tuyau.

 On voit bien que dans ce cas, il faut que B1 donne un verre d'eau  B2 exactement toutes les secondes. S'il ralentit ou accélère, ça va se ressentir dans le flux d'eau qui est dans le tuyau.

 Maintenant, rajouter une autre table entre B1 et B2. La table, c'est l'équivalent d'un buffer mémoire.
 B1 prend des verres et les pose sur cette table. B2 prends des verres sur cette table et les vide dans l'entonnoir.

 Quelle condition pour avoir exactement un verre par seconde ? Il faut que B2 prenne et verse un verre d'eau par seconde et il faut que B1 aille suffisamment vite pour que la table ne soit pas vide.

 Et pourquoi ça marche mieux ? Parce que B2 est un DAC, qu'il intègre une bonne horloge exactement construite pour faire un verre d'eau par seconde et parce que B1 est un PC, qu'il va à 10 000 à l'heure et qu'en un millième de seconde il a déjà rempli toute la table et qu'il peut aller pisser un coup le temps que ça se vide un peu avant de la re-remplir.

 Il peut même faire tomber de l'eau par terre, il a largement le temps de re-remplir son verre.

[Chet]

Ta modélisation avec les verres d'eau, c'est... Comment dire... ?
... LIMPIDE

[curiosity]

Exactement! : clair et on peut allez dormir..avec le chat qui ronronne ...et émet des vibrations..que je m'en vais le poser sur une plaque de granit celui la

[renan]

Oui intéressant comme analogie.
Mais il ne peut faire tomber de l'eau car dans un morceau la première note n'est pas égale à la 1000eme contrairement aux molécules d'eau qui sont toutes identiques donc s'il fait tomber de l'eau des bits sont perdus ce qui n'est pas notre point ici comme tu le soulignes.

Par contre la table elle est où? dans le pc ou dans le 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....


Disons que sur les forums, on voit beaucoup de situation ou améliorer les horloges de la source semble améliorer le rendu (reclocking, mutec usb , world clock etc). Ça ce comprend si on envoi un signal trop mauvais pour que le dac redresse correctement tout. Mais pour la plupart on est sur des horloges au moins aussi qualitatives que celles des dac.

Que penser du coup de ceux qui chaines 2 ou 3 Mutec pour redresser le signal? Juste un comportement compulsif??

[Morbius]

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