C'est quoi pour vous un pc audiophile

[Morbius]

Bon, j'ai regardé le test donné par ThierryNK.
Comparaison de câbles USB, mesure et écoute.
Pas d'écart sur le signal analogiqe en soirtie du dac (of course), y compris câble ultra pourri avec rallonge.
Sauf dans le cas d'un DAC à transfer isochrone (donc synchrone je crois) ou on a quelque chose au niveau du jitter mais rien sur l'analogique qui en découle, confirmant les assertions de Jipi.
Y aurait-il un test qui prouverai le contraire ?

Sinon, concernant cette histoire de latence, tu voulais en venir où Thierry ?

[ThierryNK]

Of course?

Qq mesures dans ce sens ne démontrent strictement rien de général. Un peu de rigueur dans les raisonnements non?

[Morbius]

(02-18-2016, 01:40 AM)ThierryNK a écrit : Of course?

Qq mesures dans ce sens ne démontrent strictement rien de général. Un peu de rigueur dans les raisonnements non?

Puisqu'on parle de rigueur, peux-tu lire correctement avant de répondre ?
Ai-je écrit que que quelques mesures démontrent quoi que ce soit de général ?
Le lien que tu donnes sur la vidéo Jipi par contre lui démontre un peu plus. Le titre est "le mythe du jitter".

Passons ...

Au lieu de t'accrocher à un petit "of course", simple façon de parler, peux tu m'expliquer par un raisonnement rigoureux en quoi une latence d'un buffer (que ce soit en écriture ou en lecture) indique qu'un logiciel ou un système d'exploitation peut avoir un impact quelconque sur un jitter en sortie de carte son ?

J'en suis à ma deuxième relance, je commence à croire que tu évites le sujet.

[ThierryNK]

Je n'ai rien de plus à dire que les 2 derniers post et les liens fournis.

Je n'ai jamais cherché à démontrer quoi que ce soit sur un forum, je fournis des documents et des mesures que j'ai trouvé intéressants, je rapporte mes propres expériences audio, ensuite à chacun d'en tirer ce qu'il veut. Comme je l'ai déjà dit dans un autre post, je n'aime pas les évangélisateurs, et je ne vais pas endosser ce rôle.

Un petit dernier pour la route: https://www.dropbox.com/s/p5njtp28f6fz2z...e.pdf?dl=0

Amitiés

[Pascal64]

Salut Thierry.
Très bon article que ce papier de Mr Plisson (je me demandais quand tu allais nous le sortir   )

Il m'arrive de le relire ...


J'ai la jigue jusque dans les guibolles maintenant, c'est malin  

[ThierryNK]

Salut Pascal

Nouveau forum, nouveaux participants, mais le décor reste le même. 

Amitiés

[Morbius]

(02-18-2016, 01:40 AM)ThierryNK a écrit : Un peu de rigueur dans les raisonnements non?

(02-16-2016, 07:31 PM)ThierryNK a écrit : N'importe quelle latence (aléatoire) entre top horloge et action est source de jitter.

Voici pourtant une affirmation sans la moindre rigueur.
Tu ne dis pas quelle action ni quelle horloge (il y en a deux dans un processus asynchrone).

(02-16-2016, 07:31 PM)ThierryNK a écrit : Dans ce que décrit Thierry Gluzman (dont le métier principal n'est pas journaliste audio, mais l'informatique temps réel) c'est l'accumulation de latences à différents endroits d'un système, qui ne conduit pas à un jitter de type électromagnétique ou de variation d'horloge, mais d'un flux électrique temps réel qui ne contient pas les bonnes données au bon endroit, ce qui est strictement équivalent à un jitter d'horloge.

Toujours aucune rigueur.
Le gars fait de l'informatique temps réel. Quel argument rigoureux en effet !
Et non, l'accumulation des latences logicielles ne génèrera pas de jitter car c'est asynchrone.
Schéma :



Le logiciel et le driver qui sont exécutés par le CPU et qui font appel au DD, la ram, etc écrivent les échantillons dans le buffer en rentrant par la case 6 et l'échantillon va descendre vers les cases de plus bas rang jusqu'à s'empiler juste avant la dernière case non vide.

Le buffer est un buffer de 6 échantillons dans mon exemple. Il faut le voir comme un FIFO, les échantillons rentrent par le 6 et sortent par le 1. Je remplis ma baignoire par le 6 et elle se vide par le 1.

Le hardware de la carte son (donc aucun rapport avec le soft de lecture) va lire du côté du 1. A chaque lecture, il enlève l'échantillon en '1' et tous les échantillons présents dans le buffer sont décalés d'un cran vers la gauche. La carte son prends cet échantillon et le met en forme à l'aide de ses mécanismes internes et de son horloge interne.

Tu vois parfaitement que le moment ou le CPU qui exécute le logiciel écrit dans la case 6 n'a aucun rapport avec le moment ou la carte son lit dans la case 1. Il faut juste que le CPU aille assez vite pour que le buffer ne soit jamais vide. Mais en aucuns cas il n'a besoin de le faire régulièrement, c'est ASYNCHRONE.

Note 1 : j'ai simplifié la représentation du fifo comme un truc qu'on rempli d'un côté et qu'on vide de l'autre. Dans la pratique ça ne se fait pas comme ça car si on veut décaler le contenu vers la gauche à chaque fois que la case 1 est lue, il fraudai faire une boucle pour parcourir le buffer et décaler chaque case à gauche. C'est inefficace, en général on fait avec deux pointeurs qui pointent sur quelle case (en informatique on dit une adresse) est la lecture et sur quelle case est l'écriture et on les fait "tourner" comme ceci : (les couleurs lecture / écriture sont inversée par rapport à mon schéma)



