Modérateurs: Modération Forum Installations, Modération Forum DIY, Le Bureau de l’Association HCFR • Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 3 invités

Création câble USB "audiophile"

Message » 09 Sep 2010 17:45

Merci beaucoup Tazz28 pour toutes ces infos mêmes si je dois dire que c'est un peu dense pour moi...

Pour être sûr que j'ai bien compris, tu confirmes que les modes Asynchrone, Synchrone et Adaptatif ne concernent que le transfert des données et n'affecte en rien l'horloge proprement audio, sauf dans le cas hautement improbable (DAC à 5€) où cette horloge audio est calée sur l'horloge de transmission des données usb?

Si c'est le cas, toute l'argumentation des fabricants de DAC "asynchrones" comme étant supérieurs puisqu'ayant une horloge complètement décorrélée des horloges sources et USB n'est que foutaise puisque les autres modes sont déjà décorrélés de la source et de l'usb?
Fyper
 
Messages: 3608
Inscription Forum: 13 Juil 2005 18:05
  • offline

Message » 09 Sep 2010 17:54

ok merci pour l'explication générale du fonctionement de l'USB que j'avais déjà lu à droite ou gauche.
Maintenant, ce qui nous intéresse, c'est ça :
Tazz28 a écrit:- Adaptatif : un mix des deux, comme l'asynchrone, mais avec un controle de flux directement au niveau de l'USB, le device indiquant au host si on peut accélérer ou ralentir la com USB via le endpoint de synchro en lui disant combiens de sample audio mettre par packet USB tout en utilisant la synchro de base des SOF USB.

Comme dit plus haut, le protocole de gestion Windows de l'usb audio ne gère pas l'asynchrone, on se retrouve donc avec un chipset de DAC qui fait de l'adaptatif isochrone.
Le premier inconvénient facile à comprendre, c'est que ce mode ne garantit pas l'integrité des données vu qu'il n'y a pas de renvoie des paquet éronnés. On a le même probleme en HMDI et en SPDIF. Reste à savoir si dans le protocole usb audio, il y a ou non redondance des données. Si oui, au même titre que pour le SPDIF ou l'HDMI, avec un cable de longueur correcte, les données seront integralement préservée car la probabilité qu'une erreur soit multiplié plusieurs fois au moment de la redondance est pratiquement nule. C'est la raison pour laquelle je pense que la qualité d'un cable SPDIF ou HDMI n'a pas beaucoup d'importance et qu'il vaut mieux utiliser le SPDIF pour l'audio (qui deplus est réservé à l'audio, ce qui n'est pas le cas de l'USB qui va gérer en même temps tout un tas d'autres devises).
Le deuxieme inconvénient que nous exposent les vendeurs de cable dit "haut de game" ou d'interface permettant d'utiliser l'usb en mode asynchrone pour ressortir en SPDIF (ce qui ne fait que reporter le probleme :wink: ), c'est ce fameux, mysterieux jitter :mdr: :evil: :mdr: : les impulsions du signal se déplacent ou se dispersent en longueur, entrainant des erreurs en sortie lors de la récupération des données. S'il n'y a de controle d'erreur, il fait comment ton chipset ?
robob
 
Messages: 5925
Inscription Forum: 21 Mar 2007 19:23
Localisation: 95 (coté campagne)
  • offline

Message » 09 Sep 2010 18:50

Fyper, malheureusement, il y a aussi des truc a plus de 5€ qui vont utiliser la même clock pour l'usb et le dac à cause de l'utilisation basique de chipset consumer audio de base a trois kopec, mais tout matos sérieux se doit de décoreller les deux.
Je confirme ta compréhension des choses.
Un DAC avec USB Audio en asynchrone, par nature garanti cette décorrélation donc en théorie garantie cette supériorité. Ce n'est qu'histoire de garantie, mais comme je disait en plaisantant, rien ne leur interdit de l'autre coté d'utiliser le 50hz secteur comme masterclock locale :mdr:

robob, l'intégrité des donnés est garantie par un crc5 pour les headers et un crc16 pour les data ( http://www.usb.org/developers/whitepapers/crcdes.pdf)
Par contre comme on est en isochrone, packet foiré = packet perdu = absence de data pour les samples perdu.
Le fameux jitter est le propre des interfaces synchrones comme le spdif où la clock fait partie intégrante du signal. Les datas sont normalement directement injectés dans le dac car on est en flux tendu synchrone donc ça se fait "nativement".
Pour palier à cela, on re-complexifie tout le bazard sur le haut de gamme en bufferisant et en re-clockant sur une clock locale.
En USB, comme le chip d'interface USB est plus "complexe" car bus asynchrone et clock USB pas du tout stable, on est moins tenté de faire ce genre de chose (clock USB= clock dac).
Par contre, en audio pro, bufferiser et reclocker à outrance n'est pas possible à cause des délai introduits, la liaison en question participant en général à un ensemble beaucoup plus complexe complétement synchronisé.
En utilisation perso, c'est pas un problème et l'USB n'est clairement pas fait pour les utilisations pro.
Enfin, en spdif, j'ai pas vu de code correcteur d'erreur, même pas de CRC mais une simple parité mais j'ai pas creusé. En Hdmi je connais pas donc je m'abstiendrai
.
Tazz28
 
Messages: 2802
Inscription Forum: 03 Nov 2008 23:47
Localisation: Dreux
  • offline

Message » 09 Sep 2010 23:16

