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

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

Le meilleur DAC ?

Message » 07 Jan 2003 14:19

Xéna a écrit:Pour la transmission SPDIF, je vous conseille la lecture de http://www.epanorama.net/documents/audio/spdif.html qui décrit parfaitement ce mode de transmission. Vous y lirez entre autre que l'horloge de base a une période de 163 nS et que la spec du SPDIF autorise un jitter de +/- 20 ns, soit 24.5 % d'erreur. Je pense que l'electronique actuelle est capable de tenir facilement cette spécification, d'autant plus que tous recepteur SPDIF digne de ce nom se doit d'incorporer un système de resynchronisation de son horloge sur chaque transition. Et comme il y a au moins une transition à chaque bit transmis, je peux affirmer sans me tromper qu'à part se mettre dans les pires conditions ( utiliser un cordon non blindé de 50 m et ce à côté d'un poste à soudure électrique en fonctionnement ) , il ne peut pas y avoir d'erreur de transmission à ce niveau.


Salut Xena,

tu n'as peut être pas vu mon précédent post dans ce même topic dans lequel je poste 3 articles intéréssants sur ce phénomène :

ajds a écrit:Un des articles de référence de l'AES (audio enginereing society) sur le sujet écrit par Julian Dunn en 1993 explique clairement les phénomènes mis en cause. Dunn a modélisé les effets d'une transmission sur le signal et le jitter provoqué (chapitre 2 du document).
Il cite également un précédent article ou une étude sur l'audibilité du jitter a été menée, en synthèse la figure 9 page 13 donne un visuel du niveau de jitter maximal admis en fonction de la fréquence.

Voici l'article en question :
http://www.birdland.com/papers/jitter92.pdf

Citons aussi cet excellent article :
http://www.broadcastpapers.com/audio/Jitter1-rev1.PDF

qui propose une solution basée sur une double PLL pour atténuer le jitter.

Un autre enfin, présenté à l'AES en 1995 par Richard Cabot :
http://www.audioprecision.com/publicati ... n961.shtml

La figure 5 montre l'écart temporel lors de la récupération d'horloge.
La figure 8 montre sur une FFT les effets du jitter : basiquement l'apparition d'harmoniques parasites par rapport au signal d'origine.


epanorama, c'est bien, ca donne une première description, mais ca reste quand même un site de vulgarisation electronique. Ca a le mérite d'éviter la lecture fastidieuse des documents officiels décrivant les normes IEC 958 & co, mais ce site n'est pas une référence absolue en la matière. Les vrais documents de référence sont les descriptions des normes IEC et les proceedings de l'AES (http://www.aes.org/) mais, malheureusement, bien peu d'entre eux sont disponibles gratuitement en ligne et la plupart sont payant ou alors il faudrait adhérer à l'AES ;)

Essayons donc de faire avec ce que l'on a et voyons tout d'abords le premier article de Dunn :
on voit en première page qu'il parle bien de cette tolérance de 20 ns de la norme. Malgré tout, après quelques explications théoriques, il cite un précédent article (ref [9]) dans lequel il a étudié de près l'audibilité du jitter. Je n'ai pas réussi à trouver cet article en ligne mais le principal est dispo dans celui qui en ligne, en page 14, Figure 9 : un tableau de l'audibilité du jitter versus la fréquence, on voit qu'a partir de 200 Hz, la sensibilité au jitter croit fortement jusqu'a atteindre une valeur max de 20 ps ! à 20 Khz. La norme initiale est donc complètement à coté de la plaque, ce qui est tout à fait normal : n'oublions pas que la norme SPDIF a été écrite au tout début de l'ère audio numérique (< 1980) époque à laquelle tout le monde avait largement sous-estimé l'influence du timing sur la restitution.

Dunn décrit également comment est généré le jitter en transmission à partir de la récupération de l'horloge depuis le signal spdif lui-même (diagrame de l'oeil) mais bon c'est un peu trappu et pas forcément facile à comprendre. L'article de Cabot, a l'avantage d'être beaucoup plus visuel avec notamment la figure 5 ou l'on voit bien ce qui provoque le jitter dans la récupération de l'horloge.


