A propos de jitter

[tcli]

Bonjour

Ces temps ci, je me pose des questions à propos d'interface digitales et donc forcement de jitter.
Il est réputé difficile à mesurer, mais peut-on, avec nos moyens du bord, en "voir" les effets ?

J'ai ressorti un vieil article (1992 ) :

J-test.pdf

(151.29 Kio) Téléchargé 123 fois

qui liste les différents types de jitter et surtout décrit un signal de test (Le J-test ) conçu spécifiquement pour détecter au mieux les effets du jitter.

Ce signal est l'addition d'un signal carré à Fs/4 à -3dbfs (ie: presque au max) avec un signal carré à Fs/192 oscillant entre 0 et -1 LSB (ie : très très faible).
Note : un signal carré à Fs/4 est en fait une sinusoïdale, car toutes ses harmoniques sont absentes, puisque supérieures à Fs/2. Mais si on regarde les échantillons cela ressemble à un signal carré ie :



Voici son spectre pour Fs=48Khz et 16bits :

jtest.png (10.06 Kio) Vu 1662 fois

On voit clairement le signal à -3dbFs à 48/4=12Khz, et le signal carré très faible avec sa fondamentale à 48Khz/192=250Hz à la limite des -96dbFs et ses harmoniques rapidement en dessous de -120dbFs.

Par la suite, on va s'intéresser à ce qui se passe autour du signal à Fs/4. Voyons ce que l'on peut espérer mesurer avec ma carte son de base (une focusrite Scarlett solo). Ici le spectre moyenné en rebouclage avec un signal à 12Khz :

focusscarlettesolo.png (12.73 Kio) Vu 1662 fois

C'est pas si mal (attention à l'échelle de fréquence : linéaire et +-3.5Khz autour de 12Khz), d'autant plus qu'à cause d'un niveau de sortie un peu faible, j'ai été obligé d'augmenter le niveau du préamp d'entrée, ce qui remonte un peu le plancher de bruit.

Passons aux choses sérieuses :
Faisons jouer le J-test par un PC sous daphile, sortie toslink vers un DAC Matrix mini puis liaison par coax entre le Matrix et le DCX2496 et mesure d'une sortie analogique par la focusrite.
Vous suivez ?
D'accord c'est un montage shadock, mais mon mini PC n'a qu'une sortie optique ou USB et le DCX qu'une entrée coax. C'est justement parce-que je cherche une solution que je fais ces tests.
Voici le résultat :

toscoax.png (19.73 Kio) Vu 1662 fois

Ah oui quand même ..
Les raies symétriques autour du signal à 12Khz sont typique du jitter et les 1ère sont quand même assez fortes et en plus il y en a beaucoup. De plus on voit un élargissement au pied du signal principal, signe de bruit de phase aléatoire.

1ère constatations rapides en donc sûrement fausses :
- En faisant n'importe quoi on arrive à avoir du jitter
- Même avec un carte son de base, avec le J-test, on peut "voir" les effets du jitter (j'ai pas dit mesurer ).
- L’ASRC en entré numérique du DCX2496, sensé réduire le jitter, fait très moyennement son travail

Essayons autre chose :
J-test depuis le PC sous daphile, sortie USB vers le Matrix puis liaison par coax entre le Matrix et le DCX2496 et mesure d'une sortie analogique par la focusrite :

USBCoax.png (20.72 Kio) Vu 1662 fois

Eh! c'est nettement mieux du point de vue raies parasites, par contre le bruit de phase aléatoire est plus important.

2ème constatations :
- Le toslink c'est le mal
- Le récepteur USB du Matrix à l'air plutôt bien, même si il n'est pas asynchrone.

Alors enfin , essayons plus drôle :
J-test depuis le PC sous daphile, sortie USB vers le Matrix, sortie analogique vers le DCX2496 et mesure d'une sortie analogique par la focusrite:

USBanalog.png (23.34 Kio) Vu 1662 fois

Consternation : Il n'y pratiquement plus de raies parasites , par contre le bruit de phase !!!

3ème constatations:
- J'ai dis que des bêtises ci-dessus
- l'USB pas asynchrone c'est le mal
- Le récepteur USB du Matrix est pas si bon que ça
- l'ASRC du DCX fait bien son travail pour ce qui est du bruit de phase aléatoire, moins pour les raies parasites.(il arrive à corriger celui amené par l'USB dans la 2ème configuration)

Conclusion:
- Qu'est ce qu'on peut s'amuser avec une carte son !
- Je vais éviter le toslink. C'est dommage, greffer une entré optique sur le DCX m'aurait couté moins de 10€
- Faut se méfier de l'USB.

