DAC R2R DENAFRIPS TERMINATOR (et les autres)

[GuileZ_]

C'est clair faux débat, pour avoir une lecture de CD correcte il faut mettre le K€ pour limiter les corrections d'erreurs et Cie.
La démat' on s'affranchi des très nombreux défauts des lecteurs physiques.

[FDDRT]

Oui car en TCP (pas en UDP !), l'intégrité de l'information est garantie.
En vulgarisant, 2 cas:

Quand tout va bien:


Quand il y a un problème (bien souvent sur la couche transport):

TCP est la couche transport. Les problèmes sont souvent sur les couches inférieures (réseaux ou physique).

Ce n'est pas le mécanisme d’acquittement qui permet de garantir l'intégrité de la transmission. L'acquittement permet juste de garantir que toutes les trames envoyées ont bien été reçues. Cela ne garantie pas que ce qui a été reçu est identique à ce qui a été envoyé.

Ce sont les sommes de contrôle inclus dans les trames TCP qui garantissent l'intégrité de la transmission.

Toutefois, même si la transmissionest "garantie", il est toujours possible d'avoir des problèmes de lecture liés à la transmission de données.

[Steph-Hifi]

des pbs de lecture liés à la transmission de données ? je ne comprend pas ce que tu dis tu peux développer ?

dans TCP, si le matériel est défaillant le transport n'est pas acquitté et les paquets sont en erreur... on est bit perfect garantie de bout en bout.

[Adhara]

Oui car en TCP (pas en UDP !), l'intégrité de l'information est garantie.
En vulgarisant, 2 cas:

Quand tout va bien:


Quand il y a un problème (bien souvent sur la couche transport):

TCP est la couche transport. Les problèmes sont souvent sur les couches inférieures (réseaux ou physique).

Ce n'est pas le mécanisme d’acquittement qui permet de garantir l'intégrité de la transmission. L'acquittement permet juste de garantir que toutes les trames envoyées ont bien été reçues. Cela ne garantie pas que ce qui a été reçu est identique à ce qui a été envoyé.

Ce sont les sommes de contrôle inclus dans les trames TCP qui garantissent l'intégrité de la transmission.

Toutefois, même si la transmissionest "garantie", il est toujours possible d'avoir des problèmes de lecture liés à la transmission de données.

C'est le checksum qui permet l'intégrité (MD5, hash, ..) qui est intégré au protocol TCP ! Il y a acquittement si et seulement si le checksum est ok, sinon il y a réémission de la trame.
En cas de problème c'est bien souvent du à ce qu'il y a entre l'émetteur et de récepteur (câble, switch, routeur...) et cela se vérifie très facilement (avec les bons outils d'analyse).

[Adhara]

des pbs de lecture liés à la transmission de données ? je ne comprend pas ce que tu dis tu peux développer ?

dans TCP, si le matériel est défaillant le transport n'est pas acquitté et les paquets sont en erreur... on est bit perfect garantie de bout en bout.

Il n'y a pas de problème mais quelqu'un à dit (page précédente) que la transmission des data via IP en audio n'était pas fiable ni qualitative. Ce qui est absolument faux.
Le but était de démontrer/expliquer la fiabilité de la transmission de paquets sur protocole TCP/IP.

Personnellement il est impossible de différencier un flux streamé (16/96) d'un flux CD donc support physique (16/96) [ je parle avec une électronique de qualité équivalente dans les 2 cas de figure]
Après je le conçois, il y a eu un choc culturel entre le passage de la cassette et du vinyle...au CD et plus largement aux flux numériques.

[Steph-Hifi]

effectivement c'est plus que faux, c'est exactement comme dire que si je transfert un autre type de fichier d'un ordinateur a un autre je pourrais sur word perdre des lettres, sur excel perdre des chiffres, sur une photo perdre des couleurs...

TCP est tellement robuste que tout l'internet Protocol IP se base dessus et transfert tous les jours des milliards et des milliards de fichiers, de mails, de photos, de vidéo, des sommes d'argents etc.. sans la moindre perte

