USB : sa vie , son oeuvre

[shal]

Je fais une spin-off d'un autre sujet et sur proposition de mambojet :
Pour un système vert en dématérialisation...

Le but serait ici de discuter d'un point de vue technique sur l'USB et plus particulièrement sur son utilisation dans le cadre de l'audio.
Le cas d'utilisation standard étant utiliser un PC (ou assimilé) pour alimenter un DAC USB.

J'essaye de rester simple et de ne parler que de l'utile en audio.
Pour ceux qui s'y connaissent, ils ne découvriront rien de nouveau.

Je suis loin de maîtrisé USB mais j'ai déjà fait quelques trucs:
- modification de driver Re: Chacun son bricolage
- utilisation de sonde USB pour analyse de traffic
- création de paquets USB "a la main"

Il y a surement des erreurs, si vous en voyer dites le , on vas faire avancer le schmilblick ensemble.

Partie physique

USB pour Universal Serial Bus.
Un bus série est quelque chose de simple. Le connecteur et le câble en lui même est très simple.
Il y a 4 fils (je ne parle pas de l'USB3 ici qui est différent) :
- un pour la masse
- un pour conduire du 5V
- deux autres (appeler D+ et D- ) pour transmettre l'information . Elle est a peu prés protégé par un système proche des câbles symétrique XLR

Il y a deux types de connecteur (A => plat et B => carré) pour bien faire en sorte que les deux appareils reliés ne sont pas égaux. Il a l'hôte et le périphérique (presque faux ce que je dis car il y a l'USB On-The-Go , mais je simplifie ici) .
Il y a aussi le cas des périphérique qui sont des bridges. Et donc un hôte peut "voir" plusieurs périphériques sur un connecteur.
C'est l'hôte qui commande sur le bus et c'est lui qui dit quand les périphérique peuvent causer.

Une petite aparté : sur ce point c'est donc le contraire de l'ethernet , où là chacun peut causer quand il veut. Il y a ensuite un mécanisme de détecter de collision (quand deux personnes ont parlé en même temps ) puis de renvois du paquet ethernet (en espérant que ce coup ci cela passe).

Donc pas grand chose a dire. On voit bien que c'est prévue pour être pas cher a produire et très généraliste.

Protocole USB
Les appareils USB sont censés respecté un protocole de communication définit par l'USB Implementers Forum, Inc. (http://www.usb.org).
Même ceux qui utilisent des drivers spécifiques doivent implémenter certaines fonctions.

Un périphérique peut aussi implémenter des fonctions non obligatoire  mais qui sont pratique. Ce sont les USB Device Class.
Dont celui qui vas nous intéresser ici : USB Audio Class.  Mais il y en a plein d'autre par exemple pour la vidéo, pour les chargeur de batterie USB , les cartes à puces etc etc
Deux gros avantages pour le constructeur de choisir cette solution:
- Souvent des solutions toutes faites a prendre sur étagère (Par exemple le XMOS)
- Pas besoin d'installer un  driver sur l'hôte, donc moins de problème de SAV utilisateur

1 désavantages: Pas extensible et donc si on a des besoins particulier, il faut faire autre choses.

Je fais une section vraiment informatique ici, le lecteur peut passer toute cette section s'il le souhaite.
Rendez-vous à buffer circulaire.

Quand un appareil nouveau se connecte , l'hôte demande au périphérique de se présenter (GET DESCRIPTOR).
Le périphérique répond alors en donnant sa description.
Vous avez un exemple de description ici http://pastebin.com/sk2HVYgS  cela correspond a une RME Fireface UCX.
Cela fait 485 lignes, je le met pas ici.  Néanmoins, je vais essayer de rendre la lecture de ce descripteur compréhensible.

Dans le descripteur on trouve quelques information général (nom du constructeur, nom du produit , numéro de série, classe et sous-classe USB ) ainsi q'un certains nombre de configuration.