En fait, la bonne solution contre le jitter est connue depuis bien longtemps : l'horloge du coté DAC qui est renvoyée à la source qui doit s'y conformer.
Cela a été fait depuis des dizaines d'années par certains constructeurs de lecteur CD, mais c'est aussi maintenant possible avec l'USB asynchrone.
Cela sera l'objet de la prochaine étape....

PS: Si vous voulez rire, je vous conseille cet article de stereophile de 2009:
https://www.stereophile.com/content/case-jitters
Ils ont passé au J-test plusieurs transport CD (dont des très cher). Leur mesures sont en 44Khz/16bits, mais c’est comparable. Si vous ne lisez pas l’Anglais, vous pouvez sauter l’intro et aller directement aux résultats.

[Misu]

Hello,
je suis pas du tout expert en systèmes numériques, mais pour moi le bruit de phase & le jitter c'est exactement la même chose, mais regardé soit en fréquentiel, soit en temporel.
J'ai plus l'habitude de regarder le bruit de phase. Quand je vois tes courbes, clairement niveau bruit de phase/jitter, c'est le dernier cas le pire.
Les rais symétriques autour du signal dans le premier cas me font pas mal penser à des "spurious tones" d'une PLL. Ca serait pas étonnant que ça vienne de l'ASRC. Et vu ta courbe, pour moi il réduit bien le jitter.
Mais bon, mes constatations sont vraiment à prendre avec des pincettes, je ne suis pas vraiment compétant dans ce domaine

[tcli]

Hello,
je suis pas du tout expert en systèmes numériques, mais pour moi le bruit de phase & le jitter c'est exactement la même chose, mais regardé soit en fréquentiel, soit en temporel.

Oui tu as raison, le jitter c'est du bruit de phase, mais je savais pas comment exprimer clairement la différence entre bruit de phase aléatoire qui élargi la base du spectre du signal de test ou celui qui est périodique et crée des raies latérales autour de la porteuse.

[gerardfma]

- Le toslink c'est le mal
- Je vais éviter le toslink. C'est dommage, greffer une entré optique sur le DCX m'aurait couté moins de 10€

Je partage cette conclusion.
Je suis à chaque fois horrifié quand je lis dans un post qu'une sortie optique est meilleure qu'une sortie coaxiale. C'est toute la différence entre la théorie et la pratique. Sur du haut de gamme, l'optique peut être meilleure mais sur la grande majorité des produits, il est bien plus facile d'implémenter une liaison coax de qualité qu'une liaison optique. Et si dans nos installation la distance est courte, alors vive le coax sans hésitation aucune

- Le récepteur USB du Matrix à l'air plutôt bien, même si il n'est pas asynchrone.
- l'USB pas asynchrone c'est le mal
- Le récepteur USB du Matrix est pas si bon que ça
Conclusion:[/b]
- Faut se méfier de l'USB.

En fait, la bonne solution contre le jitter est connue depuis bien longtemps : l'horloge du coté DAC qui est renvoyée à la source qui doit s'y conformer.
Cela a été fait depuis des dizaines d'années par certains constructeurs de lecteur CD, mais c'est aussi maintenant possible avec l'USB asynchrone.

Attention aux raccourcis. En mode asynchrone, le "device USB", dans notre cas le DAC, ne fournit pas l'horloge à la source, en tout cas pas au sens où la majorité des lecteurs comprennent le mot horloge.
Dans ce mode, l'émission des paquets audio est cadencée par le récepteur (le DAC) qui indique à l'émetteur (le PC) s'il est prêt à recevoir la suite du flux, ce flux étant constitué d'une suite de trames audio, contenant donc un certain nombre d'échantillons.
Ce n'est pas du tout comparable à l'implémentation dans un lecteur CD ou un transport, dans lequel le mécanisme vaut pour chaque échantillon, donc en théorie plus de jitter et pas de loupé d'échantillon.

En quoi cette différence est importante ?
Dans le fait que cadencer l'envoi du flux USB ne change en rien l'implémentation générale de l'interface USB qui de par les niveaux de priorités des couches et des pilotes au sein du système d'exploitation ne garantit en rien un parfait isochronisme et la certitude d'envoyer les trames audio dans le temps imparti afin que le récepteur ne soit pas en manque.
En d'autres termes, quand le récepteur indique à l'émetteur "ok pour envoyer la suite", rien ne prouve que le dit émetteur sera en capacité d'envoyer le bloc suivant de trames sans délai.

Un DAC USB Asynchrone n'est donc pas le DAC ultime, en tout cas pas s'il fonctionne avec le pilote natif de l'OS.
Si par contre il est livré avec son propre pilote, alors il est *possible* que ces problèmes soient *correctement* adressés.
Et avec un bon pilote, même un DAC Synchrone avec un bon ASRC pourra faire aussi bien qu'un Asynchrone.

Telles étaient nos conclusions il y a quelques années déjà, mais nul n'a la science infuse et j'attends impatiemment la suite de tes tests

