Modérateurs: Staff Univers Casques, Staff Haute-Fidélité, Staff Juridique • Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 14 invités

Discussions sur le matériel Haute-Fidélité

C'est quoi un Jitter et ça sert à quoi ?

Message » 16 Juin 2009 20:04

syber a écrit:
corsario a écrit:
syber a écrit:Merci Corsario,

Mais tu sais moi, tant que j'ai pas expérimenté un truc j'ai du mal à en saisir la portée ... :D


Bon ben par exemple quand tu écoutes la musique chez toi, bon ben y a du jitter, et puis quand tu viens écouter la musique chez moi, bon ben, ya plus de jitter, c'est propre. Voilà concrètement :mdr:



J'ai pour principe de ne jamais répondre sur les filières des amateurs crédules et béats d'enceintes truc et d'ampli bidules Image... ce serait trop facile pour moi ! Image


j'aime beaucoup ton smiley :mdr:

Mais bon sinon, pour le jitter, les enceintes et les amplis ne font rien à l'affaire : on est déjà dans l'analogique là.

C'est la source qui fait le bien et le mal pour ce qui concerne le jitter (et en l'occurence dans ma boutade au dessus je parlais donc de lecture sur mon PC. Mais c'était de la pure mauvaise foi car on voit sur les graphes au dessus que des platines conventionnelles peuvent aussi être excellentissimes en manière de jitter; Et si ça se trouve mon PC serait à la ramasse si on mesurait son jitter (Naaaannn, je rigole.... )

syber a écrit:On m'a fait comprendre qu'il fallait que j'arrête de parler de scène sonore en trois dimensions, ça en vexait quelque z'uns qui ne comprenaient pas de quoi je parlais 8) :mdr:


la scène sonore en 3 dimension : voilà typiquement quelque chose qui est probablement fortement altéré par un jitter mal maîtrisé je pense.
corsario
 
Messages: 2218
Inscription: 01 Fév 2005 18:39
Localisation: Paris
  • offline

Annonce

Message par Google » 16 Juin 2009 20:04

Publicite

 
Encart supprimé pour les membres HCFR

Message » 16 Juin 2009 20:11

Je comrpends très bien ce que tu veux dire.

C'est juste que comme tu as fait l'effort de faire des messages techniques et clairs, je me permet d'etre un peu tatillon ;) .

En informatique, tu as une horloge, dans toute transmission numérique, tu as une fréquence, donc une horloge. Le transfert de fichier du PC vers le DD externe, certe le port USB ne transmet pas le signal d'horloge, mais à un moment, ton PC fait coucou au disque et lui dit "tien, moi je fonctionne à telle fréquence... par exemple 250 MHz, mon pote, tu as interet a te caller la dessus, sinon on va pas s'entendre". Et voilà. Si à un moment ca part en vrille, pas grave, on est asynchrone, le disque dur dit au PC qu'il est à la ramasse et le PC lui renvoi les morceaux que le disque n'a pas eu le temps de traiter.
Pour les transferts par le réseau vers HCFR, c'est encore pire car il y a des couches et des couches de protocoles qui font qu'avant que le serveur HCFR comprenne que j'ai tapé "ABC", il y a 15 serveurs qui se sont relayés l'info, certains étaient à l'ouest et ont demandé que l'info soit renvoyée, d'autres l'ont mise en attente le temps de finir un truc plus important qu'ils avaient à faire etc...

Pour quelques petites explications en plus, j'ai trouvé ça (c'est le moins mauvais que j'ai pu trouver - lire au moins le §1. Description) :
http://wapedia.mobi/fr/Bus_informatique
guest
 
Messages: 23526
Inscription: 15 Fév 2001 2:00
  • offline

Message » 16 Juin 2009 20:11

En fait de Jitter, je crois avoir remarqué que cela préoccupe principalement les amateurs de DAC reliès en SPDIF.

Pour ma part, j'ai un lecteur intégré et un PC relié en WiFi sur une borne AE, je crois bien que statistiquement je suis dans la zone la moins risquée, si j'ai bien suivi ces filières.

