Transport audio externe vers DAC

[mulciber]

Ha enfin une réponse technique faite par un technicien !

- Concernant la wordclock, j'ai lu que ce ne pouvait pas être une solution contre le jitter car le signal wordclock va transiter lui même par un cable assujeti au jitter (décallage temporel) : est-ce exacte ? bref si l'horloge de la source est importante, autant cadencer correctement le SPDIF, pas besoin d'utiliser en plus un wordclock, non ?

La bonne question est : est ce la qualité de l'horloge ou la synchronisation de la source et du DAC qui est le plus important lors d'une synchronisation word clock.

[robob]

Salut,
Pour que le traitement d'un signal audio numerique soit parfait, il faut deux choses :
1- Que le transfert des données soit integre, ce qui est envoyé = ce qui est reçu (bit-perfect).
2- Que l'horloge du convertisseur N/A soit le plus précise possible.

Le point 1 est le plus facile à réaliser, la PLL du DAC se resynchronisant sur le signal SPDIF récupere toutes les données sauf dans des cas exceptionnels. Le points 2 pourrait être aussi simple : il suffirait de reclocker le DAC avec sa propre horloge mais survient le probleme de la synchronisation des données entre le recepteur du DAC lié à l'horloge du signal SPDIF et le chip de conversion avec sa propre Horloge. En d'autre terme, même avec un Buffer de données entre les deux, il faut top ou tard résorber le décallage des horloges. Comme des tas de mecs plus compétents se sont posé la question bien avant moi, je suppose que ce probleme est réglé depuis belle lurette et que 99% des DAC audiophiles vendus aujourd'hui utilisent une recette efficace.
Par exemple mon petit DAC Audiophonics est muni d'un Quartz 11.2896mhz qui n'est certainement pas là pour indiquer l'heure. J'ai d'ailleur posé la question au vendeur afin de connaitre l'implémentation du DAC et donc l'importance ou pas de la régularité de l'horloge de la source et du jitter induit par le transport.
Si le DAC utilise la PLL pour se synchroniser, il va de soit que l'horloge de la source est importante. Si le DAC utilise sa propre horloge pour synchronisé les données à convertir, la qualité du transfert devient toute relative.

[gerardfma]

... est muni d'un Quartz 11.2896mhz qui n'est certainement pas là pour indiquer l'heure.

Quelle coincidence troublante, 11.2896MHz c'est pile 256 fois 44.1kHz

[robob]

Ce qui ne m'explique pas comment est fait la synchro entre le recepteur qui doit se caller sur l'horloge SPDIF et le convertisseur s'il fonctionne avec le quartz, mais qui semble montrer que le DAC fonctionne sur sa propre horloge et devrait donc s'affranchir du jitter eventuel dû au SPDIF ou à l'horloge (totalement irréguliere) de mon chipset son, non ?
Je vais poser la question sur DIYaudio, je ne voudrait pas trop déranger Audiophonics sur ce coup, surtout que leur DAC vient de Chine et qu'il ne maitrise peut-être pas completement son implémentation...

[gerardfma]

Ce n'est pas le DAC (PCM1798 de BB) qui utilise la fréquence fournie par le quartz, mais bien le récepteur Cirrus CS8416.
Ce dernier utilise cette horloge pour la diviser en interne, par 256 par exemple pour tomber sur les 44.1kHz requis pour un flux classique type Audio CD.
D'autre part, elle sert de référence à la PLL intégrée au CS8416 (et non au DAC comme écrit initialement) , PLL qui va en fait asservir la dite fréquence sur celle, "virtuelle", extraite du flux de données SPDIF.
Dans un montage de ce type, la précision du quartz est toute relative, puisque de toute façon, la vraie fréquence est celle résultante de l'asservissement fait par la PLL sur le flux SPDIF.

D'autre part, le récepteur extrait le flux de donnée SPDIF et l'envoie via une liaison sérielle (broches OLRCK, OSCLK, SDOUT) au DAC, qui à partir de là opère la conversion, au rythme imposé par l'horloge de la liaison sérielle et non par le quartz... donc au rythme de la liaison SPDIF ... d'où l'importance de la qualité de la source ...

