DAC - Questions "basiques"

[J-C.B]

Bonsoir,
Dans cette partie de l'audio, je suis largué. Ce n'est pas pour autant que je n'en connaisse pas les fondements , mais les solutions adoptées et les évolutions me sont méconnues.
Puisque ce fil se veut basique, ne serait il pas possible que chacun fasse un effort pour être compréhensible.
Un glossaire des principaux termes, un synoptique montrant les fonctions utilisées , voir l'évolution du traitement du signal (heu! des différents signaux possibles) , serait le bienvenu. Il permettrait , je le crois fermement de synchroniser les connaissances et ainsi de profiter à tous.
Cordialement

[sdf]

* ...

* Liaison filaire ou non ?
On revient un peu sur les "entrées". L'ajout d'un module pour lire en Wifi n'est pas une mince affaire si je regarde ce qui s'est fait. Avantages et inconvénients de cette liaison par rapport à une liaison filaire style Coax ou AES.XLR ?


...

Salut, de quoi parles-tu? Tu parles d'un airport express par exemple???

[breizheau]

Oui. Qu'est-ce qui serait le "meilleur" : liaison en éthernet filaire, AEN ou un câble coaxial ?

[sdf]

Je pense que la qualité des diverses liaison est équivalente!

[Tazz28]

Elles sont surtout pas comparables:
D'un coté on a des liaisons synchrones : spdif-AES/EBU (fibre, Coax ou XLR), I2S , sdif2 et 3.
D'un autre des liaisons asynchrones venant du monde informatique: ethernet, wifi, usb.

Chaque domaine/monde a ses propres problématiques, défauts et applications de prédilections mais quoi qu'il en soit, le circuit de conversion final travaille en synchrone et on aura à un moment ou un autre le passage du monde asynchrone ver le monde synchrone pour entrer en pcm ou dsd dans le circuit final DAC.
Donc correctement implémentés, elles sont équivalentes. (toute la nuance est dans le correctement ...)

Une bonne liaison asynchrone est complexe à mettre en œuvre en comparaison d'une liaison synchrone dans 99,9% des cas/applications Hifi et grand public.

[alkasar]

Oui. Qu'est-ce qui serait le "meilleur" : liaison en éthernet filaire, AEN ou un câble coaxial ?

Je pense que la qualité des diverses liaison est équivalente!

Pas tout a fait équivalents, mais au final je pense comme toi

AEN ? je connais pas.
Une transmission wifi ou CPL bénéficie d'une correction d'erreur rudimentaire mais efficace. En ethernet filaire, c'est à l'équipement terminal de contrôler l'intégrité. A ma connaissance, tous le font.
Sauf erreur irrécupérable qui occasionne des coupures de signal (on a tous expérimenté un appareil wifi à la limite de la portée), cette partie de la transmission est sans perte. Pour implémenter proprement en audio, faut un buffer qui créé un délai.

Un transport numérique "audio" spdif, que ce soit sur cable coax ou optique, peut avoir des pertes. Pas de correction d'erreur dans le protocole. Sur le papier, c'est moins bien.

Bien que n'ayant jamais creusé la question, je parierai cependant que les erreurs éventuelles dues au moyen de transport proprement dit sont négligeables par rapport aux autres soucis comme le jitter par exemple.

Le "meilleur" choix du transport se fera amha sur d'autres critères : la distance entre source numérique et dac, facilité d'accès, etc. Pour écouter dans le jardin le lecteur de CD du salon, vaut mieux un récepteur wifi upnp qu'un appareil filaire spdif


Pour imaginer le dac idéal, une entrée spdif reste undispensable car c'est le plus classiquement rencontré, et une entrée I2S. Libre à chacun de choisir le moyen d'apporter le signal I2S au dac (usb, borne wifi, etc.)

[Tazz28]