la scène sonore en 3 dimension : voilà typiquement quelque chose qui est probablement fortement altéré par un jitter mal maîtrisé je pense.


C'est une bonne raison de faire ABX 5 chez moi. :D
syber
 
Messages: 10301
Inscription: 30 Juil 2005 15:07
  • offline

Message » 16 Juin 2009 20:14

corsario a écrit:
loloboy a écrit:Dans un cas synchrone / temps-réel, le buffer souffre de son problème théorique de débordement ou de pénurie. Néanmoins, j'ai toujours du mal avec cette théorie car, selon moi, une erreur d'horloge est une variation aléatoire dont la moyenne doit être négligeable (ie : on devrait avoir autant de périodes "un peu plus courtes" que de périodes "un peu plus longues").


Ah mais ce n'est pas ça. Ca ne déborde pas, heureusement. Sinon ça serait grave. C'est effectivement une variation aléatoire.
Le problème c'est que ces petites variations en x se modulent avec le signal en y pour le rendre moins précis, moins impactant, rajouter un peu de bruit de fond et même rajouter en plus de la modulation de fréquence. Mais ça ne fait pas des blancs, ni des trous, ni rien. Sinon ça serait vraiment grave. C'est subtil. C'est pour ça que c'est pernicieux.

C'est bien pour ca que je ne comprends pas pouvquoi le buffer d'entrée n'est en général pas considéré comme une bonne solution.
guest
 
Messages: 23526
Inscription: 15 Fév 2001 2:00
  • offline

Message » 16 Juin 2009 21:48

loloboy a écrit:Je comrpends très bien ce que tu veux dire.

C'est juste que comme tu as fait l'effort de faire des messages techniques et clairs, je me permet d'etre un peu tatillon ;) .

En informatique, tu as une horloge, dans toute transmission numérique, tu as une fréquence, donc une horloge. Le transfert de fichier du PC vers le DD externe, certe le port USB ne transmet pas le signal d'horloge, mais à un moment, ton PC fait coucou au disque et lui dit "tien, moi je fonctionne à telle fréquence... par exemple 250 MHz, mon pote, tu as interet a te caller la dessus, sinon on va pas s'entendre". Et voilà. Si à un moment ca part en vrille, pas grave, on est asynchrone, le disque dur dit au PC qu'il est à la ramasse et le PC lui renvoi les morceaux que le disque n'a pas eu le temps de traiter.
Pour les transferts par le réseau vers HCFR, c'est encore pire car il y a des couches et des couches de protocoles qui font qu'avant que le serveur HCFR comprenne que j'ai tapé "ABC", il y a 15 serveurs qui se sont relayés l'info, certains étaient à l'ouest et ont demandé que l'info soit renvoyée, d'autres l'ont mise en attente le temps de finir un truc plus important qu'ils avaient à faire etc...


Je suis totalement d'accord. Mais le résultat c'est que jitter ou pas, à la fin on à "ABC" qui arrive à bon port, même si ça a été compliqué : les données informatiques ne sont pas altérées par le jitter (même si elles en subissent).

Si ça avait été un flux audio-numérique avec conversion analogique on aurait pu avoir à la fin "bABCc" à la place du "ABC" envoyé : le jitter altère le flux audio-numérique et surtout le résultat final analogique

*En toute rigueur j'aurais du faire un dessin du "ABC" déformé (puisqu'on est censé être dans le domaine analogique), mais bon, c'était pas facile...

loloboy a écrit:
corsario a écrit:
loloboy a écrit:Dans un cas synchrone / temps-réel, le buffer souffre de son problème théorique de débordement ou de pénurie. Néanmoins, j'ai toujours du mal avec cette théorie car, selon moi, une erreur d'horloge est une variation aléatoire dont la moyenne doit être négligeable (ie : on devrait avoir autant de périodes "un peu plus courtes" que de périodes "un peu plus longues").


