(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.Regardes bien mon schéma.
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.
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
To be and not to be, that is the answer.