La précision et la stabilité du quartz sont par contre primordiaux dans le cas d'une liaison asynchrone, avec bufferisation des données, car là, oui, la référence d'horloge devient "locale" au DAC, peu importe (dans une certaine mesure bien sûr, faut pas exagerer non plus) la stabilité de la liaison SPDIF

Post édité pour corriger un "typo" ...

[robob]

Merci pour l'explication : sur DIYaudio, un forumeur me dit que le CS8416 peut-être utiliser en "mode esclave" et qu'il possede un buffer de 2 echantillons de données. Est-il possible que bien qu'il soit asservi sur l'horloge du SPDIF, il se serve de se buffer pour renvoyer les données au rythme de l'horloge du quartz ? je lis ça dans le datasheet :
"After a fixed delay from the Z/X preamble (a few periods of the internal clock, which is running at 256Fs),
the circuit will look back in time until the previous Z/X preamble and check which of the following conditions
occurred:
1. If during that time, the internal data buffer was not updated, a slip has occurred. Data from the previous
frame will be output and OSLIP will be set to 1. Due to the OSLIP bit being “sticky,” it will remain 1 until
the register is read. It will then be reset until another slip/repeat condition occurs.
2. If during that time the internal data buffer did not update between two positive or negative edges (depending
on OLRPOL) of OLRCK, a repeat has occurred. In this case, the buffer data was updated twice,
so the part has lost one frame of data. This event will also trigger OSLIP to be set to 1. Due to the OSLIP
bit being “sticky,” it will remain 1 until the register is read. It will then be reset until another slip/repeat
condition occurs.
3. If during that time, it did see a positive edge on OLRCK (or negative edge if the SOLRPOL is set to 1)
no slip or repeat has happened. Due to the OSLIP bit being “sticky,” it will remain in its previous state
until either the register is read or a slip/repeat condition occurs."
Mon anglais technique est limité, mais peux-tu me confirmer que en gros, le DAC récupère les données mais les renvoie à la cadence de sa propre horloge en bufférisant maximum deux échantillons : s’il n’a pas reçu le suivant il répète le precedent. Dans ce cas, il serait complètement exonéré du jitter de la connexion ? Tout au plus risque t’il de louper un échantillon ou d’en répéter un si les horloges ne sont pas en phase.

[gerardfma]

Tout d'abord, j'ai corrigé mon post précédent, là où j'avais écrit DAC alors qu'il fallait lire CS8416

Le CS8416 comprend effectivement 2 buffers, D et E:
- D est le buffer de réception, dans lequel est stockée la trame en cours de réception et ce jusqu'a analyse complète de sa validité
- E est le buffer où est stockée la trame une fois totalement reçue, si elle est valide, et qui contient donc ce qui doit être envoyé au DAC
Les 2 buffers sont indépendants, et le circuit peut en même temps recevoir une nouvelle trame (dans le buffer D), tout en envoyant le contenu de la précédente (contenue dans le buffer E) au DAC.
A noter quand même qu'on parle bien là de "trame", pas "d'échantillon", et qui dit trame dit plusieurs échantillons successifs (canaux droit et gauche).

Il faudrait vérifier, mais je suis à peu près certain que sur ton DAC Audiophonics, le CS8416 ne peut être utilisé qu'en mode Master, et donc que le DAC PCM1798 est cadencé via les signaux OLRCK et OSCLK, fournit par le CS8416 et qui résultent de l'asservissement via sa PLL (dont la référence est l'horloge fournie par l'osciallteur à 11.2896MHz) à l'horloge extraite du flux SPDIF:
In master mode, the left/right clock (OLRCK) and the serial bit clock (OSCLK) are outputs, derived from the recovered RMCK clock., le "recovered" signifiant reconstituée par la PLL.

Le CS8416 serait typiquement utilisé en mode slave dans une application de type DAC asynchrone et donc bufferisé. Dans ce cas, il y aurait effectivement stockage des échantillons dans un buffer tampon et possibilité pour le DAC (le circuit) d'avoir une horloge parfaitement stable, et de ne plus être tributaire des variations vues sur le flux SPDIF.

[mulciber]