En ce qui concerne l'écriture dans les DACs, c'est autre chose. Il faut absolument que les DACs soient alimentés à la bonne fréquence ( 44.1 khz, 48 khz, etc ... ). Les systèmes actuels ( toujours dignes de ce nom ) utilisent un buffer pour mémoriser les données reçues et génèrent leur propre horloge avec laquelle ils vont alimenter les DACs. De ce fait, ils sont totalement indépendants de l'intervalle de temps entre les mots transmis.


Ce que font toujours en encore la plupart des intégrés HC du commerce c'est qu'ils prennent l'horloge récupérée vue plus haut et l'utilisent directement pour synchroniser les DACs, avec tout le jitter qui va avec.

Ce que fait TAG McLaren dans son AV32R et son dispositif anti-jitter spécial, c'est qu'ils générent une deuxième horloge de référence à la fréquence détectée (par exemple 44.1 Khz) et essaye de faire correspondre l'horloge récupérée avec l'horloge de référence. Dans le cas ou le système n'arrive pas à faire correspondre les 2, il se base sur l'horloge récupérée :

C'est décrit ici http://www.tagmclaren.com/dev/white/wp9.asp et c'est assez explicite :

The AV32R uses a twin phase lock loop design to reduce the jitter on the master clock to an absolute minimum. The first loop extracts the clock from the bi-phase encoded SPDIF (or TOSLINK) signal. Due to the nature of bi-phase encoding, this signal still contains some time variations caused by the data encoded in the SPDIF signal. The second phase locked loop is based upon a voltage controlled crystal oscillator which provides one of the most stable clock oscillators possible. The phase locked loop filter starts to reject jitter from the clock signal at 6Hz and it is critically damped to provide good stability and the quickest possible lock time. Should this second loop not be able to track the input, such as in vari-speed applications or from particularly unstable source devices, the system will switch seamlessly back to the first loop and continue playing.


Ils se targent d'obtenir un jitter min de 10ps ce qui est excellent.

Au niveau des appareils utlisant un buffer tampon de données avec une re-génération complète de l'horloge, je ne sais pas d'ou viens cette légende mais il y a bien peu d'appareils qui fonctionnent sur ce principe. Peut être certains Meridian, et encore je ne suis pas sur. Si tu as des informations techniques la dessus n'hesites pas à les partager ;)

Bien sur je ne parle pas ici de la norme FireWire, qui comme je l'ai montré précedemment impose un buffer + horloge de référence. Restons sur le SPDIF ;)


Prenons le cas d'un appareil moyen de gamme et récent : le rotel Rsp-1066, dont j'ai eu l'opportunité de récuperer le manuel de service, toujours disponible en ligne apparemment (fait rare) ici :http://www.xlfidelity.se/sm/rsp1066sm.pdf

On y voit dans le bloc diagram page 19 que le spdif est préalablement récupéré par un circuit AK4114 pour être ensuite envoyé vers le dsp CS49326 et finalement vers les DACs.

Il n'y a pas de bufferisation ou autre circuiterie de récupération de jitter autre que l'AK4114. Voyons un peu ce dernier :
http://www.asahi-kasei.co.jp/akm/en/pro ... k4114.html

L'horloge est récupérée avec un "Low jitter analog PLL" ou issue d'un quartz et le tout est envoyé en tant que "master clock" à tout le reste de l'appareil (pins MCK01 et MCK02). Nulle part il est fait mention d'une double PLL pour la récupération de l'horloge (cf article mentionné plus haut), l'horloge récupérée bien que issue d'une PLL de bonne qualité (la fameuse Low jitter analog PLL) va donc avoir les même caractéristiques que celle de l'article de Cabot.