Note 2 : la carte, c'est un peu plus qu'un buffer, une horloge et un bus, elle a un microcontrôleur voir un microprocesseur et du code en mémoire morte. Il y a donc bien un programme qui rentre en jeu mais pas le soft de lecture.

Voilà, est-ce assez rigoureux pour toi ?

(02-18-2016, 03:01 AM)ThierryNK a écrit : Je n'ai jamais cherché à démontrer quoi que ce soit sur un forum, je fournis des documents et des mesures que j'ai trouvé intéressants, je rapporte mes propres expériences audio, ensuite à chacun d'en tirer ce qu'il veut. Comme je l'ai déjà dit dans un autre post, je n'aime pas les évangélisateurs, et je ne vais pas endosser ce rôle.

Tu fournis effectivement des documents mais ils se contredisent et tu refuses de discuter de leur contenu.
Procédé bien peu rigoureux et même je trouve assez malhonnête.

D'un côté tu me demandes d'argumenter rigoureusement (ce qui s'appelle démontrer), d'un autre tu me reproches de démontrer en utilisant au passage le terme péjoratif d'évangélisateur.
A ma connaissance, un évangélisateur ne démontre pas, il impose des croyances ce que tu fais assez bien je trouve sous couvert de fausse modestie.
En tous cas oui, on peut dire que je lute par la démonstration contre les idées reçues. J'essaie de convaincre par l'argumentation, je n'évangélise pas. Je l'ai d'ailleurs dit en toute transparence dès ma présentation sur ce forum.
Et si quelqu'un veut me contredire, il est bienvenu, je ne demande qu'à mieux comprendre. Mais qu'il le fasse en prenant un élément de mon raisonnement et en expliquant pourquoi il est faux. Pas en brandissant un article dont il refuse ensuite de débattre sous prétexte qu'il est écrit par je en sais quel gourou.

En restant au niveau de tes propos, moi ce sont les moralisateurs que je n'aime pas.

Concernant le dernier lien que tu as donné, je suis tout à fait en phase avec ce qu'il dit.
Le premier chapitre "Software induced jitter" ne fait aucunement référence à un quelconque "bon moment" pour envoyer les échantillons à la carte, il n'est pas question de latence. Il est, comme dans le 1er lien donné sur le fil JRiver - Niveau débutant, question uniquement de bruit généré par l'activité. Les deux articles se contredisent néanmoins puisque l'un dit que le pire c'est le DD (il faudrait d'ailleurs préciser car SSD et DD sont très différents point de vue parasites), l'autre dit que ce sont les accès RAM. Aucun des deux ne donne de chiffres donc de toutes façons, ils peuvent toujours brandir une chose ou une autre, ce n'est pas du tout étayé. Par ailleurs, pour réduire les émissions électromagnétiques, le soft n'est qu'un moyen très faible (sauf éventuellement la lecture depuis la mémoire qui élimine le DD), j'ai déjà expliqué que l'underclocking donnera de bien meilleurs résultats, on est sur une tout autre échelle. Un autre élément fort est d'avoir une carte son correcte, blindée (comme les xonar), ils n'en font pas mention, dommage.

Et pour finir je rappelle que l'article de jipi que tu as donné explique que pour 2€ on élimine le jitter à 100 fois moins que le seuil d'audibilité.

[surfman]

Re,

Perso, je tourne sous Audirvana, et je peux te dire que ces propos à propos d'integer mode, est tout à fait cohérent, après, je veux bien faire des tests entre forumeurs sur les players bit perfect afin de voir si le résultat est le même en fonction du player, je suis ouvert à toute écoute et reconnaîtra sur la place publique, ici même, que je me trompe ...

Marc

PS => D'slé, mais parlé de carte son est-ce exact ???, perso ma sortie est le dac, ok, il se comporte comme une carte son, après le bla bla informatique first in first out, le jitter etc, est-ce bien raisonnable, seul l'écoute compte ...

[MrLocoLuciano]

Le test auditif n'a pas valeur de démonstration malheureusement Marc...

Notre ami Morbius ne jure que par des démonstrations chiffrées.
Hors comme déjà dit :

(02-16-2016, 01:49 PM)MrLocoLuciano a écrit : la science avance grâce à des postulats, postulats qui sont parfois démontrés des 10aines d'années plus tard -> Einstein dernièrement avec les ondes gravitationnelles. Ce n'est pas car on ne le mesure pas que le phénomène n'existe pas. 

Je sais que la référence à Einstein ne t'a pas plus Morbius mais je recommence !
Un phénomène non mesuré, cela ne veut pas dire qu'il n'existe pas 

[0000]

(02-18-2016, 03:01 AM)ThierryNK a écrit : Un petit dernier pour la route: https://www.dropbox.com/s/p5njtp28f6fz2z...e.pdf?dl=0

Une petite remarque sur ce "Integer Mode" qui est simple à réaliser sous Linux.
Il me semble que c'est encore à cause d'un mauvais point de ce système propriétaire iOS, qui ne donne pas de choix aux utilisateurs et les force à utiliser un "mixer de son" (AppleCoreAudio). Sous Linux, on a des équivalents "Alsa Dmix" ou "PulseAudio" ..., mais un utilisateur peut décide facilement de ne pas passer par le mixer en mettant quelques lignes dans un fichier de config alsa, par exemple :

Code :

pcm.!default {
type hw
card 0
}

ctl.!default {
type hw          
card 0
}