[wakup2]

En pratique ou ce situe le seuil d'audibilité ?

[tcli]

Attention aux raccourcis.

C'est que j'aime pas faire long.

En mode asynchrone, le "device USB", dans notre cas le DAC, ne fournit pas l'horloge à la source, en tout cas pas au sens où la majorité des lecteurs comprennent le mot horloge.
Dans ce mode, l'émission des paquets audio est cadencée par le récepteur (le DAC) qui indique à l'émetteur (le PC) s'il est prêt à recevoir la suite du flux, ce flux étant constitué d'une suite de trames audio, contenant donc un certain nombre d'échantillons.

Effectivement

En quoi cette différence est importante ?
Dans le fait que cadencer l'envoi du flux USB ne change en rien l'implémentation générale de l'interface USB qui de par les niveaux de priorités des couches et des pilotes au sein du système d'exploitation ne garantit en rien un parfait isochronisme et la certitude d'envoyer les trames audio dans le temps imparti afin que le récepteur ne soit pas en manque.

En pratique ca ne change rien. Il suffit de buffériser assez et que la source soit suffisamment rapide pour "n'être jamais en manque" et dans ce cas c'est parfaitement équivalent à un mode synchrone de bout en bout avec horloge coté DAC.
Je sais bien qu'un kernel Linux n'est pas un kernel real time, mais, en fait, de nos jours, on s'en fout, car le PC avec son disque SSD a tellement plus de débit que le débit audio nécessaire, que même si le processeur part faire des courses entre deux échantillons, il aura le temps de revenir avant de traiter le suivant .
Ca m'étonnerait vraiment beaucoup qu'on soit régulièrement en famine du coté DAC avec un USB synchrone. Ca arrive peut être une fois de temps en temps, pas de quoi avoir une influence en continue sur l'écoute .
Si vraiment ca m’angoissait , je pourrais utiliser la version de daphile avec kernel rt (qui améliore les choses mais ne fait toujours pas de Linux un vrai kernel RT) et demander que chaque morceau soit chargé et verrouillé en mémoire avant d'être joué (l'option existe).
Même avec un lecteur CD et une horloge venant du DAC, tu ne peux assurer que tu n'auras pas de drop out. La lecture optique peut se louper et il faudra bien buffériser avant que le laser retrouve la piste. Bref c'est la même chose.
D'ailleurs , dans l'article de stereophile cité, le meilleur lecteur de l'époque (complètement hors de prix) lis le CD en x2 et bufférise beaucoup avant de fournir les échantillons au rythme de l'horloge du DAC. En gros , il dématérialise le CD en temps réel

Zut, j'ai été long.

[tcli]

En pratique ou ce situe le seuil d'audibilité ?

J'attendais la question
J'en sais rien, il y dans la littérature quelques indication, mais ca à l'air vague , comme toujours quand on commence à parler de ressenti.
J'ai pas vraiment la possibilité de changer rapidement de mode et donc encore moins de faire un ABX, mais ....
J'ai l'impression que j'arrive à entendre une différence entre les différente config. Surement une illusion.

[gerardfma]

Je sais bien qu'un kernel Linux n'est pas un kernel real time, mais, en fait, de nos jours, on s'en fout, car le PC avec son disque SSD a tellement plus de débit que le débit audio nécessaire, que même si le processeur part faire des courses entre deux échantillons, il aura le temps de revenir avant de traiter le suivant .

En théorie oui.
Mais j'ai appris à laisser la théorie de coté, et ce que nous avions étudié sur le cadencement USB audio "asynchrone / isochrone" est assez indépendant de ces paramètres de performance (vitesse CPU, disque SSD, USB 3.00, etc.).
Mais bon, en théorie, tu as raison.

D'ailleurs , dans l'article de stereophile cité, le meilleur lecteur de l'époque (complètement hors de prix) lis le CD en x2 et bufférise beaucoup avant de fournir les échantillons au rythme de l'horloge du DAC. En gros , il dématérialise le CD en temps réel

Méthode classique utilisée sur les lecteurs CD portables pour les rendre assez indifférents aux chocs, vibrations et autres aléas de transport.
Comme l'a dit sur un autre post un forumeur dont j'ai oublié le nom, on pourrait se demander pourquoi cette méthode n'a pas été implémentée de manière généralisée sur les lecteurs CD
Peut-être pour coller aux exigences des audiophiles ne jurant que par la méthode originelle de lecture ?

Zut, j'ai été long.

Oui, et du coup, j'ai surement loupé un échantillon sans m'en rendre compte

[tcli]

En théorie oui.
Mais j'ai appris à laisser la théorie de coté, et ce que nous avions étudié sur le cadencement USB audio "asynchrone / isochrone" est assez indépendant de ces paramètres de performance (vitesse CPU, disque SSD, USB 3.00, etc.).
Mais bon, en théorie, tu as raison.