Apparemment l'horloge de référence générée par le Quartz est essentiellement utilisée pour détecter la fréquence d'échantillonage rentrante ou pour les signaux non-pcm (DD/DTS). L'horloge de sortie sera soit l'horloge récupérée (Mode1) soit l'horloge de référence (Mode2), les pins CM0/CM1 permettent de selectionner le mode. Il existe apparemment un mode intelligent (Mode3) dans lequel l'horloge utilisée est la référence (Quartz) tout en monitorant l'horloge récupérée. Le mécanisme n'est pas automatique et requiert une logique supplémentaire pour piloter ca et faire en quelque sorte la même chose que TAG. Je n'ai pas vu de circuit dédié à ce genre de chose dans le diagramme du 1066, j'en conclus qu'il ne l'implémente pas :(

Accessoirement, en page 46, on voit le diagramme d'implémentation typique dans lequel la master clock du 4114 est utilisée directement sur le DAC.

Ma conclusion est que le jitter reste un phénomène perceptible en SPDIF et qu'il est grand temps qu'on abandonne cette norme de transmission vieillisante pour passer a quelque chose de mieux pensé : ie l'interface FireWire ;)


PS : Dédicace particulière à AJDS :) ( le post toujours d'actualié ) http://www.homecinema-fr.com/forum/view ... t=29656566


héhé, d'ailleurs il faudrait que je change le titre par "Un cordon a un sens, même en numérique, mesures à l'appui" ;)
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Annonce

Message par Google » 07 Jan 2003 14:19

Publicite

 
Encart supprimé pour les membres HCFR

Message » 07 Jan 2003 14:23

Un UP pour cause de jitter du forum :lol:
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 07 Jan 2003 18:30

Ajds,
merci pour la référence sur le RSP1066. J'ai bien vu que c'est le CS493263 http://www.cirrus.com/en/products/pro/detail/P45.html qui drive les DACs et non le AK4114. Or, si tu regardes bien le diagramme de ce circuit, tu vois la présence de :
- un RAM INPUT BUFFER associé au FRAMER SHIFTER situé entre les entrées series numériques et le DSP.
- un RAM OUPUT BUFFER entre le DSP et l' OUTPUT FORMATER qui drive les DACs.
Le pilotage des DACs est donc totalement indépendant du timming de la ligne SPDIF, ce qui est logique car le décodage est fait dans le CS493263.
Les articles que tu cite ne tiennent pas compte de cet état de l'art car ce n'est plus le signal SPDIF qui cadence les DACs.
C'est pourquoi je répète que à l'heure actuelle, le jitter ne peut plus être un problème sur des équipements conçus avec des composants adéquats.
Xéna
 
Messages: 2072
Inscription: 09 Oct 2001 2:00
Localisation: ROQUEVAIRE ( 13 )

Message » 07 Jan 2003 20:23

Salut !

Je suis bien d'accord avec ajds là dessus (c'est suffisament rare qu'on soit vraiment du même point de vue tout de suite pour qu'on le signale :wink: :roll: , même si cela n'a jamais empèché des discussions constructives :wink: ).

En quelques mots, selon moi, les dac hifi ont rarement une mémoire tampon (le seul que je connais est le Chord DAC64 à 25000F quand même !), donc l'horloge utilisé pour la conversion n/a est "forcément" celle récupérée par la PLL de la liaison SPDIF, donc on récupère le jitter associé, ou au moins une partie (selon le comportement de la PLL).
il me semble que certains des liens proposés par ajds présentent bien cela...

Pour le cas du RSP1066 et autres décodeurs hc, c'est peut-être différent des dac purement hifi, car il y a des puces de décodage (DD, DTS...), donc certainement des horloges supplémentaires...
Alors que sur les dac purement audio, en général on a une puce de réception SPDIF qui attaque la puce dac et "c'est tout" !

Sans compter qu'avec 2 horloges et un buffer entre les 2, il faut forcément que l'horloge associée à la conversion soit recalée sur celle de la SPDIF (afin de garantir que le buffer ne va pas déborder ou se vider complètement).
Cela impose alors que la 2ème horloge soit asservie sur le long terme par une PLL sur la 1ère horloge, et cela va donc récupérer au moins une partie du jitter de l'horloge 1.


Pour finir, je pense que de toute façon, SPDIF ou pas, le jitter est un problème important en audionumérique, surtout que j'ai l'impression que la majorité des fabricants ne se donnent pas la peine de mettre des horloges de qualité dans leur matos : en général, une porte inverseuse intégrée à une des puces numériques, 1 quartz, 2 capa et 1 résistance, et basta, on est loin d'un oscillateur faible jitter de qualité !

Je crois d'ailleurs qu'un de ces 4, je vais essayer un changement d'horloge dans ma platine... Car il ne faut pas oublier que le jitter au niveau de la conversion n/a est toujours au moins aussi important que celui de l'horloge (et en pratique un peu plus) !

a+

jb
jbcauchy
 
Messages: 3165
Inscription: 22 Oct 2001 2:00
Localisation: Chatellerault
  • offline

Message » 07 Jan 2003 20:38

Moi j'avis un PC comme drive relié en spdif, j'ai essayi un câble à 5 euros et un câble à 1500 euros, comme je n'entidais pas de différence et que le son étit pas très bon, eh ben j'ai tout jitter à la poubelle!


:wink:
vincent128
 
Messages: 6312
Inscription: 05 Déc 2001 2:00
Localisation: France
  • offline

Message » 07 Jan 2003 20:49

Xéna a écrit:Ajds,
merci pour la référence sur le RSP1066. J'ai bien vu que c'est le CS493263 http://www.cirrus.com/en/products/pro/detail/P45.html qui drive les DACs et non le AK4114. Or, si tu regardes bien le diagramme de ce circuit, tu vois la présence de :
- un RAM INPUT BUFFER associé au FRAMER SHIFTER situé entre les entrées series numériques et le DSP.
- un RAM OUPUT BUFFER entre le DSP et l' OUTPUT FORMATER qui drive les DACs.
Le pilotage des DACs est donc totalement indépendant du timming de la ligne SPDIF, ce qui est logique car le décodage est fait dans le CS493263.
Les articles que tu cite ne tiennent pas compte de cet état de l'art car ce n'est plus le signal SPDIF qui cadence les DACs.
C'est pourquoi je répète que à l'heure actuelle, le jitter ne peut plus être un problème sur des équipements conçus avec des composants adéquats.


Oui en effet le diagramme du CS49326 montre bien que les données PCM sont bufferisées. C'est à la fois logique et étonnant.

Logique parce qu'un intégré HC / preamp HC a besoin de bufferiser pour une raison bien simple : permettre à l'utilisateur de paramètrer les retards sur chaque canal en DD/DTS/DPL-II. Le datasheet du CS49326 indique d'ailleurs que si on veut des délais plus importants, il faut ajouter de la SRAM (page 62).

Etonnant parce ce que, justement, sur le Rsp-1066, le réglage de délai n'est pas disponible pour les enceintes principales et donc pour du PCM stéréo :o

Etonnant aussi parce que lorsqu'on regarde une application typique (Hi-Fi) de l'AK4114, ce dernier pilote les DACs. Quand on regarde une application typique d'un chip HC, c'est ce dernier qui pilote les DACs avec donc une horloge de référence interne et une bufferisation des données. Cela sous-entendrait donc qu'un appareil HC est plus apte à retranscrire correctement du PCM (entendez sans jitter) qu'un DAC Hi-Fi.

Si cela s'averai vrai, ca serait une petite révélation dans le monde de la hi-fi :lol:
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 07 Jan 2003 21:57

ajds a écrit:Etonnant aussi parce que lorsqu'on regarde une application typique (Hi-Fi) de l'AK4114, ce dernier pilote les DACs. Quand on regarde une application typique d'un chip HC, c'est ce dernier qui pilote les DACs avec donc une horloge de référence interne et une bufferisation des données. Cela sous-entendrait donc qu'un appareil HC est plus apte à retranscrire correctement du PCM (entendez sans jitter) qu'un DAC Hi-Fi.

Si cela s'averai vrai, ca serait une petite révélation dans le monde de la hi-fi :lol:
Oui, ce n'est pas idiot comme raisonnement !

Mais il faudrait aussi que l'horloge intégrée dans les décodeurs hc soit de qualité, mais là je sais pas dire ?
Et aussi, que la partie conversion n/a et analogique soit aussi de bonne qualité, ce qui n'est sans doute pas le cas dans les intégrés hc bon marché.

Cela montre aussi que certains fabricants hifi partent parfois vers des solutions plus "idiophiles" que réellement techniques : ils nous mettent des composants analogiques de "luxe" mais laissent souvent des traitements numériques très sommaires et des horloges pourries... :cry: :evil: :(

Sinon, avec une horloge interne au décodeur hc décorélée de l'horloge venant du SPDIF, je vois pas comment on peut garantir que le buffer ne va pas déborder ou se vider complètement sans mettre un asservissement ? Les simples tolérances sur les quartz me parraissent insuffisantes pour le garantir ?

a+

jb
jbcauchy
 
Messages: 3165
Inscription: 22 Oct 2001 2:00
Localisation: Chatellerault
  • offline

Message » 07 Jan 2003 22:24

Si j'exclus les interventions d'un individu qui fait avancer les débats en jetant des pierres, c'est un post particulièrement instructif ! merci adjs !
J'aurais voulu être un artiiiiiiiiiiiste .... ouillllllle
Finalement la HiFi c'est pas mal ;-)
Avatar de l’utilisateur
Kador
Membre HCFR
Membre HCFR
 
Messages: 3409
Inscription: 14 Mar 2002 2:00
Localisation: 31 cassoulpif

Message » 08 Jan 2003 1:07

jbcauchy a écrit:[Sinon, avec une horloge interne au décodeur hc décorélée de l'horloge venant du SPDIF, je vois pas comment on peut garantir que le buffer ne va pas déborder ou se vider complètement sans mettre un asservissement ? Les simples tolérances sur les quartz me parraissent insuffisantes pour le garantir ?



Essayons de calculer ;)

On peut partir du principe que la tolérance finale de la PLL est la même que celle du Quartz qui l'alimente.
La plupart des PLL en audio sont baties sur un Quartz 27 Mhz, prenons un HC-49U de Kony un chez Radiospares :
Frequency Calibration tolerance : +/- 0.005 % @ 25°C
Frequency Stability tolerance : +/- 0.010% @ 0-70°C

Le total de la tolérance combinée nous donne +/- 0,015%, ce qui qui donne 0,030% si on prends les extrèmes (le Quartz de la source est au plus bas, celui de la référence est au plus haut).

Sur un signal 44.1 Khz 16 bits, ca nous donne donc un delta de 44100*16*0,030/100 = 211 bits de décalage par seconde.

Au bout d'une heure de musique on a donc environ 760 Kbits

Ca tiens tout juste dans une SRAM 1 Mbits, configuration préconisée par Cirrus pour les config THX :o

Mais bon il faut garder un peu de marge et il faut de la RAM aussi pour le code du chip et le buffer de sortie.
Conclusion : ca parait possible mais il ne faut pas lésiner sur la RAM embarquée !

Sinon, autre chose curieuse, le jitter max d'un chip de PLL analogique tel un Burr Brown PLL1705 est de 50 ps soit plus que la tolérance max annoncée par Dunn, même avec une horloge de référence on voit que le problème n'est pas simple :o

http://www.tij.co.jp/jsc/docs/msp/pro_s ... 705_06.pdf
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 08 Jan 2003 1:28

OUAIS ! :P

La filière redevient intéressante !
Ninja40
 
Messages: 1473
Inscription: 22 Aoû 2002 16:37
  • offline

Message » 08 Jan 2003 11:15

ajds a écrit:Sur un signal 44.1 Khz 16 bits, ca nous donne donc un delta de 44100*16*0,030/100 = 211 bits de décalage par seconde.

Au bout d'une heure de musique on a donc environ 760 Kbits


Tout d'abord, ton calcul est pour du mono et non de la stéréo. :)

Ensuite, ce n'est pas la bonne vision des choses car tu fais l'amalgamme entre la transmission SPDIF et le chargement des DACs.

1 - La transmission pour du 44.1 KHz se fait avec une horloge de 2.8 MHz, soit une période de 357nS.
2 - 44.1KHz correspond à un intervalle de temps de 22.67 uS
3 - On peut donc transferer 63.5 bits pendant ce temps, alors que le protocole SPDIF prévoit 2 chaînes de 24 bits.

Il n'y a donc pas de phénomène de glissement continu entre les horloges de l'émeteur et du recepteur, et donc aucun risque de perte de bit.
Xéna
 
Messages: 2072
Inscription: 09 Oct 2001 2:00
Localisation: ROQUEVAIRE ( 13 )

Message » 08 Jan 2003 13:07

Xéna a écrit:Tout d'abord, ton calcul est pour du mono et non de la stéréo. :)


oui et en plus j'ai oublié que si on prends le cas inverse de mon hypothèse (l'horloge de la source clockée moins vite) : c'est la cata, le DAC passe son temps à attendre les données et le buffer est vide en permanence ! :oops:

Ensuite, ce n'est pas la bonne vision des choses car tu fais l'amalgamme entre la transmission SPDIF et le chargement des DACs.


ben je me suis placé directement au niveau de l'information utile pour simplifier le calcul.

1 - La transmission pour du 44.1 KHz se fait avec une horloge de 2.8 MHz, soit une période de 357nS.
2 - 44.1KHz correspond à un intervalle de temps de 22.67 uS
3 - On peut donc transferer 63.5 bits pendant ce temps, alors que le protocole SPDIF prévoit 2 chaînes de 24 bits.

Il n'y a donc pas de phénomène de glissement continu entre les horloges de l'émeteur et du recepteur, et donc aucun risque de perte de bit.


ben justement je ne suis pas sûr qu'il faille voir les choses sous cet angle car il faut prendre en compte :
- le codage bi-phase mark encode chaque bit avec 2 impulsions
- il faut ajouter aux données brutes utiles des données de sync et de contrôle (Channelstatus and subcode information)
- pour chaque échantillon, 2 mots de 32 bits sont envoyés, à priori de manière synchrone donc la capacité de transmission non utilisée est tout simplement perdue et ne peut pas servir à faire des recalage d'horloge

Plus je refléchis à la chose plus je pense que jbcauchy a raison : il faut forcément un asservissement de la fréquence finale par celle qui est émise.
Mais bon ca ne remets pas en cause la faisabilité de la chose et asservissement ne signifie pas forcément jitter à l'arrivée. Dans ce cas un tout petit buffer suffira amplement.

D'ailleurs dans le datasheet du CS49326 ils parlent de 2 modes pour le clock : Master et Slave. Faudrait creuser pour voir ce que ca fait exactement.
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 08 Jan 2003 14:05

Kador a écrit:Si j'exclus les interventions d'un individu qui fait avancer les débats en jetant des pierres, c'est un post particulièrement instructif ! merci adjs !


J'éspère que tu ne parles pas de mon post : c'était juste un petit trait d'humour (peut-être pas très drôle je vous l'accorde).
Ca servait notamment à dire : ouf, on peut enfin, à nouveau, dire une petite connerie de temps en temps sans que pour autant tout parte en coui.lle.

