(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.
To be and not to be, that is the answer.