Je suis d'accord, sauf pour les détails concernant CPL WIFI et Ethernet.
Ces derniers intègrent TOUS des systèmes de détection et corrections d'erreur au niveau PHYS/MAC plus ou moins rudimentaires et AUCUN ne garantie la non perte de donnée et leur totale intégrité.
C'est le boulot des protocoles de niveau supérieur que de garantir tout le reste à coup de check d'intégrité, retransmission, remise en séquence etc ....
Dans les trois cités, le wifi (lequel en plus, a,b,g,n ?) est un non sens du point de vue de toutes techno réseau modernes. Un grand nombre de problématiques fondamentales sont éludés et ignorées donnant un truc qui tombe a peu près en marche, ce qui va très bien pour du "consumer product". C'est pas juste parce qu'il y a des perturbations radio que ça merdouille grave des fois ou que ça fait des truc bizarre. C'est by design ....
Le CPL est très proche de l’Ethernet, sauf que la couche PHYS/MAC est ... comment dire, fallait oser une hérésie pareille. Outre le pourrissage de tout son réseau électrique et la génération de perturbation électromagnétiques de manière totalement non maitrisé/maitrisable (on aime ou pas), le médium étant non maitrisé/borné, ça marche bien, ou pas.
Tout ça pour dire que tout n'est pas noir ou blanc, c'est un peu plus compliqué, et que le plus adapté est toujours une histoire de compromis en fonction de la situation/domaine d'application comme pour le choix synchrone spif/i2s et l’asynchrone de haut niveau. Fin de la digression.

[Bobo le Chat]

Hello
Intéressante discussion, continuez
AEN je le traduirais en airport express numérique, cad liaison wifi/n ou ethernet sortie en toslink/analogique ou mieux en i2s voir les travaux d'Alex_tw viewtopic.php?p=174959853#p174959853 et suivant donc liaison wifi ou ethernet i2s dac
Amicalement
Roger

[breizheau]

Oui pardon..... AEN=Airport Express Wifi "N" comme me l'a dit Alex dans un MP.

[breizheau]

Je pense que cette liaison ne doit pas être trop mal.

Après !a, il faut créer la partie qui puisse commander le DAC pour qu'il puise les infos dans le NAS.....sujet que l'on peut débattre dans un autre sujet.

Que pensez-vous du 1794 en DAC ? Des conseils pour le "truc" qui est avant : DIR9001, CS841x ?

Quel est le rôle du PDM100 par exemple et celui de justement de ces CS841x ou autre DIR ?

Comment exploiter les possibilités des "DAC" en eux même ?

[alkasar]

Hello
Intéressante discussion, continuez
AEN je le traduirais en airport express numérique, cad liaison wifi/n ou ethernet sortie en toslink/analogique ou mieux en i2s voir les travaux d'Alex_tw viewtopic.php?p=174959853#p174959853 et suivant donc liaison wifi ou ethernet i2s dac
Amicalement
Roger

c'est cool ce qu'a fait alex en effet pour attraper l'I2S à l'intérieur de l'airport express (1). Ca évite un codage/décodage spdif et une partie des soucis d'horloge.
Pour moi, je dissocie ça du dac. C'est un moyen de ramener le signal numérique jusqu'au dac de la façon la plus appropriée possible.
Un receveur USB qui transforme en I2S en est un autre, qui évite les soucis du wifi mais qui a les contraintes liées à USB. Rien n'est parfait.


Tazz on sent ta frustration sur ces protocoles pas complètement aboutis on peut quand même dire que wifi même si c'est bordélique, quand ça passe, on arrive à obtenir des trames à 100% justes.


(1)Je trouve que l'airport express est un superbe hardware avec le défaut d’être de chez la pomme avec le gros virus itunes jamais très loin La même bidouille sur un autre receveur wifi upnp m'intéresserait bien plus Ce doit etre faisable sur d'autres hardwares. Reste à trouver le diyer talenteux qui le fera avec une squeezbox ou autre.

[alkasar]

Que pensez-vous du 1794 en DAC ? Des conseils pour le "truc" qui est avant : DIR9001, CS841x ?

Quel est le rôle du PDM100 par exemple et celui de justement de ces CS841x ou autre DIR ?

Comment exploiter les possibilités des "DAC" en eux même ?

là tu rentre dans les choix de conception du dac.