alors que jouer un CD sur un lecteur CD c'est TOUT l'inverse vu que la lecture se fait en synchrone a savoir la musique se fait en temps réel pendant la lecture, si jamais une erreur de lecture se produit, les bits manquant sont interpolés (inventé) via le redbook cd. A part de tres rare lecteur, la lecture d'un CD musical n'est pas garantie bit perfect.

[FDDRT]

Et malgré tout, le protocole TCP seul ne permet pas de garantir la lecture d'un flux audio sans erreur !

[Steph-Hifi]

TCP est un tuyau, sans fuite, sans nœud, sans perte etc..

par contre un tuyau seul ne fait rien certe, mais il serait "sain" de mettre le ola a tout ce qui pourrait faire croire a ce que TCP pourrait être un problème dans une chaine audio numérique, au contraire c'est un gage de perfection dans le transport numérique.

d'ailleur ce n'est pas un hasard si le systéme de routing audio numérique le plus perfectionné du moment (DANTE) se base dessus (et l'utilise en temps réel)
https://en.wikipedia.org/wiki/Dante_(networking)

[ohl]

alors que jouer un CD sur un lecteur CD c'est TOUT l'inverse vu que la lecture se fait en synchrone a savoir la musique se fait en temps réel pendant la lecture, si jamais une erreur de lecture se produit, les bits manquant sont interpolés (inventé) via le redbook cd. A part de tres rare lecteur, la lecture d'un CD musical n'est pas garantie bit perfect.

là c'est plutôt un mythe audiophile !
La lecture CD n'est pas du tout synchrone : il y a de gros buffers pour remettre les données dans l'ordre et éliminer les erreurs éventuelles.
Il y a toujours des erreurs C1 et C2 totalement corrigeables et généralement très très peu d'interpolations, même dans un lecteur CD d'autoradio. Il suffit d'avoir les CD assez propres....

Pour l'audio sur IP (Dante, AES67), ce n'est généralement pas du TCP mais du RTP sur UDP. Ce qui est évidemment moins sûr pour l'intégrité des données mais en pratique, ça marche très bien.

[jacko]

... pourtant il suffit de pas grand chose pour qu'un rip de CD sur PC sous Jriver puisse avoir des erreurs.
J'en ai eu plusieurs nécessitant de refaire le rip.

[Steph-Hifi]

absolument il ne faut pas oublier la qualité du support, son etat, etc.. je me souviens sur itunes en cochant la correction d'erreur sur les rip bien souvent entendre le moteur pas a pas de la tete laser insister pendant plusieurs secondes sur certains passage.

mais oui je dois avouer que j'ai forcé le trait "MAIS" il y a bien plus de légendes urbaines qui vont a l'encontre de la dématérialisation alors le CD n'est que le "simple" support d'un fichier informatique et que le copier et le faire transiter sur un autre support via TCP/IP peut etre 100% bit perfect et qu'il n'y a plus aucun intérêt de penser qu'un lecteur CD sera meilleur qu'un système dématérialisé. Surtout maintenant avec les dac USB asynchrone modernes , c'est lui qui fait tout le job et pas vraiment ce qui est en amont.

après qu'on s'attache a l'objet, a son lecteur et a son bouton play et/ou sa télécommande je peux le comprendre sans soucis.

[FDDRT]

TCP est un tuyau, sans fuite, sans nœud, sans perte etc..

par contre un tuyau seul ne fait rien certe, mais il serait "sain" de mettre le ola a tout ce qui pourrait faire croire a ce que TCP pourrait être un problème dans une chaine audio numérique, au contraire c'est un gage de perfection dans le transport numérique.

d'ailleur ce n'est pas un hasard si le systéme de routing audio numérique le plus perfectionné du moment (DANTE) se base dessus (et l'utilise en temps réel)
https://en.wikipedia.org/wiki/Dante_(networking)

Non, TCP n'est pas un tuyau... et n'est pas sans perte. Mais ce n'est pas cela qui le rend théoriquement inapproprié pour la transmission audio live: le protocole TCP ne garantie pas la latence !

C'est pour cela que Dante ne s'appuie pas sur TCP, mais, au contraire, est un autre protocole qui se situe au même niveau que TCP (en concurrent , en quelque sorte, couche 4 du modèle OSI).

Mais ce n'est pas aussi simple en pratique... Dante utilise beaucoup de ports:
https://www.audinate.com/learning/faqs/which-network-ports-does-dante-use

Par exemple, pour découvrir tous les appareils sur le réseau qui sur compatible Dante, Dante s'appuie sur le multicast DNS. C'est le seul service utilisé qui s'appuie sur TCP pour qu'un réseau Dante fonctionne. Sinon, Dante se passe de TCP.

L'avantage de Dante, c'est qu'il comble la lacune principale de TCP: Dante garantie une latence (programmable selon les appareils et le réseau). Une limitation parmi d'autres, Dante est limité à 7 sous-réseaux. Une autre limitation est qu'il n'accepte pas les liaisons radio (wifi, BT, ...), ce qui facilite beaucoup pour garantir une faible latence !

Bref, TCP, Dante, le wifi, .... peuvent poser des problèmes .... c'est rare mais ça peut arriver ! Cela ne remet pas en cause pour autant la solution, c'est parfaitement viable la plupart du temps.

[Steph-Hifi]

oui mais on se fout de la latence dans le cadre d'une transmission asynchrone ! a ce stade on est pas en temps réel (dante l'est raison pour laquelle il passe en UDP)
on est aussi forcement bit perfect sauf panne matériel car TCP/IP est utilisé dans le cadre d'un reseau doméstique trés simple avec un routeur internet (la box) et en général 1 ou 2 switch; effectivement les paquets perdus peuvent exister, mais la encore en asynchrone, ils finiront, sauf panne materiel toujours par arriver sans perte.

et tout sela est infiniment plus robuste qu'un support optique a la lecture temps réel qui est dependant de la qualité du support et d'une mecanique en mouvement.

[Adhara]

oui mais on se fout de la latence dans le cadre d'une transmission asynchrone ! a ce stade on est pas en temps réel (dante l'est raison pour laquelle il passe en UDP)
on est aussi forcement bit perfect sauf panne matériel car TCP/IP est utilisé dans le cadre d'un reseau doméstique trés simple avec un routeur internet (la box) et en général 1 ou 2 switch; effectivement les paquets perdus peuvent exister, mais la encore en asynchrone, ils finiront, sauf panne materiel toujours par arriver sans perte.