Ah mais ce n'est pas ça. Ca ne déborde pas, heureusement. Sinon ça serait grave. C'est effectivement une variation aléatoire.
Le problème c'est que ces petites variations en x se modulent avec le signal en y pour le rendre moins précis, moins impactant, rajouter un peu de bruit de fond et même rajouter en plus de la modulation de fréquence. Mais ça ne fait pas des blancs, ni des trous, ni rien. Sinon ça serait vraiment grave. C'est subtil. C'est pour ça que c'est pernicieux.

C'est bien pour ca que je ne comprends pas pouvquoi le buffer d'entrée n'est en général pas considéré comme une bonne solution.


oui ça me semble une bonne solution à moi aussi.
corsario
 
Messages: 2218
Inscription: 01 Fév 2005 18:39
Localisation: Paris
  • offline

Message » 16 Juin 2009 22:02

Corsario toi qui a potasse le truc,
*une clock externe qui synchronise emetteur et receveur va t il resoudre le pb du jitter ou la derive possible de transmission de cette clock aux deux fait qu on reintroduit du jitter ?
la solution d un petit buffer qui stocke les 1 et les 0 et une clock de luxe ds le dac permet de parfaitement 'temporiser' le decodage est elle meilleure ?
Bref, y a t il des solutions au pb du jitter ?
d ailleurs pkoi on arrive a faire des drives+dac a jiiter limites et que nos solutions informatiques semblent ne pas arriver a la hauteur de ces mecaniques ?

Edit : sorry pour le buffer, j avais pas integre le post du dessus :oops:
Dernière édition par JG Naum le 16 Juin 2009 22:04, édité 1 fois.
Hi-fi : nas Qnap TS221, Transporter, Classé 2200i, Vivid Audio, Rel
HC : Pio KRP 500A, Vivid, Scandyna Minipod & Cinepod, Pana BDT 270, Yamaha Rxa 1040
Avatar de l’utilisateur
JG Naum
Staff Œuvres
Staff Œuvres
 
Messages: 5351
Inscription: 12 Mar 2005 20:08
Localisation: Paris

Message » 16 Juin 2009 22:03

loloboy a écrit:C'est bien pour ca que je ne comprends pas pouvquoi le buffer d'entrée n'est en général pas considéré comme une bonne solution.


Jusqu´ici, j´ai plutôt lu l´inverse : le buffer en entrée etant plutôt tenu pour être une solution efficace. Sur HCFR et ailleurs.
Adhérez au club de ceux qui ont la "méfiance infuse", après avoir adhéré à l'association...
haskil
Membre HCFR
Membre HCFR
 
Messages: 49552
Inscription: 06 Déc 2001 2:00
Localisation: Haute Normandie et Paris
  • offline

Message » 16 Juin 2009 22:04

Bonjour Corsario,

corsario a écrit:Un ordre de grandeur : "digital audio theory predicts that jitter needs to be below 100ps for 16-bit (ie, CD) audio to be reproduced without degradation—and 24-bit audio requires jitter to be below 10ps!"


Il y a un problème avec ces chiffres. La résolution du 24 bits est 256 fois supérieure à celle du 16 bits. Le jitter considéré étant petit par rapport à la période d'échantillonnage, on peut considérer que la perturbation est linéaire. Donc si 100ps sont requises pour 16 bits, 100/256 = 0.39 ps sont requises pour du 24 bits. Et encore moins si la fréquence d'échantillonnage est supérieure.

On peut calculer la limite absolue. L'erreur maximale est obtenue aux zéros d'une sinusoïde de pleine amplitude et de fréquence maximale. La pente de la fonction sinus est alors de 1, de sorte qu'un décalage de pi/2 radians conduirait au premier ordre à un écart en amplitude de pi/2 fois l'amplitude max.
Pour le CD, la période de la sinusoïde sera de 1/22050 = 45.4 µs. Les pi/2 valent un quart de période, soit 11.3 µs.
On cherche le décalage conduisant à la plus petite erreur mesurable, soit 32768 fois moins. Ce qui donne 346 ps.
Pour du 24 bits 192 kHz, les mêmes calculs conduisent à 0.31 ps.