L'hôte analyse les différentes configurations et choisit celle qui lui convient.
Un exemple serait une carte son supportant USB Audio Class 1 et 2
Sous OS X qui supporte nativement UAC2 (UAC2 pour USB Audio Class 2) , il choisira la deuxième configuration.
Alors que sous Windows basique (sans driver ASIO ou autre), il ne connait que l'UAC1 il choisira UAC1.

Chaque configuration comporte un ensemble d'interface  qui décrivent des endpoints .
Ouai,je sais ça fait bizarrement compliqué  ce système, prenons un exemple (issue du lien plus haut).

l'entête d'un descripteur

Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x0424 Standard Microsystems Corp.
  idProduct          0x3fd9
  bcdDevice            0.01
  iManufacturer           1 RME
  iProduct                2 Fireface UCX (23455936)
  iSerial                 3 A0A762B3C75E8C8
  bNumConfigurations      1

bNumConfigurations est à 1 donc 1 seul configuration sur cette appareil

Une description d'un interface:

Interface Descriptor:
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           2
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol     32

Là, on voit que c'est une interface dédié à l'Audio Streaming. Moins évident le protocole d'interface est 32 soit 0x20 en hexadécimal et cela veut dire UAC2.  On voit aussi que cette interface a deux endpoints.

Les deux endpoints (simplifié)

Endpoint Descriptor:
        bEndpointAddress     0x01  EP 1 OUT
          Transfer Type            Isochronous
          Synch Type               Asynchronous
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
Endpoint Descriptor:
        bEndpointAddress     0x81  EP 1 IN
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Feedback
        wMaxPacketSize     0x0004  1x 4 bytes

A tiens! on voit apparaître des informations qui plaisent aux audiophile : Asynchronous.
On y reviendras plus tard. Il faut juste savoir qu'un hôte envois un paquet à un endpoint  donné d'un périphérique donné.

J'ai omis volontairement une information: il existe 4 types de transfert:
- transfert de commande : paquet de petite taille, la réception assuré, exemple demander la configuration d'un périphérique
- transfert d’interruption : petit paquet et rapide . Exemple : un clavier, une souris
- transfert bulk : grosse donnée avec garantie acheminement . Exemple : disque dur USB
- transfert isochrone : grosse donnée avec garantie de bande passante mais pas d'acheminent (juste détection d'erreur, pas de correction) . Exemple : DAC

On s’intéressera qu'au cas isochrone.

Les buffer circulaires

Une notion a maîtriser est la notion de buffer circulaire. rien de compliqué mais si l'on ne l'a jamais vu cela peut paraître obscure.
bon, encore une fois wikipedia est super:

Un buffer circulaire est une zone mémoire qui comporte  n cases de taille fixe.
On écrit dans 1 case puis dans la suivante etc etc . Il y a un pointeur sur la case a écrire qui avance au fur a mesure.
Idem il y a un deuxième pointeur, celui de la lecture qui point sur la case a lire et qui avance a chaque fois.
Voila c'est tout .

Si on applique cela au transfert de donnée.
On a deux entités . Une source et un destinataire et au milieu un buffer circulaire.
La source vas écrire dans le buffer circulaire et le destinataire lire dedans .

On voit que le problème peut être quand le lecteur vas plus vite que l’écrivain : on lit potentiellement n'importe quoi .
Inversement si l’écrivain vas trop vite, il vas faire un tour complet et écraser des données non encore lu par le lecteur.

USB Asynchrone

Ça y est on a tout pour discuter du cas l'USB isochrone asynchrone.

Dans un DAC on a la partie purement DAC
A chaque tick donnée par une clock, la puce lit un buffer et transforme ce buffer en son analogique.
Ce buffer lu est une case d'un buffer circulaire.

Le rôle de la partie du DAC qui s'occupe de la réception USB et de garder ce buffer circulaire propre , que l’écrivain aille pas trop vite ou pas trop lentement pour que la lecture a vitesse constante soit toujours parfaite.
Pour cela il vas utiliser les deux endpoints vu plus haut .
En USB Asynchrone, le periphérique reçoit des données audio par un canal mais il envoit aussi un feedback par un autre canal.

