Le Forum Indépendant de la Hifi et des Audiophiles

Tu utilises le volume sur le DAC ou sur ton ampli?

(02-18-2016, 01:40 AM)ThierryNK a écrit : [ -> ]Ta "démonstration" avec des bits est très peu convaincante quand on prend en compte que c'est un signal électrique à 5.6 MHz qui est généré en spdif pour du 16/44 et que c'est un comportement d'onde et non un comportement simplificateur de bits et de mots qu'il faut prendre en compte. Une modélisation numérique sans la modélisation électrique sous-jacente n'a aucune valeur.
Un seul buffer (celui d'arrivée dans le DAC par exemple) a un effet de latence  négligeable.  Pour l'accumulation de plusieurs buffers, ce n'est pas le cas.

Regardes bien mon schéma.
Je l'ai bien dessinée l'horloge et la mise en forme à 5.6 mhz. Le carré vert qui s'appelle "mise en forme du signal".
C'est bien ça qui transforme les bits en signal (ou onde si tu préfères). Tu as une flèche des bits qui rentrent, une autre flèche d'une horloge qui rentre et le tout donne ton signal à 5.6 mhz.

Je ne connais pas son fonctionnement détaillé mais une chose est sûr, le logiciel et le driver n'ont rien à voir là dedans, c'est interne à la carte son.

La gestion des interruptions dans un OS, c'est genre 100 à 1000 fois par secondes, ils ne peuvent pas générer un signal à x mhz, ni à aucune fréquence d'ailleurs, ce n'est pas prévu pour, c'est bien trop irrégulier et lent. C'est juste prévu pour que l'oeil humain voie 2 programment qui "avancent" en même temps de manière fluide sur un seul processeur.

Le CPU, le driver et le logiciels ne "voient" même pas le chip de mise en forme, ils ne "savent" pas à quoi ressemble un signal PCM 16/44, ils ne voient qu'un buffer, c'est à dire une mémoire dans laquelle ils écrivent via le driver.
La seule chose qui se passe c'est que quand il y a de la place dans le buffer, il y a une interruption qui va arrêter les processus en cours sur le CPU pour lui demander d'envoyer un nouveau groupe de samples à la carte via un appel à une fonction du driver.

(02-18-2016, 01:40 AM)ThierryNK a écrit : [ -> ]Quant à:
N'importe quelle latence (aléatoire) entre top horloge et action est source de jitter.

Si tu trouves ça "non rigoureux" alors que c'est d'une banalité extrême et général, non lié directement à l'audio, je n'y peux pas grand chose.
Si tu mets 10 coureurs  strictement identiques en terme de vitesse et d'acceleration sur une ligne de départ, mais que leur temps de réaction (latence) au coup ce sifflet de départ n'est pas le même, ils se seront plus jamais alignés (jitter) pendant la course.

C'est non rigoureux parce que tu ne dis pas quand ils partent, ce qu'ils représentent, ce que représente la ligne d'arrivée et tu ne dis pas un jitter sur quoi.
Si tu le faisais tu verrais que ce que tu dis est complètement faux dans le cas d'envoi de samples à une carte son car après c'est a-syn-chrone. Dans la carte son, pas dans le dac, je parle depuis le début d'un signal envoyé sur Spdif, pas d'un USB asynch sur lequel tu a déjà admis que le soft ne génère pas de jitter.

Pour reprendre ton analogie, si les coureurs sont les échantillons, on s'en fout complètement qu'ils soient alignés. D'ailleurs, ils ne doivent pas l'être.
Ils sont envoyés par paquets, tout le monde dans un paquet va à la même vitesse, chaque paquet est envoyé à intervalle pas très régulier et 1 par 1, pas tous en même temps.
Ils ne partent donc pas en vélo, ils partent en bus et il n'y a qu'un bus à partir à la fois.
Chacun a sa place dans le bus, personne ne se mélange dans le bus, tout le monde monte et descend du bus dans un ordre prédéfini.

Etape 1 : une interruption dit au CPU "tu peux envoyer un bus (un bloc d'échantillon) car le buffer est vide"
Etape 2 : un premier bus part (appel au driver pour passer un paquet d'échantillons à la carte son)
Etape 3 : le bus arrive en mettant un certain temps, les coureurs descendent sans se mélanger, et ils vont faire la queue 1 par 1 en gardant bien le bon ordre (la queue, c'est le buffer)

On attend la prochaine interruption (qui se produira lorsque la queue est assez vide) et le logiciel/driver/CPU renverront un autre bus avec les échantillons suivants.

Pendant ce temps, en parallèele et à une fréquence complètement décorrélée, sur la carte son, de manière complètement indépendante du système CPU /logiciel/driver (asynchrone) un vilain aspirateur (ce que j'ai appelé "mise en forme du signal") aspire 1 par 1 a intervalle très régulier (grâce à sa propre horloge) le premier gars de la file.
Chaque gars aspiré est broyé par cet aspirateur qui les transforme en signal 5.6mhz.

Voilà, dire que le logiciel/CPU/Driver peut induire du jitter par des délais, c'est dire qu'il est hyper important que les bus partent super à l'heure, et qu'au moindre décalage, ça se retrouvera sur le signal 5.6 mhz.

Ben non, c'est archi faux. Le seul impact d'une latence sur ces bus, c'est de remplir plus ou moins bien la file, aucun impact tant qu'elle n'est pas vide. La seule source de jitter générée par l'ordi se produit dans l'aspirateur c'est à dire sur la carte son et donc en dehors de tout contrôle du logiciel/driver/cpu.

Regarde la gif que j'ai donné. On peut parfaitement avoir la flèche rouge qui pompe les caractères de manière ultra régulière, même si la flèche verte écrit de manière irrégulière. La seul contrainte de la flèche verte c'est d'être en avance sur la rouge (le buffer doit pas être vide).

C'est tellement évident, je sais pas comment l'expliquer plus simplement que ça.

Bémol : de par leur activité, le logiciel/CPU peuvent solliciter plus ou moins certains composants de l'ordi, générant ainsi des perturbation électromagnétiques que le système de mise en forme du signal (l'aspirateur super régulier) peut choper et ça peut donner du jitter en théorie, c'est l’objet du dernier article que tu as fourni, reste à creuser ces deux points :
 - quels sont les ordres de grandeur de ces parasites ? Impact possible ?
 - le logiciel est-il réellement l'élément le plus déterminant là dedans ? J'ai donne d'autres pistes qui me semblent bien plus dimentionnantes.

Mais ça n'a rien à voir avec le moment auquel le CPU passera les échantillons à la carte, ça on s'en fout complètement du point de vue jitter sur le signal PCM qui sorts du SPDIf

(02-19-2016, 12:08 AM)ThierryNK a écrit : [ -> ]Tu utilises le volume sur le DAC ou sur ton ampli?

Audio volume settings page 32 

MBIT+
Pour ma part je ne m'en sert pas et laisse le volume à zéro dB.
La gestion du dithering n'est pas au top selon moi sur çe logiciel.

Je préfère donc utiliser l'ampli pour gérer le volume.
(Le préampli du DAC est by passé)

Bonsoir,
Je ne comprends absolument pas quel est le but des démonstrations précédentes !
D'ailleurs, sont elles réellement concluantes ?
Quelle est la finalité ou l'utiliité pour "l'Audiophile moyen" ?

(02-18-2016, 06:44 PM)MrLocoLuciano a écrit : [ -> ]C'est autant à toi de nous prouver que cela n'existe pas qu'à nous de te démontrer que cela existe. Tu ne m'as pas prouvé jusqu'à présent que ces phénomènes n'ont pas d'impacts avec les différentes démonstrations présentées.

Par respect, je ne reprendrai pas ta dernière phrase...

Désolé de m'être emporté mais si tu veux éviter ça, ne parle pas à la place des autres surtout en déformant par des approximations.

Ne pas croire en l'écoute et ne pas croire en l'écoute subjective, c'est très différent.
Effectivement, je fais des écoutes subjectives comme tout le monde et j’entends des choses mais j'ai fait l'essai de comparer ces écoutes à des écoutes ABX dans les strictes mêmes conditions. Et j'ai constaté, comme la plupart des CR de tests ABX que j'ai trouvés sur le net qu'il y a un monde entre ces deux types d'écoute. J'en conclus à titre personnel  que :
 - je ne me fie pas à mes écoutes subjectives pour tirer des conclusions (des pistes oui, mais pas des conclusions)
 - lorsque quelqu’un parle du résultat d'une écoute subjective, je pense qu'il doit préciser que c'est subjectif et ne pas brandir ce qu'il a "entendu" comme une vérité absolue. J'ai lu ici de nombreuses foi : si j'entends une différence en écoute subjective, c'est qu'il y en a une même si aucune théorie ou mesure ne vient corroborer ce que j'ai entendu.

C'est tout ce que je dis à ce sujet.

Je n'ai jamais tenté (en donc encore moins prétendu) démontrer que les perturbations EM de l'activité d'un ordi ne peuvent impacter le jitter. Je dis même le contraire, à savoir que c'est parfaitement démontré du point de vue théorique par le dernier article donné, reste à savoir :
 - si c'est significatif avec des mesures ce que ne font pas ces articles.
 - si le logiciel est vraiment al meilleur façon de luter contre ces perturbations

Tu peux reprendre ma dernière phrase, je n'ai aucun problème avec ça.
Je constate que je suis obligé de me répéter, que mes posts sont lus en diagonale et que c'est pénible de devoir se répéter.
Aucune animosité là dedans, encore désolé si ça a été perçu comme ça mais SVP, lisez et comprenez avant de répondre.

---

(02-19-2016, 12:29 AM)Vicento a écrit : [ -> ]Bonsoir,
Je ne comprends absolument pas quel est le but des démonstrations précédentes !
D'ailleurs, sont elles réellement concluantes ?
Quelle est la finalité ou l'utiliité pour "l'Audiophile moyen" ?

L'objectif est de démonter que le soft n'a aucun impact sur le jitter, du moins dans sa capacité à envoyer les échantillons au "bon moment".
Et comme, dans une solution bit perfect, le jitter est le seul truc qui peut dégrader le son, il n'est donc pas nécessaire d'investir dans un ordi puissant pour avoir un son de qualité maximale
Rien que ça, ça fait des centaine d'€ d'économies (l'ordi que j'ai donné en exemple est dans les 300€, un ordi "audiophile" du marché dépasse souvent les 1000€. Le sujet du topic est : qu'est-ce qu'un ordi audiophile ?

De plus, les solutions qui font décoder le flac dans le NAS à la place du PC, ou le fait de préférer des WAV aux flacs ou utiliser des trucs comme JPlay (choix qui complexifient la mise en oeuvre et augmentent potentiellement le coût) ne vont jouer que sur les perturbations électromagnétiques qu'il faudrait d'abord chiffrer pour voir leur impact.

Et pour l'instant, je en vois rien de probant à ce niveau, ce point reste à creuser avec des mesures. Je suis tout ouvert, j'ai de gros doutes mais aucune conclusion pour le moment.

De plus, j'ai donné des pistes qui vont énormément baisser ces perturbations comme d'undeclocker et sous volter le CPU et la RAM (donc le bus mémoire). Très simple, ultra green et sur le papier beaucoup plus efficace que de gagner 1% d’utilisation CPU.

Bonsoir Morbius 

(02-19-2016, 12:17 AM)Morbius a écrit : [ -> ]Regardes bien mon schéma.
Je l'ai bien dessinée l'horloge et la mise en forme à 5.6 mhz. Le carré vert qui s'appelle "mise en forme du signal".
C'est bien ça qui transforme les bits en signal (ou onde si tu préfères). Tu as une flèche des bits qui rentrent, une autre flèche d'une horloge qui rentre et le tout donne ton signal à 5.6 mhz.

Je ne connais pas son fonctionnement détaillé mais une chose est sûr, le logiciel et le driver n'ont rien à voir là dedans, c'est interne à la carte son.

La gestion des interruptions dans un OS, c'est genre 100 à 1000 fois par secondes, ils ne peuvent pas générer un signal à x mhz, ni à aucune fréquence d'ailleurs, ce n'est pas prévu pour, c'est bien trop irrégulier et lent. C'est juste prévu pour que l'oeil humain voie 2 programment qui "avancent" en même temps de manière fluide sur un seul processeur.

Le CPU, le driver et le logiciels ne "voient" même pas le chip de mise en forme, ils ne "savent" pas à quoi ressemble un signal PCM 16/44, ils ne voient qu'un buffer, c'est à dire une mémoire dans laquelle ils écrivent via le driver.
La seule chose qui se passe c'est que quand il y a de la place dans le buffer, il y a une interruption qui va arrêter les processus en cours sur le CPU pour lui demander d'envoyer un nouveau groupe de samples à la carte via un appel à une fonction du driver.

On n'écrit pas un signal USB ou Spdif. On le créé en temps réel.
C'est de la création EN TEMPS REEL de ce signal de 5.6 MHz, de manière continue en spdif, par "bouffées" en USB qu'il s'agit. 

(02-19-2016, 12:17 AM)Morbius a écrit : [ -> ]

(02-18-2016, 01:40 AM)ThierryNK a écrit : [ -> ]Quant à:
N'importe quelle latence (aléatoire) entre top horloge et action est source de jitter.

Si tu trouves ça "non rigoureux" alors que c'est d'une banalité extrême et général, non lié directement à l'audio, je n'y peux pas grand chose.
Si tu mets 10 coureurs  strictement identiques en terme de vitesse et d'acceleration sur une ligne de départ, mais que leur temps de réaction (latence) au coup ce sifflet de départ n'est pas le même, ils se seront plus jamais alignés (jitter) pendant la course.

C'est non rigoureux parce que tu ne dis pas quand ils partent, ce qu'ils représentent, ce que représente la ligne d'arrivée et tu ne dis pas un jitter sur quoi.

Là, en toute amitié, tu déconnes. Je ne faisais qu'illustrer, hors audio,  ce qu'était un jitter lié à la latence d'un buffer.

Les coureurs, il partent au coup de sifflet, c'est écrit 

Tu peux faire partir les coureurs tous ensemble au coup de sifflet  et mesurer les écarts entre eux à l'arrivée, ou bien les faire partir 1 par 1 toutes les secondes et mesurer les écarts à l'arrivée par rapport à la repartition "exacte" toutes les secondes. C'est pareil. 

Une donnée (coureur) à un "mauvais" moment est strictement identique à un jitter. Il n'y a pas que les dérives d'horloge qui en provoque, les données pas au bon moment avec une horloge "parfaite" aussi. 

...ou bien des données que l'on doit traiter en temps réel pour fabriquer un signal électrique de plusieurs Mega Hz (j'écris explicitement Mega au cas où) qui  proviennent d'un processus impliquant des tas de buffers, d'interruptions ou de priorités de threads.

Même pas le moindre petit doute avec les mots clés "temps réel" "Mega Hz" "données au bon moment"? 

Amitiés

Morbius,
Je ne comprend pas bien ton discours.
Si un logiciel "bit perfect" + un DAC asynchrone suffisait, il y a longtemps qu'on le saurait, non ?

Il existe un forum apellé computer Audiophile avec des milliers de pages sur le sujet.
La dernière solution à la mode est le Sonore Signature rendu (SSR)
Tu connais ?

(02-19-2016, 01:40 AM)ThierryNK a écrit : [ -> ]On n'écrit pas un signal USB ou Spdif. On le créé en temps réel.
C'est de la création EN TEMPS REEL de ce signal de 5.6 MHz, de manière continue en spdif, par "bouffées" en USB qu'il s'agit. 

Non non non et non.
Archi faux sur toute la ligne.
C'est quoi que tu comprends pas dans le mot "asynchrone"  ou dans le mot "buffer" ?

C'est la dernière fois que j'explique.

Il y a deux hardware qui travaillent en parallèle chacun à sa propre fréquence.
Dans tous tes raisonnement, tu n'en cites qu'un, tu es donc déjà faux sur le point de départ, à savoir le hardware dont tu prétends décrire le fonctionnement.
Il y a le processeur et la carte son. (laissons de côté l'USB pour un moment).

Le processeur central écrit les échantillons dans de la mémoire, un buffer à un rythme qui n'a aucune importance tant que le buffer n'est pas vide.
Il faut que tu comprennes que cette mémoire tampon sert "d'amortisseur" entre les deux et que chacun travaille à sa propre fréquence avec ses propres horloges.
Un processeur x64 ne sait absolument pas générer un signal spdif. Je te l'ai déjà dit, sinon pas besoin de carte son pour avoir une sortie spdif sur un PC. Hors c'est pas le cas.

La carte son lit ce qui est dans le buffer à sa propre vitesse, avec son propre quartz d'horloge pour générer en temps réel un signal spdif.
Et c'est la régularité de cette vitesse qui fera ou pas du jitter.
Et la carte son fait ce travail indépendamment du logiciel qui lui fourni ces échantillons.
Le logiciel n'ayant aucun rôle à ce niveau il n'a pas d'impact (sauf pour les parasites déjà expliqués en long en large et en travers)

---

(02-19-2016, 01:40 AM)ThierryNK a écrit : [ -> ]Une donnée (coureur) à un "mauvais" moment est strictement identique à un jitter.

Non ce n’est pas identique à un jitter parce que notre coureur ne court pas vers la sortie spdif, il court vers une zone mémoire dans laquelle il va poireauter, faire la queue, en attendant son tour.

(02-19-2016, 02:04 AM)Morbius a écrit : [ -> ]

(02-19-2016, 01:40 AM)ThierryNK a écrit : [ -> ]On n'écrit pas un signal USB ou Spdif. On le créé en temps réel.
C'est de la création EN TEMPS REEL de ce signal de 5.6 MHz, de manière continue en spdif, par "bouffées" en USB qu'il s'agit. 

Non non non et non.
Archi faux sur toute la ligne.
C'est quoi que tu comprends pas dans le mot "asynchrone"  ou dans le mot "buffer" ?
...

Amusant, heureusement que j'en ai vu d'autres 

Il y a un premier énorme "buffer" qui est la piste elle même stockée sur un disque. 

Ensuite, bufferisation, asynchronicité, tout ce que tu veux. 

En sortie spdif, il y a un flux numérique sous la forme d'un courant à 5.6 MHz. Ce courant à 5.6 MHz ne souffre aucune interruption sinon perte de synchronisation entre emetteur et récepteur. 

J'ai écrit "création" du flux spdif et non gestion des données qui servent à le créer. Création du COURANT ELECTRIQUE SPDIF, et ce courant électrique il doit être  à 5.6 MHz quoi qu'il arrive et créé au fil de l'eau. 

Je parle électricité quand tu veux te restreindre aux données. 

Pour le jitter de latence, et mes coureurs, réfère toi à n'importe quel cours universitaire sur les télécommunications et voix sur IP. Après tout, je ne suis pas rémunéré ici 

Amitiés

(02-19-2016, 02:30 AM)ThierryNK a écrit : [ -> ]J'ai écrit "création" du flux spdif et non gestion des données qui servent à le créer. Création du COURANT ELECTRIQUE SPDIF, et ce courant électrique il doit être  à 5.6 MHz quoi qu'il arrive et créé au fil de l'eau. 

Je parle électricité quand tu veux te restreindre aux données.

Tu réponds toujours à côté.
Oui, il a d'autres buffers en amont de celui de la carte son, et alors ?

Et je te parle bien de courant électrique, je ne restreint pas aux données.

Ce qui est restreint aux données, c'est le travail du CPU et du logiciel.

La génération du courant qui sort de la carte sdpif, c'est après le buffer, par ce que j'ai appelé "mise en forme du signal".
3ieme fois que je te le dis + 1 dessin.

Bon j'arrête là, tu veux pas comprendre, tu veux pas comprendre.