Tout cela est un exercice purement intellectuel. Dans le dernier cas, cela représente un bruit de -144 dB ! En-dessous de l'agitation moléculaire de l'air ou de l'agitation thermique des semiconducteurs qui véhiculent le signal.

corsario a écrit:Figure 1 : signal test = une sinusoide autour de 11.025kHz avec des petites modulations (en rouge) pour embêter les platines


En rouge, ce sont les échantillons. Les petites modulations sont invisibles sur la figure. Ce sont des transitions d'une amplitude élémentaire, espacées toutes les 48 périodes.

corsario a écrit:Un truc que je n'ai pas compris c'est pourquoi dans la figure 2 le 16 bit arrive à -150 dB alors que dans la figure 3 on nous dit que le CD (16 bit) ne peut pas avoir un bruit de fond inférieur à -132 dB.


Ce n'est pas du 16 bits, mais du 24 bits. C'est le nouvel appareil de mesure de John Atkinson.

corsario a écrit:Ce qu'il faut garder en tête en regardant les résultats pour les quelques platines suivantes est qu'il faut arriver à reproduire la figure 2. Si on y arrive pas mais que le bruit est en dessous du niveau du CD, ce n'est pas si grave. Mais si on dépasse le bruit de fond du CD (-132 dB), là c'est un peu la cata quand même.


N'exagérons rien. Rappelle-toi notre test sur le 24 bits, et les conditions d'écoute invraisemblables qu'il nous a fallu utiliser pour entendre un bruit de -96 dB. On parle ici de quelque chose de 38 dB en-dessous !
Cependant, ce n'est pas le niveau des harmoniques, que nous devons comparer à notre -96 dB, mais l'amplitude de leur somme.
Par construction, la somme des harmoniques du signal original pur est de -96 dB, puisque c'est une fréquence dont l'amplitude crête à crête est de 1 niveau numérique élémentaire.
Par contre, l'étendue en fréquence des parasites produits par les lecteurs est très différente, et on ne peut pas déterminer leur niveau total en se basant simplement sur les spectres obtenus. Elle peut être inférieure ou supérieure, indépendemment du fait que son graphe dépasse ou non celui des harmoniques du signal original.

corsario a écrit:Est-ce que c'est audible je ne sais pas, mais j'ai tendance à penser que dans le cas du McIntosh et du Pioneer, oui !


Je ne sais pas non plus. J'ai tendance à penser que pour la Pioneer non, et pour la McIntosh, je ne sais vraiment pas. L'amplitude indiquée, de -85 dB, est audible seule, mais étant donné qu'elle n'apparait qu'au voisinage immédiat d'une fréquence 85 dB plus forte, elle sera complétement masquée par cette dernière.
Mais d'un autre côté, peut-être que c'est audible non sous forme de signal indépendant, mais comme variation de la fréquence du signal principal.
Pio2001
 
Messages: 5904
Inscription: 07 Oct 2003 12:50
Localisation: Neuville-sur-Saône
  • offline

Message » 16 Juin 2009 22:19

JG Naum a écrit:Corsario toi qui a potasse le truc,
*une clock externe qui synchronise emetteur et receveur va t il resoudre le pb du jitter ou la derive possible de transmission de cette clock aux deux fait qu on reintroduit du jitter ?
la solution d un petit buffer qui stocke les 1 et les 0 et une clock de luxe ds le dac permet de parfaitement 'temporiser' le decodage est elle meilleure ?


Salut,

il y a pas mal de possibilités toutes plus astucieuses les unes que les autres expliquées sur ce document : http://www.tnt-audio.com/clinica/diginterf1_e.html, avec des belles figures en couleur. Les solutions que tu imagines sont plutôt développées en page 2.

JG Naum a écrit:Bref, y a t il des solutions au pb du jitter ?


oui, la preuve dans les mesures de certaines platines page précédente