Grace a ce canal, le périphérique peut dire à l'hôte d'accélérer ou de ralentir . Donc même si le PC a une horloge pas fiable du tout, le DAC lui donnera les informations nécessaire pour que le buffer circulaire soit toujours correctement rempli.

On remarquera que plus un buffer circulaire est grand , moins on a de risque de problème mais qu'inversement on vas rajouter de la latence.
Cette latence est pas importante pour nous audiophile mais peut l'être si on est dans un studio d’enregistrement.

USB Synchrone

Regardons le cas de l'USB audio isochrone synchrone.

Ici aucun feedback et l'horloge qui sert a faire avancer la lecture est déduite de l'arrivé de paquet USB.
Chaque milliseconde (ou 125µs dans le cas du High speed) il y a un Start of Frame (SoF) et les données qui suivent.

Donc la qualité de l'horloge du PC (enfin de la clock du contrôleur USB) se retrouve impliqué dans la conversion  numerique/analogique.
Même si des système de recalage style PLL peuvent être utilisé pour corriger le problème en grande partie.

Conclusions

On voit que grâce à l'USB asynchrone on peut s'affranchir des problèmes de qualité d'horloge du PC.
Les données PCM tel que présent dans le fichier wave arrivent presque tel quel dans le DAC.
Ensuite on a une "garantie" que l'information arrive de façon parfaite dans le récepteur USB du DAC.
Faut-il encore que le constructeur ne fasse pas n'importe quoi entre ce récepteur et la puce de décodage.
Mais ce genre de problème est par exemple identique a ce que l'on trouve dans un lecteur CD. Il y a la partie laser qui lit une donnée et la stock dans un buffer et la partie DAC qui lit se buffer et le convertie en analogique. Donc pas de différence spécifique ici. Si on sait le faire sur un lecteur CD , on sait le faire sur un DAC USB asynchrone.

Alors vous me direz que j'ai occulté le fait que le mode isochrone ne garantie pas les données.
C'est exact mais il y a une détection des erreurs et des problème des buffer plein ou vide (ce sont des xruns).
Quand des erreurs arrivent, on peut en être informé . Dans la pratique, je n'en vois jamais.

J'ai été beaucoup trop long et pourtant j'ai omis de  parler de plein de chose.
Il faut voir cela comme une introduction pour la discussion.

Quelques liens
USB basique:
http://fr.wikipedia.org/wiki/Universal_Serial_Bus
Pour aller plus loin:
http://www.beyondlogic.org/usbnutshell/usb1.shtml
Buffer circulaire:
http://fr.wikipedia.org/wiki/Buffer_circulaire
http://www.silabs.com/Support%20Documen ... -Paper.pdf

[AJMARS]

Je lis tout ça avec grand intérêt...

Merci

A plus
André

PS peux tu nous dire quel matériel tu utilises au niveau de la réception des données USB coté DAC.

[shal]

Pour ceux qui aime bien ce genre de post. j'en avais fait un qui bien que pas trop sérieux contenait un peu d'information aussi : Re: Un petit Dac entre un Mac et un ampli ?...

Je me rends compte que j'ai oublié de parlé du contrôle de volume.
L'USB Audio Class définit comment envoyer un information sur le contrôle de volume au DAC.
On peut préciser le volume entre -127db et +127 db par pas de 1/256 db.
Cela veut dire que le PCM est envoyé sans aucune modification même si au niveau du logiciel de lecture, vous diminuer le volume.

Ensuite comment le DAC gère cette information est très variable.
Mais pas mal de puce travaille en 32, 40 voire 64 bit donc peuvent gérer le volume sans "trop" perdre d'information.
D'autres DAC vont utiliser cette information pour contrôle un atténuateur analogique (par exemple : réseau de résistances).