Pour faire archi simple (on est dans les basiques n'est ce pas) en commencant par la fin :
-la puce dac (ad1955,wm8740,...) prend en entrée un flux numérique PCM ou DSD(ceux des CD/DVD ou SACD) ou I2S + une horloge et sort de l'analogique.

-avant le dac, il y a un Digital Receiver (dir9001,WM8805,...) qui reçoit le flux numériques en spdif ou I2S, se démerde pour l'horloge*, et convertit en pcm ou dsd.

-encore avant, il peut y avoir un sélecteur de source, ou une autre puce qui convertit spdif en I2S ou usb->spidf ou usb->i2s selon les choix.

Il y a aussi des puces dac qui prennent directement un flux I2S en entrée, ce qui permet de zapper le receiver. Il y a aussi des puces qui contiennent plusieurs de ces étages, ou même qui font tout en un !

En sortie, certaines puce dac n'ayant qu'une sortie en courant, il faut un étage de conversion I/V. En général on finit par un filtre/buffer de sortie si le dac ne peut pas driver la charge attendue.

(*)L'horloge est le plus grand bazar dans tout ça. Il y a des centaines de pages dans la littérature juste la-dessus et je ne maitrise pas assez pour pouvoir simplifier. Max (IIII) aborde la question plus haut. On comprend que le dac a besoin d'une horloge et que la source en une forcément aussi. Comment être toujours parfaitement synchrone ?

A chaque étage t'as des choix et aussi pour l'architecture globale : un seul ou plusieurs dacs en // pour améliorer rapport S/B ? doubler pour sortie symétrique ? etc.

Les dacs eux même peuvent travailler en 16, 24 ou 32, 64 bits et a des fréquences 44,1, 48, 96 ou 192kHz. Ils peuvent etre mono, stero, multicanal.

Certaines cartes oversample. Le signal source arrive en spdif 16/44.1 par exemple et il est convertit en 24/96 ou 24/192 par sur-échantillonnage avant l'entrée dans le dac. L'oversampling peut être systématique ou débrayable.


Et l'avenir est sans doute à des puces intégrant receiveur + dsp + controle de volume + dac. C'est déjà là chez ST (DDX) et TI (Purepath) et sans doute d'autres que je ne connais pas.


En fait, je m'aperçois qu'il est difficile de simplifier, tant les options sont nombreuses:)

[breizheau]

Merci Alain pour ces précisions.

[Tazz28]

Tazz on sent ta frustration sur ces protocoles pas complètement aboutis on peut quand même dire que wifi même si c'est bordélique, quand ça passe, on arrive à obtenir des trames à 100% justes.

Encore heureux

[Tazz28]

Alkasar a bien survolé la chose. Il manque juste la partir filtrage numérique qui historiquement était externe puis interne et optionnellement externe.
Dans les filtrages pouvant être intégrés, on atteind l'ultra complet dans les sabres32 de ESS : FIR complètement programmable pour l'oversampling, filtre de de-emphasis pour les signaux PCM/spdif, et filtre numérique final (IIR) sharp/slow roll off pour le PCM et 47 50 60 ou 70 Khz pour le DSD.
Les puces tout intégrés genre celles cité comme DDX, purepath ou Sabre32 sont une évolution certaine et intéressante: receiver tout format intégré, système d'élimination de Jitter et de reclocking, overdampling, filtrage, controle de volume dac multiples, stackables et nativement sysmétriques à sortie en I ou en V et j'en passe. Dans le cas de l'ESS, on aboutit a une architecture très intéressante, dont la masterclock est complètement asynchrone et indépendante du clocking des signaux d'entrée.
Par contre, ces puces ne sont pas applicables à tout. Elles sont par exemple complètement impropres à une utilisation en audio pro car le délais de propagation du signal est difficilement maitrisable/déterministe et donc difficilement intégrables dans une chaine de traitement numérique globale.
C'est pour cela que AKM règne en maitre dans l'audio pro : PCM ou DSD, de-emphasis oversampling simple + filtrage avec option externe, masterclock synchrone à celle du signal d'entrée le tout dans un soucis de minimiser et fixer le délais de propagation et avec des perfs finales en DNR et THD+N carrément pas dégeu (et pas pipeautées) , des boitiers avec pas trop de pinoche et facile a mettre en œuvre.
Par contre, pas d'entrés multiples commutables, stéréo stackable mono (a comparer au 8 voies de l'ess) , pas de spdif, ni de décodage des info spdiff, pas de antijitter/reclocking, pas de filtre programmable ni techno d'oversampling un peu tordu, etc ...

Sur l'ensemble en détaillant les choix/options/techniques/applications des différents blocs fonctionnels évoqués, y a de quoi en écride des bouquins entiers Va falloir structurer tout ça sinon on va partir dans tous les sens (on a déjà bien commencé )