JG Naum a écrit:d ailleurs pkoi on arrive a faire des drives+dac a jiiter limites et que nos solutions informatiques semblent ne pas arriver a la hauteur de ces mecaniques ?


Parce que certaines des solutions informatiques que nous choisissons ne sont pas adaptées (PC + DAC via S/PDIF est l'exemple le plus évident). Mais avec la carte son dans le PC je pense, au moins pour le jitter, qu'il n'y a pas de problème (à vérifier).
Et idem si on fait une belle solution où on transfert de l'informatique via USB asynchrone (si ça existe), wifi ou ethernet vers un DAC qui se charge de tout : il "suffit" que ce DAC ait une bonne horloge et un bon traitement du jitter généré en interne.
corsario
 
Messages: 2218
Inscription: 01 Fév 2005 18:39
Localisation: Paris
  • offline

Message » 16 Juin 2009 22:21

Pio2001 a écrit:Bonjour Corsario

(...)


Génial, il y a à potasser là !...

Merci pour tes explications Pio, je sens que je vais mieux comprendre ces graphes de Stereophile
corsario
 
Messages: 2218
Inscription: 01 Fév 2005 18:39
Localisation: Paris
  • offline

Message » 16 Juin 2009 22:22

JG Naum a écrit:*une clock externe qui synchronise emetteur et receveur va t il resoudre le pb du jitter ou la derive possible de transmission de cette clock aux deux fait qu on reintroduit du jitter ?


Que la clock soit un module externe dédié ou la clock du drive, dans les deux cas elle traverse le câble et arrive toute déformée au DAC. En théorie, elle est peut-être un peu moins déformée lorsqu'elle vient d'un module à part, car elle n'est pas superposée aux données audio. Mais en pratique, il est probable que les différences de qualité entre horloges viennent masquer cela, et normalement, les DACs remettent complètement en forme le signal d'horloge entrant, aussi déformé soit-il.

JG Naum a écrit:la solution d un petit buffer qui stocke les 1 et les 0 et une clock de luxe ds le dac permet de parfaitement 'temporiser' le decodage est elle meilleure ?


Elle est de toutes façons imposée par le transcodage S/Pdif / PCM ou par la conversion EFM. Les vraies données à convertir sont produites directement dans le DAC après traduction des données codées qui sont sur la galette du CD pour un lecteur intégré, ou qui viennent de l'interface S/Pdif pour un convertisseur externe, et elles sont produites directement selon l'horloge du lecteur, ou selon le signal d'horloge tout propre reconstitué en interne par le DAC si c'est un DAC externe.

A moins de saboter le DAC pour l'empècher de reconstituer un signal d'horloge propre, on ne retrouve pas en sortie le jitter qu'on avait en entrée : http://www.prismsound.com/m_r_downloads/cdinvest.pdf
On ne voit donc en sortie, si les résultats de cette étude sont généralisables(*), que le jitter de l'horloge finale, et non celui du drive ou du câble, qui sont perdus en route (par la reconstruction dans la PLL pour le DAC, et tout simplement par le fait que la mécanique est esclave du DAC dans un lecteur intégré).


(*) Comportement constaté sur un Prism DAC-1, ce n'est pas non plus de la gnognotte !
Pio2001
 
Messages: 5904
Inscription: 07 Oct 2003 12:50
Localisation: Neuville-sur-Saône
  • offline

Message » 16 Juin 2009 23:06

En lisant, le doc Primsound donne en lien par Pio2001, je retrouve une hypothese abordée, il y a 4 ou 5 ans, a la suite d´un article publie dans Hifi News qui avait etabli une relation entre taux de jitter et alimentations des platines : celles dont le rail d´alimentation tirait sur le rail dedié a la conversion avait un jitter important. Celle dont l´alimentation etait bien concue avec régulations bien penseées, design étudié, transfo suffisament solide souffraient moins du pb aux mesures.
Adhérez au club de ceux qui ont la "méfiance infuse", après avoir adhéré à l'association...
haskil
Membre HCFR
Membre HCFR
 
Messages: 49552
Inscription: 06 Déc 2001 2:00
Localisation: Haute Normandie et Paris
  • offline

Message » 16 Juin 2009 23:16

haskil a écrit:
loloboy a écrit:C'est bien pour ca que je ne comprends pas pouvquoi le buffer d'entrée n'est en général pas considéré comme une bonne solution.


Jusqu´ici, j´ai plutôt lu l´inverse : le buffer en entrée etant plutôt tenu pour être une solution efficace. Sur HCFR et ailleurs.

J'avais d'autres souvenirs... mais de là à en trouver les traces...

Du coup, pourquoi n'est-ce pas plus souvent mis en oeuvre ?
guest
 
Messages: 23526
Inscription: 15 Fév 2001 2:00
  • offline

Message » 16 Juin 2009 23:23

Je ne suis pas fabricant, mais il me semble avoir compris qu'il est à l'heure actuelle impossible de concevoir un DAC sans buffer en entrée.

Les données entrantes ne sont pas les données à convertir. Elles doivent être traitées et passer par des puces de calcul pour reconstituer les données à convertir. Ces puces sont cadencées par une horloge. Cette horloge est interne.
Il faut donc un buffer pour synchroniser les données entrantes à l'horloge interne.

Certains fabricants mettent en avant le buffer de leur DAC, mais c'est comme un fabricant de fourchettes qui vanterait le fait que ses fourchettes ont un manche, ce qui est effectivement bien pratique pour les saisir, mais ne leur donne pas spécialement d'avantage sur la concurrence.
Pio2001
 
Messages: 5904
Inscription: 07 Oct 2003 12:50
Localisation: Neuville-sur-Saône
  • offline

Message » 16 Juin 2009 23:26

Pio2001 a écrit:Bonjour Corsario,

corsario a écrit:Un ordre de grandeur : "digital audio theory predicts that jitter needs to be below 100ps for 16-bit (ie, CD) audio to be reproduced without degradation—and 24-bit audio requires jitter to be below 10ps!"


Il y a un problème avec ces chiffres. La résolution du 24 bits est 256 fois supérieure à celle du 16 bits. Le jitter considéré étant petit par rapport à la période d'échantillonnage, on peut considérer que la perturbation est linéaire. Donc si 100ps sont requises pour 16 bits, 100/256 = 0.39 ps sont requises pour du 24 bits. Et encore moins si la fréquence d'échantillonnage est supérieure.

On peut calculer la limite absolue. L'erreur maximale est obtenue aux zéros d'une sinusoïde de pleine amplitude et de fréquence maximale. La pente de la fonction sinus est alors de 1, de sorte qu'un décalage de pi/2 radians conduirait au premier ordre à un écart en amplitude de pi/2 fois l'amplitude max.
Pour le CD, la période de la sinusoïde sera de 1/22050 = 45.4 µs. Les pi/2 valent un quart de période, soit 11.3 µs.
On cherche le décalage conduisant à la plus petite erreur mesurable, soit 32768 fois moins. Ce qui donne 346 ps.
Pour du 24 bits 192 kHz, les mêmes calculs conduisent à 0.31 ps.

Tout cela est un exercice purement intellectuel. Dans le dernier cas, cela représente un bruit de -144 dB ! En-dessous de l'agitation moléculaire de l'air ou de l'agitation thermique des semiconducteurs qui véhiculent le signal.

J'avoue, j'ai du relire le message 2x pour le comprendre :oops: .
C'est pourtant clair et logique.

Donc, seon toi, suréchantilloner en sortie d Drive permettrait-il de lutter efficacement contre le jitter ? (sachant qu'aujourd'hui, sauf certaines platines comme de mémoire les Pioneer avec Legato Link, le suréchantillonage se fait plutot en entrée du DAC)
guest
 
Messages: 23526
Inscription: 15 Fév 2001 2:00
  • offline



Retourner vers Discussions Générales

 
  • Articles en relation
    Dernier message