Donc continuez bien la discution (trop technique pour moi). Ma seule contribution, c'est :
quand est-ce qu'on teste un PC comme drive HDG avec synchronisation commune du drive et du DAC sur wordclock externe (branchée en BNC)? Y'a pas mal de carte sons pros et semi-pros qui permettent ça!
En principe plus aucun jitter, non?
vincent128
 
Messages: 6312
Inscription: 05 Déc 2001 2:00
Localisation: France
  • offline

Message » 08 Jan 2003 18:05

Ajds a écrit:ben justement je ne suis pas sûr qu'il faille voir les choses sous cet angle car il faut prendre en compte :
- le codage bi-phase mark encode chaque bit avec 2 impulsions
- il faut ajouter aux données brutes utiles des données de sync et de contrôle (Channelstatus and subcode information)
- pour chaque échantillon, 2 mots de 32 bits sont envoyés, à priori de manière synchrone donc la capacité de transmission non utilisée est tout simplement perdue et ne peut pas servir à faire des recalage d'horloge

en fait, la transmission se fait par block et chaque block comprend une entête de 192 bits + 192 échantillons ( D + G ).
Un bloc fait donc 192 + ( 192 * 32 * 2 ) = 12480 bits, soit 24960 cycles d'horloge. La période du SPDIF est de 163nS ce qui fait une durée de transmission de 4.068 mS.
Or, à 44.1 KHz, il faut 4.353 mS pour émettre 192 échantillons.
Il semble évident que le recepteur ne peut pas syncrhoniser son horloge 44.1KHz car la durée de transmission des 192 échantillons + entête correspond à du 48 KHz.
Il est donc nécessaire pour le récepteur de buffériser ces échantillons qui arrivent trop vite, et de générer sa propre horloge 44.1 KHz.
Xéna
 