J'ai aussi oublié de parlé du problème d'isolation galvanique entre le DAC et le PC.
En effet vu que l'USB c'est des 4 fils de cuivres, le PC et le DAC sont relié électriquement.
Et comme générale les PC sont bruyant du point de vue électrique, il vaut mieux qu'il y ai une isolation galvanique entre les deux.

[AJMARS]

Saurais tu ce qu'il existe comme carte de réception qui utilise un USB Asynchrone et qui délivre un signal I2S

Merci
André

[Hollow]

Amha, c'est impossible.

a+

[AJMARS]

Je viens de jeter un oeil aux Amereno citées plus haut.... j'ai répondu moi même à ma question...

Si toute fois il y d'autres choix....

http://www.amanero.com/

Comme sur ma carte de convertisseur il y a un multiplexeur numérique de prévu entre le récepteur S/PDIF et la suite, ça devrait me prendre très peu de temps pour implanter ce genre de chose...

A plus
André

[shal]

Saurais tu ce qu'il existe comme carte de réception qui utilise un USB Asynchrone et qui délivre un signal I2S

Merci
André

heuu  
Tu as mambojet  qui parle justement de cela a coté : http://www.6moons.com/audioreviews/ami2/amanero.pdf

Ou alors je comprends pas un truc

[AJMARS]

Oui désolé... je viens de lire...      

J'ai tout ce qu'il faut sur ma carte DAC pour rentrer l'I2S + Mclock....  Il y a longtemps j'avais implanté un mux HC au cas où....

A plus
André

[shal]

Je lis tout ça avec grand intérêt...

Merci

A plus
André

PS peux tu nous dire quel matériel tu utilises au niveau de la réception des données USB coté DAC.

J'utilise que du matos sur étagère j'aimerais bien faire  mais je sais point  

Actuellement j'ai une vénérable Edirol UA-1000 qui date de 2003-2004 et dont le transfert de donnée se passe en USB Asynchrone ( Et oui n'en déplaise a certain c'est pas wavelength ou XMOS qui ont inventé l'USB asynchrone). Mais par contre ma carte nécessite un driver spécifique car elle fait plein de chose en plus et donc comme indiqué dans mon premier message , quand les besoins spécifique ne sont pas  couvert par un USB Device Class, le constructeur doit implémenter un driver. Libre a lui de pas réinventé la roue et de réutiliser des briques existante comme le mode isochrone asynchrone.

[AJMARS]

Ben.... a partir du moment ou le module USB délivre l'I2S + Mclock, il ne reste plus grand chose à faire.... Le plus sioux est la partie analogique....

http://www.ti.com/product/pcm1796

A plus
André

[Kaneda]

 Super fil ! merci Shal.
Je vais lire ça ce soir (ou cette nuit   )

Et quelles pourraient être les explications techniques aux énormes différences audibles entre câbles USB ?

[mambojet]

Nickel, bravo  
J'ai une question
Quelles seraient les faiblesses de l'USB asynchrone bien mis en œuvre?
En te lisant on se dit qu'il n'y en a peut être pas beaucoup.
Trop beau pour être vrai ?

-- 21 Déc 2013, 19:43 --

Je viens de jeter un oeil aux Amereno citées plus haut.... j'ai répondu moi même à ma question...

Si toute fois il y d'autres choix....

http://www.amanero.com/

Comme sur ma carte de convertisseur il y a un multiplexeur numérique de prévu entre le récepteur S/PDIF et la suite, ça devrait me prendre très peu de temps pour implanter ce genre de chose...

A plus
André

L'Amanero est connue et semble assez appréciée
Mais bon il faut se méfier
Si c'est par les mêmes qui trouvent bons la DL103 et les transfos MC...

-- 21 Déc 2013, 19:46 --

Amha, c'est impossible.

a+

Quelques explications complémentaires ?
N'hésite pas, on ne fait pas payer au mot

[AJMARS]