D'autre part, le récepteur extrait le flux de donnée SPDIF et l'envoie via une liaison sérielle (broches OLRCK, OSCLK, SDOUT) au DAC, qui à partir de là opère la conversion, au rythme imposé par l'horloge de la liaison sérielle et non par le quartz... donc au rythme de la liaison SPDIF ... d'où l'importance de la qualité de la source ...

Salut,

Est ce que je peux conclure que finalement c'est bien synchronisation du dac et la source qui est plus"utile" que la précision du quartz du DAC ou de l'asservissement PPL pour réduire les problèmes de jitter ( il faut peut être les trois pour limiter au maximum les effets).

[gerardfma]

C'est la somme des 3 qui fait la qualité de cette liaison sérielle.

On ne peut négliger ni la précision ni la stabilité du quartz, ni la qualité de la circuiterie de la PLL, car si l'écart entre horloge source et horloge récepteur va grandissant, la PLL peut se trouver en situation de "décrochage" (incapacité à se caler sur la source) et donc de perte de synchro et donc potentiellement d'informations.

Mais le point majeur reste la qualité de la source dans un modèle de ce type, dit synchrone.
Or (et ce bien que je sois de longue date un fervent défenseur de la dématérialisation), une source informatique, si elle présente de multiples qualités et intérêts (facilité d'accès à sa CDthèque, fiabilité de lecture, etc...) n'est pas exempte de défauts, défauts qui n'affectent pas forcément une source de type "transport".
On a trop souvent tendance à oublier que nos bons ordinateurs ne sont pas temps réel, et ce quel que soit l'OS. Je sais que cela fera sourire certains qui pensent que vu la faiblesse du débit requis (c'est vrai quoi, avec un proc à 2.2GHz, envoyer un flux à 44.1kHz, ça doit être de la rigolade non?) mais c'est oublier les requis de fonctionnement en "flux tendu" entre source et DAC et le faible niveau de priorité affecté aux pilotes audio, et ce que l'on soit en utilisation normale, en KS, en ASIO et autres WASAPI ...

D'où le succès grandissant des DAC asynchrones en environnement informatique

[mulciber]

C'est la somme des 3 qui fait la qualité de cette liaison sérielle.

On ne peut négliger ni la précision ni la stabilité du quartz, ni la qualité de la circuiterie de la PLL, car si l'écart entre horloge source et horloge récepteur va grandissant, la PLL peut se trouver en situation de "décrochage" (incapacité à se caler sur la source) et donc de perte de synchro et donc potentiellement d'informations.

Mais le point majeur reste la qualité de la source dans un modèle de ce type, dit synchrone.
Or (et ce bien que je sois de longue date un fervent défenseur de la dématérialisation), une source informatique, si elle présente de multiples qualités et intérêts (facilité d'accès à sa CDthèque, fiabilité de lecture, etc...) n'est pas exempte de défauts, défauts qui n'affectent pas forcément une source de type "transport".
On a trop souvent tendance à oublier que nos bons ordinateurs ne sont pas temps réel, et ce quel que soit l'OS. Je sais que cela fera sourire certains qui pensent que vu la faiblesse du débit requis (c'est vrai quoi, avec un proc à 2.2GHz, envoyer un flux à 44.1kHz, ça doit être de la rigolade non?) mais c'est oublier les requis de fonctionnement en "flux tendu" entre source et DAC et le faible niveau de priorité affecté aux pilotes audio, et ce que l'on soit en utilisation normale, en KS, en ASIO et autres WASAPI ...

D'où le succès grandissant des DAC asynchrones en environnement informatique

Merci pour ta réponse.

C'est bien ce que je pensais, le discourt sur l'asservissement PPL qui permet s'affranchir du jitter de la source est une demie vérité, c'est surement nécessaire mais pas suffisant.

Sinon, connais-tu beaucoup de DAC asynchrones en environnement informatique ?

[gerardfma]

En environnement informatique, DAC asynchrone veut essentiellement dire DAC USB ou DAC Firewire. Ou encore cartes audio en Firewire.