Non, justement, tu as raison "en théorie" : il est toujours possible que le kernel , ayant autre chose à faire, ne délivre pas à temps les échantillons. Mais je dis, qu'"en pratique", avec les CPU et les disques d'aujourd'hui , il y a très peu de chance que cela arrive, sauf si le driver est mal fichu et ca m'étonnerait beaucoup.
Maintenant, si tu montres une trace, avec une version d'OS moderne, qui prouve le contraire, je l’accepterais volontiers.

j'attends impatiemment la suite de tes tests

Ca va prendre un peu de temps, je suis en discussion pour avoir une interface USB adaptée à mes besoins.

[JIM]

Intéressant, peux-tu mettre le fichier à dispo ?

[tcli]

Les voici à 44.1 et 48 khz :
https://tleconte.github.io/Jitter/Jtest48.wav
https://tleconte.github.io/Jitter/Jtest44..wav

ATTENTION : NE PAS JOUER CES FICHIERS WAV SUR DES ENCEINTES OU CASQUE.
ILS CONTIENNENT UN SIGNAL DE FORTE AMPLITUDE A HAUTE FREQUENCE CE QUI
EST PARFAIT POUR CASSER UN TWEETER

J'aurais prévenu

A noter que vu la définition du Jtest ces deux fichiers sont en fait identique. C'est seulement l'entête indiquant la fréquence d'échantillonnage qui diffère.
Je pourrais aussi en faire un 48Khz/24bits, mais j'ai peur de pas voir grand chose avec ma carte son de base.

[maxidcx]

salut
merci tcli d'avoir fait ce topic, ca remet bien en question l'importance du jitter et pas seulement coté DCX
en tappant "dcx2496 jitter" dans google on trouve aussi plein de bon truc à lire le soir dans le canapé quand waf a décidé de regarder un truc qui ressemble plus à un navet ou a une betterave crue qu'à une bonne émission.

pour ma part, j'ai 2 feedbacks concrets, mais subjectifs sur l'audibilité:
j'utilise régulièrement soit une source macbook donc liaison usb vers un dac, soit un oppo 93 équipé de la carte vanity qui bufferise la trame I2S dans une grosse fifo et la renvoie en coax spdif avec un VCXO de précision qui se corrige en fonction de la fifo.

déjà si on écoute la sortie toslink standard de l'oppo et la sortie coax de la vanity ben y a pas photo. avec le coax recloké c'est propre et les basses sont sèches, alors que le toslink on à juste envie d'arrêter la musique.

si ensuite on passe le même morceau (fichier wav) dans le macbook (audirvana+) et donc en USB async vers le DAC, ben c'est encore mieux et on à plus envie d'utilise le CD en coax... même recloké, (sauf pour les SACD ou la c'est vraiment plus pratique avec l'oppo)

ma conclusion perso, c'est qu'un dac doit avoir sa clock master propre et qu'on doit idéalement l'utiliser en USB asynchrone.
par ailleurs, pour avoir regardé les source et la doc USB-I2S de XMOS ben y a un buffer entre la tache I2S et la tache USB et je pense que si le computer est pas trop déconant alors on est au top.

concernant le DXC, l'entrée avec le CS8420 est pourrie. il faut que tu te fasses l'interface USB slave qui va bien, et que tu envisages de mettre une meilleur clock dans le DXC... (exemple miniclock de awdiy)

sinon concernant le JTEST j'arrive pas à comprendre ce que ce fichier apporte de plus dans la représentation FFT pour dépister du jitter en sortie de DAC, si quelqu'un a compris...

[wakup2]

Je me pose quand même quelques questions quand a l'audibilité d'un truc qui se passe a -90dB une fois en salle en condition réel, perso j'ai quelques doutes, faudrait déjà avoir une salle de compét avec un NR très bas.

[JIM]

Merci tcli,

Je vais essayer sur ma carte son bouclée mais je pense qu'il n'y aura pas grand chose à voir.
Il y a une sortie firewire via une carte pci propriétaire dans le PC et le rack en lui même.

3 options pour la clock, je prends celle du rack.

[tcli]

Je me pose quand même quelques questions quand a l'audibilité d'un truc qui se passe a -90dB une fois en salle en condition réel, perso j'ai quelques doutes, faudrait déjà avoir une salle de compét avec un NR très bas.

Oui c'est bien de se poser des questions.
Dans ma 1ère config shadock , les raies parasites les plus importantes sont à -70dbfs.
Si tu penses que c'est pas audible, alors ca sert à rein d'avoir 16bits, 12 suffisent.
Bon , je troll , c'est vrai que c'est surement limite d'un point de vue audition.