robob a écrit:Donc ton DAC avec son chipset, par exemple un PCM2702 reçoit les données transmises par le PC, donc par le pilote Windows (Usbaudio.sys, je crois, pour ceux qui chercheraient les spef.). Question : comment le chipset se met-il en phase avec l'horloge du PC : Peut-il envoyer une information au PC pour modifier la fréquence d'envoie des données ?
Mode isochrone, c'est le device qui demande les datas au PC selon la clock USB.
Modifie t'il sa propre frequence en fonction des données d'horloge reçues (si ces données sont transmises comme en SPDIF) ? Si il y a déphasage des horloges, des données peuvent être perdues et ne seront pas renvoyées en mode isochrone.
C'est en mode "synchrone isochrone" le mode USB utilisé en lui même étant le mode isochrone (peudo synchrone) dans tous les cas, même dans le cas asynchrone de la classe USB Audio.
Voilà ce que moi j'ai compris mais je ne suis pas un spécialiste comme toi :
Les données sont envoyées en mode isochrone : flux continu de données par paquets toutes les 1ms. Ils arrivent dans le buffer du chipset pour être traités, il ya un controle d'erreur du type bit de parité, je ne sais pas si les données sont redondantes. Si c'est le cas, le controle d'erreur doit permettre de pouvoir choisir les bonnes données dans la redondance (comme en SPDIF).
Le "endpoints" (l'implementation logique du protocole) permet aux deux parties de converser : il peut-être asynchrone. Dans ce cas l'une des deux parties sera maitre et reglera la fréquence de l'hote de telle sorte que les horloges soient en phase. Dans ce cas pas vriament de probleme.
Malheureusement, pour nous, pauvre utilisateurs de Windows, Ce mode asynchrone n'est pas implémenté (ni dans XP ni dans Vista et toujours pas dans Seven).
Le chipset de ton DAC va donc utiliser le mode adaptatif : dans ce cas l'horologe du DAC va etre reglée sur la fréquence d'arrivée des données, on retombe dans la même configuration qu'avec une connexion SPDIF et probleme possible de jitter dû à un déphasage entre les horloges.
Tu parle de paquet et de buffer -> on est bien sur un médium asynchrone.
Tout ce qui est contrôle d'erreur, c'est le problème du bus USB comme de l'ethernet ou de la stack IP par analogie avec du réseau.
Le bus est asynchrone, mais il y a bien une notion de clock et de synchro propre au media physique, mais rien avoir avec la clock des samples transportés (surtout lorsque ces data sont en plus des data compressés genre ac3 etc ....).
La problématique de l'USB est de transporter les data audio.
Le mode asynchrone pur de l'USB (pas de la classe audio) mode interrupt assimilable par analogie réseau à TCP, est trop lourd pour des données de type fux est plus lourd a implémenter dans les chips et consommateur inutile de ressource cpu des deux cotés.
Le mode Bulk : même combat mais en plus aucune garantie de bande passante et de latence donc sur des données de type fux, cela imposerait des buffers de réception énormes sans la garantie de ne pas se retrouver à un moment ou un autre avec le buffer vide à cause de l'utilisation du bus USB par un autre périphérique.
Le mode isochrone utilisé par la spec USB audio qui permet d'avoir une garantie de bande passante et de latence donc pas les problèmes précédents et de travailler en mode flux. Assimilable à de l'UDP pour continuer l'analogie réseau, sauf qu'en réseau il n'y a pas non plus la garantie de BP et de latence.
Avantage: léger à implémenter et peu consommateur en ressource, on balance les packets à intervale régulier point. La garantie de BP et de latence permet de ne gérer que de tout petit buffers coté device sans risque d'underrun et donc de coupure intempestive du son.
Inconvénient: nécessite un mécanisme de synchronisation pour éviter quand même les underrun et ne pas avoir a gérer un gros buffer. Plus exactement un mécanisme de contrôle de flux. Et quand un packet est foireux, il est définitivement perdu.
Voilà pour le choix de l'isochrone.
Maintenant passons aux différents modes de la classe USB Audio:
- Asynchrone : aucun contrôle de flux au niveau USB -> le device gère la demande des data quand il veut.
- Synchrone : la vitesse de transfert des data est rythmé par le StartOfFrame du bus USB, c'est ce qui se rapproche le plus d'un vrai mode synchrone.
- 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.
Ce dernier est le plus robuste et est assez lowlevel pour être implémenté coté device simplement, le mode asynchrone étant beaucoup plus haut niveau coté traitement des deux cotés.
Le format des data transféré est passé en configuration sur le endpoint qui va bien ansi que la fréquence pour ce dernier. Elle dérivé de la vitesse de transfer pour l'adaptatif et le synchrone.
Les data sont transférés, on peut maintenant alimenter le dac en data à la vitesse qui va bien, par l'interface qui va bien et selon un clock locale propre et stable.
Il faut bien décoreller les deux, le transport jusqu'au DAC et les problèmes de clocks locales au dac.
Si le Chip USB sort directement les data en utilisant la clock de transport USB et non la masterclock locale c'est mort
Le système de fifo avec la partie in gérées par l'usb et la partie out par la master clock locale exprime bien la décorrélation des deux domaines.
apolon34 résume très bien ce qu'il faut faire et ce qu'il a visiblement mis en œuvre avec succès.
La transmission isochrone est une excellente solution qui permet d'avoir une horloge gérée par le récepteur. Il se contente de gérer une fifo et de demander des paquets quand elle se vide et d'arrêter de demander quand c'est plein. C'est d'ailleurs la meilleure solution de transmission numérique a mon sens.
L'avantage d'un device utilisant le mode asynchrone isochrone USB, c'est que c'est la garantie que le constructeur n'a pas fait la connerie d'utiliser la clock du bus USB pour driver le DAC..... Dans les device à 5€, c'est le cas: pas de buffer a gérer, pas de dérivation de fs a faire etc ......
Mais on peu très bien utiliser le mode synchrone isochrone ou adaptatif isochrone tout en faisant les choses correctement dans le chip USB et en étant complétement indépendant de la clock USB en sortie de celui ci.
Pour finir avec les analogies, la clock de ton bus ATA, SATA ou SCSI ou SAS n'est pas synchronisée avec celle du dac de ta carte son... Dans tous les modes USB audio, on pourrait très bien imaginer une fifo assez grande pour accueillir tout ton fichier en moins d'une seconde, c'est pas pour autant que ton morceau de 5min sera joué en moins de 1s, la fifo se videra a la vitesse de la clock locale du dac.
Les choses se complique lorsque l'on a plus d'un flux stéréo à synchroniser, mais le problème n'a rien avoir avec l'USB et on s'en sort de la même manière pour la partie transfert USB
Pour finir, on en reviens à la même chose: USB -> bus asynchrone en mode packet -> rien a péter des câbles et intrinsèquement il n'est pas générateur de jitter. Après, y a pas besoin de l'USB pour faire n'importe quoi. A quand un DAC ou une source spdif avec un clock locale dérivée du 50Hz secteur .....
PS: un peu de lecture indigeste :
http://www.usb.org/developers/devclass_docs/audio10.pdf
, ne serait-ce qu'en enlevant les ferrites des câbles 
