Création câble USB "audiophile"

[apolon34]

Par rapport a un chip comme le pcm2704, c'est plutôt un genre de microcontroleur/dsp usb. Il faut se taper le programme de la puce et le driver usb pour le pc. Pas à la portée de tout le monde malheureusement.

[Tazz28]

Oui, il faut se taper le prog du micro-contrôleur, mais ça fait un tout en un pour un DAc complet sur lequel on veut gérer un afficheur et ou on a besoin d'I2C. Par contre rien a faire coté PC, il "suffit" d'implémenter la classe USB Audio.

[Tazz28]

Chez TI tu as aussi le TAS1200B ou le TUSB3200A qui implémentent directement la classe USB Audio en USB1.1, mais qu'il faut quand même un peu programmer (8051 compatible également).

[Fyper]

Fastoche !

[Tazz28]

Bon, oubliez les TI, il faut se retaper le re-clocking de la sortie I2S donc pas mieux que la soluce de apolon34 plus générique.

[robob]

Je déterre ce vieux post car les explications des "techniciens" du forum avaient clarifiées le débat mais en ce qui me concerne, il reste toujours un point non résolu qui peut prêter à débat (débat audiophile) :
- concernant le cadencement de lecture des données, le point est clair : la qualité du câble ne peut pas influencer si le DAC est conçu correctement et reclocke les données (c'est plus facile avec une transmission asynchrone).
- Un DAC USB qu'il soit asynchrone ou pas, transmet les données audio sans correction d'erreur : le récepteur fait un contrôle de validité mais, contrairement aux protocoles de tranfert "bulk" comme avec un disque dur USB par exemple, s'il détecte des erreurs, il n'y a pas de demande et de renvoie des données erronées : elles sont soit ignorées, remplacées par les précédente ou interpolées avec les suivantes.

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" onclick="window.open(this.href);return false;)
Par contre comme on est en isochrone, packet foiré = packet perdu = absence de data pour les samples perdu.

Ce point d'incertitude, s'il n'est pas quantifié, permettra toujours de relancer le fameux débats (idiophile ?) sur la qualité du cable USB.
En effet, si des erreurs sont détectées, que les données sont ignorées ou interpolées, même si moi je ne les entends pas, un autre pourra toujours dire qu'il entend une différence (car mes oreilles sont usées, que je n'ai aucune éducation musicale ou que mon matos est m.rdique ).
La premiere question qui me vient à l'esprit, c'est si un paquet est perdu, cela correspond à combien de Samples (par exemple en 16/44.1khz) ?
L'idéal serait comme je l'avais proposé plus haut, d'avoir un compteur d'erreur qui permettrait de dire "cette connxion USB à perdu xx samples sur une heure d'écoute". Inutile de dire que si c'est moins de 10 000 samples, c'est totalement négligeable (44100 samples par seconde).

Je me suis dit qu'un moyen simple de comparer la qualité de deux câbles USB, c'était de les connecter à un disque dur ou une vulgaire clé USB et de faire un gros transfert de données de plusieurs dizaines de minutes en chronométrant le temps de transfert. Si un câble est moins bon, c'est qu'il perd de temps à autre un paquet. Dans ce cas, le protocole bulk détecte les erreurs et demande le renvoie des paquets erronés. Cela prend plus de temps. Si un câble est moins bon que l'autre (perte de données), le transfert des données doit mettre plus de temps et la copie d'un gros fichier sur clé USB par se câble sera plus lente. Si le temps est identique, les câbles sont de qualités équivalentes.

Vous en pensez quoi ?

[CIU]

- Un DAC USB qu'il soit asynchrone ou pas, transmet les données audio sans correction d'erreur : le récepteur fait un contrôle de validité mais, contrairement aux protocoles de tranfert "bulk" comme avec un disque dur USB par exemple, s'il détecte des erreurs, il n'y a pas de demande et de renvoie des données erronées : elles sont soit ignorées, remplacées par les précédente ou interpolées avec les suivantes.

Bonjour,

Je me trompe peut etre, mais il me semble qu'en asynchrone, le mode bulk est utilisé, tout au moins par les convertisseurs USB/SPdif qui viennent avec leur logiciel de transfert...Donc il est fort possible de gerer le re-emission car la bande passante est aussi plus elevée.


R.C.

[thierryvalk]

Robob,

Si tu as du temps à perdre oui.
Le câble par lui-même ne génère pas d’erreur, une erreur est toujours possible suite à un parasite. Via secteur ou dans l’air.
Donc pour faire ce genre de test, tu devrais le faire un bon nombre de fois pour avoir un environnement +- similaire aux deux. Et encore, disons que tu auras 50% de marge d’erreur.

Pour tester un câble on utilise du matériel CEM dans un environnement « propre » et même là on se pose souvent des questions sur les résultats.

Si ton câble est pourris, t’inquiète ton PC t’en avertira rapidement.
En encore pas certain que ce soit le câble en cause car une bonne transmission dépend du Host, du Device et du câble. Les 3 doivent être adaptés, c’est pour cela qu’il y a des normes.
Si 2 des éléments sont légèrement hors normes, la transmission peut être meilleure que si 1 seul a un défaut.

[robob]

En encore pas certain que ce soit le câble en cause car une bonne transmission dépend du Host, du Device et du câble. Les 3 doivent être adaptés, c’est pour cela qu’il y a des normes.
Si 2 des éléments sont légèrement hors normes, la transmission peut être meilleure que si 1 seul a un défaut.