Hormis le fait que tout ce qu'a dit Tazz est rigoureusement exact on peut voir les choses de cette manière également.
- Au niveau de l'interface physique, toutes les données sont transférés sur une unique paire différentielle (D+/D-), il n'y aucun autre signal utile genre horloge ou autre mais simplement deux signaux d'alimentation (0 et 5V). ==> pas de transmission de clock.
- Le host (PC) et le device (DAC ou autre) opère chacun de leur coté sur leur propre horloge donc à 2 fréquences 'identiques' à la tolérance prêt de chacune des horloges (la spec USB impose un bit-rate pour le transfert et un nombre de ppm pour la fréquence des horloges de manière à ce que host et device puisse se comprendre. ==> de fait de l'utilisation de 2 quartz, il y aura toujours une différence aussi minime soit-elle entre chacune des fréquences autour de la fréquence nominale avec un certain jitter sur chacune des clocks.
Remarque: la fréquence d'échantillonnage de l'audio peut-être également bien différente de celle de l'USB (ex 44,1kHz).
- l'impact du câble ne peut jouer que sur l'intégrité du signal différentiel (traduit par un diagramme de l'œil dans la spec USB qui définit un certain gabarit à respecter pour le signal) hors ce n'est certainement pas le maillon essentiel - il faut considérer également les caractéristiques du transmetteur et dans une moindre mesure celle du récepteur et de ce point de vue aucun circuit n'est identique (un chipset x aura des résultats différents d'un chipset y avec plus ou moins de marges par rapport au gabarit requis) ==> avec un câble et un périphérique donné, le taux d'erreur durant la transmission des données peut également varier d'un host à un autre. Remarque: la norme USB admet un certain BER théorique variable en fonction de la nature et de la taille des paquets transmis.

Conclusion personnelles:
- est-ce qu'un câble USB quel qu'en soit le prix pourrait garantir aucune donnée erronée durant la transmission: NON.
- En s'attachant simplement à l'intégrité du signal, a quoi bon considérer juste un maillon tel que le câble si celui le plus important à savoir celui du transmetteur différentiel ne peut être contrôlé?

Au final, ma position et que n'importe quel câble certifié USB 2.0 à quelques euros correctement blindé rendra exactement les mêmes services sans différence dans le taux d'erreur que ceux soit-disant audiophiles et THG par ceux qui le vendent.
Eric.D
 
Messages: 1870
Inscription Forum: 05 Juil 2006 12:45
Localisation: dans le 06
  • offline

Message » 10 Sep 2010 8:50

Pour ceux qui veulent réellement trouver un gain pour un dac USB, je conseillerais ceci:

- utiliser un petit boitier USB qui réalise l'isolation galvanique du DAC par rapport au PC. On en trouve en kit sur internet a pas trop cher.
- utiliser une alimentation externe de bonne qualité a la place de celle du bus USB.
apolon34
 
Messages: 2176
Inscription Forum: 24 Mar 2003 15:57
Localisation: Rouen (76)
  • offline

Message » 10 Sep 2010 9:53

Presque tout à fait d'accord avec cette conclusion :
Eric.D a écrit:Conclusion personnelles:
- est-ce qu'un câble USB quel qu'en soit le prix pourrait garantir aucune donnée erronée durant la transmission: NON. (SI, si le protocole permet le renvoie des données eronnées)
- En s'attachant simplement à l'intégrité du signal, a quoi bon considérer juste un maillon tel que le câble si celui le plus important à savoir celui du transmetteur différentiel ne peut être contrôlé?

Au final, ma position et que n'importe quel câble certifié USB 2.0 à quelques euros correctement blindé rendra exactement les mêmes services sans différence dans le taux d'erreur que ceux soit-disant audiophiles et THG par ceux qui le vendent.


Conclusion n°2 :
Mais il n'en reste pas moins que le protocole de transmission est imparfait contrairement aux protocoles réseaux informatiques, qu'il y a bien un risque de pertes de données (aussi minime soit-il). Idéalement, il faudrait un protocole de transmission totalement asynchrone avec renvoie des données éronées, ce qui est parfaitement faisable aujourd'hui concernant l'audio, vu les débits maximums atteints.

Concernant le mode de transfert "adaptatif isochrone", je ne sais toujours pas si lorsqu'une erreur est detectée (crc ou controle de parité), le protocole prevoit l'envoie de donnée redondante ce qui lui permet de "remplacer" les erreurs. Je sais que c'est le cas avec l'HDMI (procédé TMDS) ou les données sont multiplexées sur 3 canaux avec des redondances : cela conforte encore plus l'idée que la qualité, pour le cable HDMI, importe peu. Dans le cas de l'USB audio (voir du SPDIF, je n'ai pas trouver non plus de doc concernant la redondance des données en AES/EBU), cela voudrait dire que toute erreur de transmission est une donnée perdu : en effet, que le chipset du DAC detecte une erreur, ok, mais s'il ne peut pas la corriger quel interet ?
Une bonne idée serait (pour les développeurs de la section DIY :wink: ) d'intégrer au circuit d'un DAC un compteur d'erreur (je suppose que le chipset doit sortir cela sur une de ses broches). Cela permettrait de voir "numériquement" quel est le nombre d'erreurs et quel est l'impact d'un changement de cable (tres long par exemple). Cela serait plus "parlant" que les constatations auditives des testeurs en herbe que nous sommes :mdr: .

En attendant, désolé les gars, mais vous n'avez pas prouvé aux perfectionistes (dont je ne suis pas :roll: ) l'inutilité d'acheter un cable USB blindé Iron Man avec connecteur en or massif 150 carats, vu que celui-ci a tout de même le potentiel d'éviter une ou deux erreurs :mdr: :mdr: .
robob
 
Messages: 5925
Inscription Forum: 21 Mar 2007 19:23
Localisation: 95 (coté campagne)
  • offline

Message » 10 Sep 2010 10:29

Isochrone -> pas de réémission des data erronés.
Oui du full asynchrone permet la réémission des data, mais le rapport complexité avantage est quasi null et nécessite une gestion de gros buffer donc augmentation de la latence etc ...
L'USB est électriquement un bus différentiel est est plutôt robuste. Un cable de bonne qualité tout simple suffit pour n'avoir une erreur que tous les 36 du mois sur de la data audio.
Et je suis d'accord, un truc en USB dit Hifi se doit de compter et d'afficher d'une manière ou une autre les erreur USB pour éviter les surprises, mais ça péterait le marché des câbles blindés à la kryptonite :mdr:
L'intérêt de détecter l'erreur est d'éviter d'envoyer de la merde au DAC. Soit t'envoie l'échantillon précédent soit tu fait une interpolation par rapport aux précédents et ça devrai passer sans t'écorcher les oreilles.
Tazz28
 
Messages: 2802
Inscription Forum: 03 Nov 2008 23:47
Localisation: Dreux
  • offline

Message » 10 Sep 2010 11:25

Tazz28 a écrit:L'intérêt de détecter l'erreur est d'éviter d'envoyer de la ***** au DAC. Soit t'envoie l'échantillon précédent soit tu fait une interpolation par rapport aux précédents et ça devrai passer sans t'écorcher les oreilles.

Justement, à ce sujet j'avais eu une discussion concernant l'upsampling. La question était parallèle au sujet présent : diminuer les erreurs causées par le transfert audio du SPDIF. Si le chipset du DAC peut accepter le 192khz, peut-être que l'upsampling des données au niveau logiciel (PC) en passant de 44.1 à 192 pouvait permettre d'améliorer le signal, car il y aurait 4 fois plus d'échantillon traité par le DAC et que dans ce cas, pour chaque erreur, l'échantillon précédent ou l'interpollation serait plus proche de l'echantillon manquant. Je sais que c'est un peu raccourci comme idée, mais le débat n'avait pas aboutit et la réponse reste en suspend. Mais cela revient toujours au probleme de départ : combien d'erreurs ? est-ce utile de s'en soucier ? quelle impact peut avoir ces erreurs par rapport à la qualité de traitement des amplis OP en sortie du DAC ?
robob
 
Messages: 5925
Inscription Forum: 21 Mar 2007 19:23
Localisation: 95 (coté campagne)
  • offline

Message » 10 Sep 2010 11:50

Faut demander a apolon34 si il a pu compter les erreur USB en sortie de l'interface USB sur son dac.
Ça doit être totalement anecdotique a mon avis mais mériterait la confirmation d'un cas réel.
Tazz28
 
Messages: 2802
Inscription Forum: 03 Nov 2008 23:47
Localisation: Dreux
  • offline

Message » 10 Sep 2010 13:05

et même s'il y a des erreurs .. n'y a t'il pas de protocole qui redemande l'info ???? Ca m'étonerai qu'il n'y a pas une couche supérieure qui assure la qualité au niveau application.
Bossant dans les telecom, je serais très surpris qu'il n'y ait rien a ce niveau.

EDIT : début de réponse :
http://www.abcelectronique.com/acquier/usb3_fr.htm

la suite:
http://www.abcelectronique.com/acquier/usb4_fr.htm

Ma comprehension est que l'audio devrait être envoyée en mode isochrone ... et donc on ignore les erreurs de CRC/ on ne fait pas de reprise sur erreur.

Conclusion, Si on respecte les longueurs std, il n'y a pas de raison qu'un cable fasse un meilleur son qu'un autre (sauf cas extrèmes de perturbations ...). En gros si on n'a pas un son mauvais (coupures) avec un cable c'est que ce sera pareil avec tous les autres cables normaux USB de la planete. >> pour moi il n'y aura en théorie pas d'impact. - En clair ca passe ou ca passe pas - et cela s'entend en 10secondes.
Yuli_35
 
Messages: 2648
Inscription Forum: 11 Aoû 2006 17:17
Localisation: Rennes
  • offline

Message » 10 Sep 2010 14:55

Tazz28 a écrit:Faut demander a apolon34 si il a pu compter les erreur USB en sortie de l'interface USB sur son dac.
Ça doit être totalement anecdotique a mon avis mais mériterait la confirmation d'un cas réel.


Non et je ne crois pas que cette info soit disponible au niveau du pcm2704 que j'utilise.

Mon dac se compose comme ceci:

usb -> pcm2704 alimenté par le bus -> spdif -> transfo isolation -> cs8416 -> fifo -> dac.
La gestion de l'horloge fifo est assurée par un pic qui surveille les états presque plein/presque vide et agit sur un dac qui agit sur la tension de commande d'un vcxo, qui agit sur l'horloge de lecture de la FIFO.

Ca semble complexe mais en réalité pas tant que ça et ça fonctionne extrêmement bien.
apolon34
 
Messages: 2176
Inscription Forum: 24 Mar 2003 15:57
Localisation: Rouen (76)
  • offline

Message » 10 Sep 2010 15:13

Fabien,

Ta fifo agit en série au niveau bit?

Tu as mis ce projet sur ton site? Je ne l'ai pas trouvé.
C'est super interressant!

Philippe
Philby
 
Messages: 9819
Inscription Forum: 12 Mar 2001 2:00
Localisation: 33
  • offline

Message » 10 Sep 2010 15:26

Salut Philippe,

Il n'est pas en ligne sur mon site, j'ai eu la flegme.

La fifo est effectivement en mode série et stocke les datas, le lrck et le bck pour que les signaux restent synchronisés.

Sujet visible ici: viewtopic.php?f=1054&t=29882749&hilit=pcm1704
apolon34
 
Messages: 2176
Inscription Forum: 24 Mar 2003 15:57
Localisation: Rouen (76)
  • offline

Message » 10 Sep 2010 15:36

apolon34 a écrit:Salut Philippe,

Il n'est pas en ligne sur mon site, j'ai eu la flegme.

La fifo est effectivement en mode série et stocke les datas, le lrck et le bck pour que les signaux restent synchronisés.

Sujet visible ici: viewtopic.php?f=1054&t=29882749&hilit=pcm1704


Purée!!!!
J'avais complètement zappé ce topic!!!
Super boulot !
Je vais lire ça de plus près.
Philby
 
Messages: 9819
Inscription Forum: 12 Mar 2001 2:00
Localisation: 33
  • offline

Message » 10 Sep 2010 15:38

Voilà un exemple de chip à utiliser pour faire un interfaçage sérieux d'un DAC en USB:
http://www.cypress.com/?rID=38801
EZ-USB FX2LP™ USB Microcontroller High Speed USB Peripheral Controller
Features (CY7C68013A/14A/15A/16A)
* USB 2.0 USB IF High Speed Certified (TID # 40460272)
* Single Chip Integrated USB 2.0 Transceiver, Smart SIE, and Enhanced 8051 Microprocessor
* Fit, Form, and Function Compatible with the FX2
o Pin compatible
o Object code compatible
o Functionally compatible (FX2LP is a superset)
* Ultra Low Power: ICC No More than 85 mA in any Mode
o Ideal for bus and battery powered applications
* Software: 8051 Code Runs from:
o Internal RAM, which is downloaded through USB
o Internal RAM, which is loaded from EEPROM
o External memory device (128 pin package)
* 16 KBytes of On-Chip Code/Data RAM
* Four Programmable BULK, INTERRUPT, and ISOCHRONOUS Endpoints
o Buffering options: double, triple, and quad
* Additional Programmable (BULK/INTERRUPT) 64 Byte Endpoint
* 8-Bit or 16-Bit External Data Interface
* Smart Media Standard ECC Generation
* GPIF (General Programmable Interface)
o Enables direct connection to most parallel interfaces
o Programmable waveform descriptors and configuration registers to define waveforms
o Supports multiple Ready (RDY) inputs and Control (CTL) outputs
* Integrated, Industry Standard Enhanced 8051
o 48 MHz, 24 MHz, or 12 MHz CPU operation
o Four clocks per instruction cycle
o Two USARTs
o Three counter/timers
o Expanded interrupt system
o Two data pointers
* 3.3V Operation with 5V Tolerant Inputs
* Vectored USB Interrupts and GPIF/FIFO Interrupts
* Separate Data Buffers for the Setup and Data Portions of a CONTROL Transfer
* Integrated I2C Controller, Runs at 100 or 400 kHz
* Four Integrated FIFOs
o Integrated glue logic and FIFOs lower system cost
o Automatic conversion to and from 16-bit buses
o Master or slave operation
o Uses external clock or asynchronous strobes
o Easy interface to ASIC and DSP ICs
* Available in Commercial and Industrial Temperature Grade (all packages except VFBGA)
Functional Overview
Cypress’s EZ-USB FX2LP™ (CY7C68013A/14A) is a low power version of the EZ-USB FX2™(CY7C68013), which is a highly integrated, low power USB 2.0 microcontroller.


En rouge les fonctionnalités primordiales.
Il est d'ailleurs utilisé sur la carte de demo ESS pour les ES9008 ....
Faut coder un peu, mais vu la bête, il permet de gérer tout le dac : afficheur, commutation des entrés etc ... (surtout si on colle une paire de 9018 derrière :mdr: )
Tazz28
 
Messages: 2802
Inscription Forum: 03 Nov 2008 23:47
Localisation: Dreux
  • offline


Retourner vers Câbles