Coté DAC USB asynchrones, juste quelques exemples que j'avais en tête:
- Ayre: http://www.ayre.com/9series.htm
- Aesthetix: http://www.aesthetix.net/introducing.php
- Wavelength: http://www.usbdacs.com/Products/Products.html
mais désolé d'avance, les prix risquent de te refroidir
Il y en a surement d'autres, peut-être plus abordables
Comme: http://www.kaplanhtdesign.com/HRT_Music_Streamer.html

[robob]

On ne peut négliger ni la précision ni la stabilité du quartz, ni la qualité de la circuiterie de la PLL, car si l'écart entre horloge source et horloge récepteur va grandissant, la PLL peut se trouver en situation de "décrochage" (incapacité à se caler sur la source) et donc de perte de synchro et donc potentiellement d'informations...

Ce que l'on sait par contre, c'est que la plus part des DAC sont tres accomodants en reception : les tests de jitter faits sur le forum montrent que pour faire décrocher les PLL des DAC testés (des modèles courants), il faut des niveaux de jitters bien au delà de ce que l'on trouve meme dans les chipset son de base.
Cela n'empeche pas, et je suis tout à fait d'accord sur ce fait, que si l'horloge du DAC (de la puce de conversion) est directement asservie par celle de la source + les dégradations liés au cable, cela va "jitteriser" le signal et sans aucun doute entrainer des dégradations audibles.
Mais on le voit bien si dessus, les chipsets de reception des DAC (CS8416, DIR9001,...) sont prévus pour pouvoir s'affranchir completement du jitter de la source. Faut-il encore que cela soit implémenté d'une maniere ou d'une autre sur le DAC ce qui manifestement est difficile à savoir.

Il n'est toujours pas claire pour moi si le CS8416 de mon DAC renvoie les données en sortie cadencées avec son propre quartz, donc dans ce cas n'importe quel sortie spdif de base de PC conviendrait et on serait "jitter-free", ou pas. A titre indicatif, Nicolas FERHAT de Audiophonics m'indique que : "Lorsque le DAC est utilisé au dessus de 48khz il utilise l'horloge du signal SPDIF, le quartz n'est plus utilisé. " et "Pour fonctionner en 24/192 il faut retirer le quartz, c'est vrai que c'est un peu contraignant, nous allons essayer d'y ajouter un jumper dans la prochaine version". Ce que je traduis par en 44.1khz, le DAC utilise sa propre horloge.
D'ailleur "In master mode, the left/right clock (OLRCK) and the serial bit clock (OSCLK) are outputs, derived from the recovered RMCK clock." : OLRCK et OSCLK sont dérivées de RMCK oui, mais comment ?

D'où le succès grandissant des DAC asynchrones en environnement informatique

Le DAC n'a pas besoin d'etre asynchrone pour suppprimer le jitter eventuel de la source : il suffit qu'il recadence correctement les données apres les avoir bufferisée.
Ma conclusion reste donc toujours la même, l'horloge de la source et la qualité du cable sont relatifs si le DAC fait correctement son boulot en recadençant le signal.

[robob]

C'est bien ce que je pensais, le discourt sur l'asservissement PPL qui permet s'affranchir du jitter de la source est une demie vérité, c'est surement nécessaire mais pas suffisant.

Ce n'est pas une demi vérité, c'est une bétise : j'ai du mal m'exprimer si tu as compris ça dans mes propos. La PLL permet de récupérer le signal d'horloge SPDIF de la source et ainsi de cadencer le recepteur sur ce signal pour ne pas louper de données en étant parfaitement synchrone (signal SPDIF synchrone).
le Recepteur renvoie ensuite ses données vers la puce de conversion et c'est là que se situe le débat : renvoie t'il les données au rythme de l'horloge SPDIF ou au rythme de sa propre horloge (celle que lui donne le quartz du DAC) ?
Si comme le pense Gerardfma, c'est l'horloge du SPDIF qui est reprise en sortie de la puce receptrice sans autre forme de traitement alors oui, le cadencement du signal source est primordiale.
Si les données sont recadencées en sortie du recepteur avec l'horloge du DAC, on à supprimé le jitter de la source...

...Mais le débat ne s'arrete pas là !
Les donnée en sortie du recepteur sont reçues par le Convertisseur N/A (un PCM1798 sur mon petit DAC) et je n'ai pas encore regardé si celui-ci ne pouvait pas bufferiser les données en entrée avant de les recadencer avec l'horloge du DAC .