L'Amanero est connue et semble assez appréciée
Mais bon il faut se méfier
Si c'est par les mêmes qui trouvent bons la DL103 et les transfos MC...

Même pas peur.....      


Quand tu vois
http://www.audiophonics.fr/amanero-comb ... -7403.html
Plus
http://www.audiophonics.fr/audiophonics ... -8396.html

Ou si tu veux te faire mal et bidouiller un peu et faire sauter le récepteur S/PDIF... et rentrer en I2S sur le Burr-Brown...
http://www.audiophonics.fr/audiophonics ... -4993.html
Y a de quoi se marrer un peu..

A plus
André

[mambojet]

Oui c'est sur que cela coûte moins cher que d'acheter une XV1S
J'ai une utilisation du Mac et de la demat qui se rapproche de la tienne
Occasionnelle mais j'aimerai bien avoir un truc qui marche a peu près

[AJMARS]

Oui c'est sur que cela coûte moins cher que d'acheter une XV1S

Tu sais... moi, je me contente de quelques SPU sur du transfo.... alors...
   

A mon âge...

A plus
André

[shal]

Nickel, bravo  :cool:
J'ai une question
Quelles seraient les faiblesses de l'USB asynchrone bien mis en œuvre?
En te lisant on se dit qu'il n'y en a peut être pas beaucoup.
Trop beau pour être vrai ?

J'ai quand même mis que le mode isochrone ne garantie pas que les données arrivent correctement . Alors que le mode bulk y arrive, c'est donc un choix et non une impossibilité du bus USB. isochrone est vraiment orienté flux. D'ailleurs il y a une notion de stream dans l'USB Audio Class dont je n'ai pas parlé. Dans l'isochrone c'est une bande passante qui est garantie.

Il faut que je cherche sur ce qui arrive si une erreur est détecté, je sais pas trop bien si elle est juste comptabilisé ou si elle est traité pour corrigé l'erreur.

J'ai aussi évoqué que la donnée arrivé dans le récepteur USB mais pas forcement jusqu’à’à la puce DAC.
Il doit exister une palanqué de DAC USB qui est un DAC SPDIF auquel on a bidouillé une entrée USB plus ou moins bien faite.

J'ai évoqué aussi les problème d'isolation galvanique . Du HF venant du PC peut-il perturber le DAC ?
Peut-être certains câbles conduise mieux les parasites que d'autres, mais là je sort complètement de mon domaine de compétence.

Reste le cas du buffer circulaire: On peut parfois avec certaines carte son (ou DAC) régler la latence. C'est en fait la taille du buffer circulaire (c'est un peu plus complexe mais c'est pour simplifier) . Si tu descends trop bas , alors il peut y avoir des pertes d'information (les fameux xrun, pour underrun ou overrun).

Mais si je reste au niveau informatique/transfert de donnée : oui USB asynchrone est pas loin de la perfection dans le cas standard.


Olivier

[AJMARS]

Au niveau de la liaison vers le convertisseur il peut être intéressant de soigner l'isolation, mais aussi la qualité des horloges délivrées par la carte USB en particulier le Wclock. Je ne sais pas ce qui est fait dans les cartes USB/I2S à ce niveau.

A plus
André

[Hollow]

Quelques explications complémentaires ?

Toujours amha, l'i2s original est loin d'être reproduit après tous les traitements induits surtout après ripage.
Mais, bon.

a+

[AJMARS]

Si les données ripées ne sont pas altérées, la qualité de l'I2S dépend essentiellement de celle du Wordclock
Donc pour une séquence de données intègres, l'I2S à la lecture peut être de qualité supérieure à celle de l'I2S sortant de la puce de conversion lors du premier enregistrement.....    

Si, si....

Le numérique est une machine à copier......

A plus
André

[Hollow]

C'est un avis.
Pour ce qui est du ripage et de son intégrité, globalement, c'est ok (moins de 1/1000 de pb d'après dbpoweramp) pour des CDs en bon état.

a+