et tout sela est infiniment plus robuste qu'un support optique a la lecture temps réel qui est dependant de la qualité du support et d'une mecanique en mouvement.

Surtout quand on parle TCP/IP ne pas oublier la nation de buffer (la mémoire tampon si on veut)... Coupez un flux streamé, vous allez encore avoir 20s/30s de musique disponible.
La lecture commence à s'exécuter quand le buffer est plein. Il n'y a donc pas de latence (sauf coupure prolongée).

[FDDRT]

oui mais on se fout de la latence dans le cadre d'une transmission asynchrone !

... jusqu'au moment où cela devient un problème !

a ce stade on est pas en temps réel (dante l'est raison pour laquelle il passe en UDP)

Dante n'est pas un protocole temps réel. Et, par construction, on ne peut pas concevoir un protocole temps réel en s'appuyant sur UDP (qui ne l'est pas non plus).
Il existe un protocole temps réel s'appuyant sur IP (et UDP ou TCP): c'est RTP (real-time protocole). Mais celui-ci ne peut fonctionner réellement en temps réel seulement si l'ensemble des machines interconnectées fonctionnent uniquement sous ce protocole.

Surtout quand on parle TCP/IP ne pas oublier la nation de buffer (la mémoire tampon si on veut)... Coupez un flux streamé, vous allez encore avoir 20s/30s de musique disponible.

Les buffers sont par défaut à 8KB. Je doute que cela soit suffisant pour 20/30s de musique PCM. Peut-être confonds-ru le tampon TCP avec le tampon applicatif ?

La lecture commence à s'exécuter quand le buffer est plein. Il n'y a donc pas de latence (sauf coupure prolongée).

Là il s'agit du buffer applicatif, rien à voir avec le buffer TCP.

Mon application de lecture (Moode Audio) commence bien avant que le buffer applicatif soit plein. En fait, le démarrage est "instantané" si mon réseau est bien configuré, sinon il y a un petit délai.