Oui, j'avais pensé à ça :si on test deux cables différents et que le PC ainsi que la clé sont identiques (on peut même reformater la clé avant chaque test), s'il y a une différence de temps de transmission, elle vient forcement du câble. J'y crois évidement pas du tout et je pense que les temps de transferts seront identiques : ça me semblait être une bonne méthode pour démontrer qu'il n'y a aucune différence entre un câble USB à pas de prix avec les conneries habituelles, genre connecteurs plaqué or et un câble de base.

Je me trompe peut etre, mais il me semble qu'en asynchrone, le mode bulk est utilisé, tout au moins par les convertisseurs USB/SPdif qui viennent avec leur logiciel de transfert...Donc il est fort possible de gerer le re-emission car la bande passante est aussi plus elevée.

J'avais un convertisseur USB/SPDIF Musiland qui utilisait ces propres drivers sous Windows : lui fonctionnait en mode bulk, donc correction d'erreur. Sur les DAC USB, non s'ils utilisent le protocole USB audio standard.

PS: pour les techniciens : mon appellation "bulk" fait référence au protocole de transmission USB utilisé pour transférer des données avec priorité à l'intégrité des données sans garantie de latence. Donc avec contrôle et renvois des paquets en erreur.

[Glazik]

Pour alimenter votre questionnement, et vous assurer que vraiment il n'est pas nécessaire de s'inquiéter de problèmes de connexion USB pour un usage audio personnel (je n'ose pas dire audiophile, vu la connotation), voici deux exemples :

Le mien, j'utilise quasi quotidiennement une interface audio RME UFX en USB2. Elle peut gérer 30 canaux jusqu'en 48kHz/24bits (18 jusqu'en 96/24) dans chaque sens et simultanément. Elle est connectée à mon Mac via un câble USB tout ce qu'il y a de standard, prolongé d'une rallonge active de 5m (et oui !). Je n'ai jamais eu un seul glitch depuis trois ans que je l'utilise.

Le second exemple est toujours chez RME. L'interface MADIFace USB permet de faire transiter en USB2 tous les canaux d'un flux MADI bilatéral. C'est un format pro équivalent à 32 liaisons AES/EBU mutliplexées jusqu'en 48/24, ou 32 en 96/24.

Vous imaginez bien qu'à côté, une liaison stéréo unilatérale, même en 384kHz/32bits, est très loin de poser problème.

[robob]

Les interfaces RME utilisent des drivers USB spécifiques : le protocole de transmission entre le PC et l'interface n'est pas le protocole USB audio standard, je pense. Tu ne peux donc pas comparer : si le protocole RME utilise un mode bulk avec reprise d'erreur, si le transfert est multiplexé (comme en HDMI) pour limité des erreurs dans un transfert isochrone, etc...on est pas dans le cas de figure d'un transfert USB audio en isochrone.

C'est comme dire que si un disque dur USB fonctionne très bien même avec un câble de 5m, ce câble fera parfaitement le boulot avec un DAC.

[Dagda]

Oui, enfin en attendant, le câble envoi des 1 et des 0 ... que ce soit de l'audio, de la donnée, de la vidéo, des frites, c'est la même chose !
Alors, même dans le cas d'un codec spécifique, la quantité d'info qu'est capable de faire transiter le câble reste nettement au dessus d'un basique signal stéréo en 44/16 (parce que oui, ne nous mentons pas, 98% des personnes lisent du 44/16, si ce n'est pas 99.9% ).

Le seul soucis que j'ai eu avec un câble usb, c'est à cause de la longueur, et c'était pour du transfert de donnée (mise à jour de firmware) !
Et pour avoir essayé plusieurs câble (dans des prix en rapport avec la qualité de fabrication), je n'ai jamais entendu quoi que ce soit de différent.

Mais, là encore, c'est subjectif

[robob]

Je suis bien d'accord avec toi et je pense que n'importe quel câble USB de base convient, surtout si le DAC fonctionne en mode asynchrone.

Mais faut choisir les bons exemples pour étayer une thèse et contredire les questionnements "audiophiles".

[Dagda]

Mais faut choisir les bons exemples pour étayer une thèse et contredire les questionnements "audiophiles".

C'est pas possible, ils ont des lois physiques fluctuantes et variables suivant le sens du vent et la phase de la lune !

D.

[fob69]

Bonjour,

Attention, la fait de na pas entendre de clicks ne vaut pas dire que le son n'est pas dégradé. Sur les liaisons usb, spdif optiques et coax audio vers un DAC il n'y a pas à ma connaissance de réémission des paquets en erreur, et lorsqu'un bit est altéré dans le flux de donnée, le paquet entier est au mieux corrigé par interpolation par le DAC mais il y a une perte d'information (le DAC invente le point manquant à partir des points précédents et suivants). Si il y a une multiplication des erreurs, le message audio PERD FORTEMENT EN DYNAMIQUE.
Si vous voulez vous en rendre compte vous achetez un cable optique à 5€ en 20m et vous comparez le résultat avec un câble de bonne qualité en 60 cm.

Je travaille dans l'informatique et j'ai rigolé quand on m'a dit de faire attention au cable usb pour mon DAC, (j'avais pris le premier qui trainait dans un titoir (du genre livré avec mn imprimante)), j'ai moins rigolé après avoir fait un test avec un cable de bonne qualité. C'est un des plus gros upgrades que je n'ai jamais eu sur mon système audio.

La non ré - émission des paquets en erreur change fondamentalement la nature de la transmission de données en audio par rapport à une transmission informatique classique.

Sur une transmission théorique avec ré - émission des erreurs en audio, le problème se déporte de toute manière cette fois à l'intérieur du DAC ou à l'intérieur de la puce de conversion (mais donc potentiellement avec moins de risque d'erreurs qu'avec le cable USB externe).

B.