Messages: 2072
Inscription: 09 Oct 2001 2:00
Localisation: ROQUEVAIRE ( 13 )

Message » 08 Jan 2003 20:04

Xéna a écrit:Il n'y a donc pas de phénomène de glissement continu entre les horloges de l'émeteur et du recepteur, et donc aucun risque de perte de bit.


Salut !

Je ne suis pas d'accord sur ce point. Ton calcul est peut-être plus vrai que celui de ajds pour ce qui est du temps pour transmettre une trame sur le SPDIF, mais pour ce qui est de l'absence de synchro entre les 2 horloges, cela ne change rien selon moi : si tes 2 horloges sont indépendantes, tu es paraitement incapable de garantir qu'elles sont parfaitement identiques en fréquence moyenne, et il y aura donc forcément glissement entre les 2...

je détaille : le drive transmet les infos de sortie en se basant sur un débit qu' il considère comme correspondant à l'envoi en moyenne de 44100 échantillons stéréo par seconde (quelque soit le protocole utilisé, le codage SPDIF n'intervient pas ici), mais en fait avec la tolérance de son quartz d'horloge, son débit moyen sera légèrement différent.
De même, le dac externe va envoyer les infos à sa puce de conversion N/A à un débit qu'il croit égal à 44100 échantillons par seconde, mais en fait le débit réel sera légèrement différent à cause de la tolérance de son quartz.

Si on suppose par ex que le quartz du drive a une fréquence réelle qui est 0.01% plus élevée que sa valeur théorique, il va envoyer en moyenne 44100 échantillons pendant une durée qui croira égale à 1 s mais qui sera 1.0001 s, ce qui correspond à un débit réel d'environ 44095.6 échantillons/seconde.

Et si que le dac a un quartz de fréquence réelle 0.01% plus faible que sa valeur théorique, il va "sortir" du buffer 44100 échantillons pendant ce qu'il croira être une seconde alors que ce sera en fait 0.9999s. ce qui fait un débit moyen de environ 44104.4 échantillons stéréo par seconde.

Dans ce cas, le débit moyen de remplissage du buffer sera de 44095.6 échantillons stéréo par seconde, et le débit de "vidange" du buffer sera de 44104.4 échantillons par secondes. Donc il se rempli plus vite qu'il ne se vide, ce qui ne pourra durer qu'un temps !
Une fois que le buffer sera vide, comment fait le dac ?

On peut noter que pour mes calculs, j'ai pris 0.01% d'erreur ce qui fait 100ppm, ce qui n'est pas tellement éloigné de la tolérance d'un quartz standard, comme l'a déja dit ajds...

Est-ce que c'est plus compréhensible comme cela ?

a+

jb
jbcauchy
 
Messages: 3165
Inscription: 22 Oct 2001 2:00
Localisation: Chatellerault
  • offline


Retourner vers Discussions Générales

 
  • Articles en relation
    Dernier message