J'ai le sentiment qu'au bout on y verra plus claire.

[gerardfma]

Non, le PCM1798 ne peut rien bufferiser, désolé

Le DAC n'a pas besoin d'etre asynchrone pour suppprimer le jitter eventuel de la source : il suffit qu'il recadence correctement les données apres les avoir bufferisée.

S'il y a bufferisation et recadencement, alors le fonctionnement du DAC est forcément asynchrone.
Si tu vois un autre mode de fonctionnement, je suis preneur d'une explication "rationnelle"

Il n'est toujours pas claire pour moi si le CS8416 de mon DAC renvoie les données en sortie cadencées avec son propre quartz

Je répète: le quartz sert à fournir l'horloge de référence à la circuiterie de la PLL, l'horloge qui sert au cadencement entre les échange CS8416 vers PCM1798, est la résultante du calage de la dite PLL sur la fréquence extraite du flux SPDIF ... donc impossibilité d'être "jitter free" sur une architecture de ce type.

La fréquence issue du quartz (en l'occurence c'est un oscillateur, pas un quartz) rentre sur la broche OMCK du CS8416. Tant que la PLL n'est pas "calée" sur la source, c'est à partir de OMCK que sont dérivés OLRCK et OSCLK. Une fois la PLL calée sur la source, c'est à partir de la fréquence "calée", dite RMCK, que sont dérivées les 2 horloges. Je cite:
A special clock switching mode is available that allows the OMCK clock input to automatically replace RMCK when the PLL becomes unlocked.

Comment sont dérivées OLRCK et OSCLK? Dans les 2 cas, c'est une simple division puisque bit rate et word rate, en tout cas à 44.1kHz, sont des sous multiples de 11.2896MHz.

A titre indicatif, Nicolas FERHAT de Audiophonics m'indique que : "Lorsque le DAC est utilisé au dessus de 48khz il utilise l'horloge du signal SPDIF, le quartz n'est plus utilisé. " et "Pour fonctionner en 24/192 il faut retirer le quartz, c'est vrai que c'est un peu contraignant, nous allons essayer d'y ajouter un jumper dans la prochaine version". Ce que je traduis par en 44.1khz, le DAC utilise sa propre horloge.

Au dessus de 48kHz ou à partir de 48kHz? J'aurais tendance à dire à partir, non?
Ce que tu dois traduire, c'est qu'au delà de 48khZ, l'horloge utilisée est purement celle extraite du flux SPDIF, sans aucun référentiel "local" et la PLL est forcément en mode "unlocked".

[robob]

S'il y a bufferisation et recadencement, alors le fonctionnement du DAC est forcément asynchrone.
Si tu vois un autre mode de fonctionnement, je suis preneur d'une explication "rationnelle"

Plus haut lorsque tu parlais des DAC asynchrones tu parlais de transmission asynchrone (USB asynchrone pour les DAC que tu donnes en lien)
Moi je te parle de DAC qui fonctionnent en SPDIF, donc synchrone, mais qui apres la reception du signal, bufferisent les données pour les recadencer à leur propre horloge. Par contre je ne sais pas comment dans ce cas ils comblent un décalage d'horloge constant : c'est pourquoi je te citait le Datasheet du CS8416 ou il est question de répeter la derniere données (et sans doute d' en sauté une dans l'autre sens).

Si la PPL se sert uniquement de l'ocillateur pour fournir l'horloge de référence à sa circuiterie, comment fait -elle si on l'enleve pour fonctionner en 192khz ?
Sinon oui, j'avais bien traduit qu'au dessus de 48khz, le petit DAC était bien dans ce cas asservi par l'horloge de la source (on peut pas tout avoir non plus à ce prix là ).

Quoi qu'il en soit, que mon DAC à 39 € ne soit pas parfaitement implementé c'est tres possible . Mais avant d'aller claquer 200 € dans une Hiface ou un cable SPDIF HDG à 150 €, je prefere d'abord les investir dans un DAC qui supprime le jitter du SPDIF (si on me montre comment, la question est toujours en suspend).