UBS quelques éléments pour mieux comprendre l'audio
Transfert de données en USB
Il est communément admis au regard des informations fournies par la norme USB que le bus série universel fournir deux types de transferts. Le transfert en mode isochrone et asynchrone.
Le mode isochrone est plus commun et plus simple à implémenter pour le transfert de données audio.
Le mode de transfert asynchrone, quant à lui, semble plus se prêter aux échanges de données audio peut s’implémenter de trois façon différentes : par interruption (interrupt), par contrôle (control) ou en mode massif (bulk).
En transfert de données USB on parle d’hôte (host) pour désigner le dispositif qui va contrôler le transfert en matière de vitesse de transfert et de priorité. L’hôte alloue une partie de la bande passante disponible sur le bus de manière protégée ou partagée. Selon la nature du périphérique, en USB 2.0, la bande passante réservée varie entre 5Mb/s, 12MB/s ou 400Mb/s.
Le mode de transfert isochrone fonctionne selon un schéma de bande passante constante et de fortes contraintes de temporelles. Le flux de données audio doit pouvoir s’écouler très régulièrement et du fait qu’aucun mécanisme de contrôle de flux (handshake) n’existe, la livraison des données n’est pas garantie à 100%.
Le modèle de données assumé par la norme USB suppose que les périphériques ont une taille et vitesse d’échange des échantillons propres. USB supporte la transmission de paquets de taille d’échantillons multiples avec récupération tant que faire se peut des erreurs sur le bus en transfert isochrone. Si un périphérique n’a pas de taille fixée pour ses échantillons ou que son échantillonage est plus grand que la taille maximale possible sur le bus, la taille d’échantillon est fixée à 1 octet et ceci afin d’éviter un traitement d’erreur complexe lorsque des erreurs surviennent dans le cas d’une fragmentation de paquet.
Transfert asynchrone
Le mode de transfert asynchrone fonctionne comme son nom l’indique de manière alternée à l’aide d’un mécanisme de contrôle de flux (handshake) permettant d’émettre des paquets à fréquence irrégulière. Ses trois méthodes existantes que nous avons présentées ci-avant s’utilisent comme suit :
- En mode d’interruption, le système réserve une bande passante garantie pour une vitesse donnée. Le pilote de son déclenche un envoi de données vers la cible à chaque interruption matérielle. Les tâches actuelles sont différées et la demande traitée « en temps réel ». Ce mode est celui qui est le plus adapté au transfert audio cadencé, par déclenchement d’interruption à chaque besoin d’envoi de paquet de données audio par l’hôte.
- En mode de contrôle, les transferts de données se font sous forme de requêtes spécifiques. En règle générale ce mode est utilisé en phase de configuration du périphérique son par le pilote.
- Enfin, en mode de transfert massif est utilisé pour transférer des blocs de données de taille importante sans particulièrement gérer de périodicité d’échange ou de vitesse régulière. Ce mode est particulièrement adapté aux périphériques tels que les imprimantes ou disques dur externes dont le débit d’échange varie considérablement au cours de leur cycle d’utilisation. Il n’est naturellement pas l’idéal pour des échanges audio cadencés, de bande passante garantie et réguliers tels que le pilote audio le recherche.
Dans un système de communication l’émetteur et le récepteur doivent pouvoir se synchroniser suffisamment pour permettre la livraison des données de manière fiable et robuste. Le concept de la communication asynchrone assure la robustesse des échanges à travers le contrôle de flux permettant au cas où le récepteur n’a pas reçu les données correctement de les retransmettre dans un temps acceptable. A l’inverse, dans le concept de communication isochrone, l’émetteur et le récepteur doivent implémenter un mécanisme de synchronisation à la fois temporel et des données pour assurer la robustesse.
Transfert isochrone
Dans le mode isochrone, le bus USB ne supporte pas l’envoi à plusieurs reprises des mêmes informations et par conséquent gère difficilement les pertes d’informations et les décalages temporels. De même lorsque des erreurs surviennent sur le bus, la gestion des erreurs devient complexe pour ne pas altérer la cadence et le séquencement des informations.
Dans la plupart des systèmes isochrone, afin de limiter les problèmes de décalage dans le temps, une horloge unique de référence est utilisée. Ce principe est utilisé par exemple sur les dispositifs professionnels audio et vidéo (world clock) ou sur le réseau téléphonique (PSTN). En tenant compte du fait qu’une grande variété de dispositifs audio peuvent être connectés entre eux et disposant de logiciel (firmware) différent, satisfaire à une synchronisation d’horloge unique répondant à tout cas de figure de manière identique est pratiquement impossible à faire. De ce fait le bus USB définit un modèle d’implémentation de temporisation basé sur des horloges multiples (1 par dispositif) pour permettre la coexistence de périphériques variés à coût raisonnable.
Horloges et USB
Le temps est présent sur le bus USB au travers de synchronisation sur des horloges. Plusieurs horloges entrent en jeu :
L’horloge de gestion des échanges d’échantillons : elle détermine la vitesse d’échange des échantillons entre le logiciel client sur l’hôte et les fonctions API USB.
L’horloge du bus USB : Elle se déclenche théoriquement à exactement 1kHz (1 fois toutes les millisecondes) à pleine vitesse et à 8KHz (1 fois toutes les 125 nanosecondes) à haute vitesse. Un paquet de données (SOF – Start Of Frame) permet de définir la vitesse choisie pour l’échange.
L’horloge de Service : Elle détermine la vitesse d’échange avec la partie logicielle cliente.
Dans la plupart des systèmes d’exploitation il n’est pas possible de maintenir une large palette de communications isochrones simultanément du fait que chaque instance du pilote devrait être interrompue à chaque échantillon à très haute vitesse. Dans ce scénario, plusieurs échantillons sous forme de plusieurs paquets de données sont remis au pilote qui les découpe en trames séquentielles pour les transmettre sur le bus en adéquation avec les prérequis négociés entre les extrémités (émetteur et récepteur).
La partie cliente émettrice semble ne pas être affectée par cette gestion de la temporisation et des tampons de bas niveaux, mais du côté récepteur, les choses peuvent se compliquer du fait d’absence de mécanisme de référence unique…
L’horloge de référence est considérée comme étant celle du bus USB, tant que faire ce peux les périphériques tenteront de s’y référencer. En général, les logiciels vont naturellement ne pas avoir directement accès au périphérique et donc au calage parfait en phase et fréquence. Ils se reposent sur le pilote qui est en charge de gérer le déplacement des paquets de données sur le bus en calant les transmissions au mieux séparément du transfert logiciel->pilote.
Synchronisation des horloges
Pour assurer un transfert isochrone correct, les trois horloges doivent dont être synchrones. Lorsqu’un décalage d’horloge se produit, il peut arriver plusieurs phénomènes :
Décalage : deux horloges qui fonctionnent à la même fréquence peuvent du fait de leur mise en œuvre différente montrer une différence de vitesse (plus rapide ou plus lente) l’une par rapport à l’autre. Sans correction, la variation observée sur une horloge peut mener à une réception de trop ou pas assez de données sur une période de temps donnée.
Gigue : Une horloge peut varier dans le temps au niveau de sa fréquence pour diverses raisons comme des variations de température, de conditions électriques, etc… Lorqu’un phénomène de gigue se produit, il résulte souvent par l’altération des données émises reçues.
Différence de phase : Si deux horloges ne sont pas en phase, différentes quantités de données peuvent être mises à disposition selon les moments. En règle générale ce décalage de phase introduit un problème que quantification et/ou génère ce que l’on nomme en audio des artefacts (sons fantômes).
Pilote de périphérique isochrone
Dans la plupart des cas, les pilotes audio implémentent des méthodes d’échanges isochrones et par conséquent il nous semble important de bien détailler quelles en sont les possibilités.
La norme USB définit un ensemble de paramètres permettant de fixer le type de synchronisation à utiliser, la vitesse à adopter et la méthode de connexion. Il existe plusieurs types de méthode de synchronisation :
Asynchrone : non synchrone mais l’information sur le débit existe. Le pilote isochrone asynchrone ne peut utiliser le SOF (Start Of Frame) ni aucune autre horloge USB pour se synchroniser. L’émission/réception de données se fait à un débit fixe et dont la liste est exhaustive (44.1KHz, 48KHz, 176.4KHz, etc…) ou à une fréquence flottante programmable en continue. Si la fréquence est flottante, elle est réglée à l’initialisation. La transmission d’information est calée sur une horloge externe ou sur une horloge interne dédiée à cet effet. Un type de source isochrone asynchrone est par exemple un lecteur de CD audio émettant les échantillons de son à la fréquence issue sur son horloge interne propre.
Synchrone : calé sur le SOF (Start Of Frame) USB. Les périphériques isochrones synchrones calent leur horloge propre sur l’émission du SOF toute les 1 ms via un PLL. Les périphérique travaillant à haute vitesse sont également capable de traquer le décalage des SOF et de se recaler dessus régulièrement. Comme pour les dispositifs asynchrones, l’émission/réception de données se fait à un débit fixe et dont la liste est exhaustive (44.1KHz, 48KHz, 176.4KHz, etc…) ou à une fréquence flottante programmable en continue. Si la fréquence est flottante, elle est réglée à l’initialisation. La transmission d’information est calée sur une horloge externe ou sur une horloge interne dédiée à cet effet. Un type de source isochrone synchrone est par exemple un micro digital calé sur l’émission des SOF de l’hôte et envoyant un nombre fixe d’échantillons par trame.
Adaptatif : Synchrone utilisant un retour d’information sur le débit et le format des données. Capable d’émettre ou recevoir des données à n’importe quel débit disponible selon leur nomenclature, les périphériques isochrones adaptatifs échangent entre la source et la destination les capacités pour sélectionner la plus adaptée à un moment T. Le débit est une information qui est ensuite intégrée dans le flux de données échangé. Le nombre moyen d’échantillon reçus pendant une période de temps donnée détermine le débit instantané variable. Un exemple de source adaptative est un DAC ou un lecteur de CD disposant d’un ensemble de fréquences ou d’intervalles de fréquences d’opérations et pouvant passer de l’une à l’autre à volonté.
Trames USB et micro-trames
USB définit une trame à pleine vitesse émise toutes les 1ms et signalée par un paquet SOF (Start Of Frame) à la tolérance de gigue près. USB définit également une micro-trame, qui à pleine vitesse est émise toutes les 125 µs à la tolérance de gigue près.
Les périphériques à haute vitesse voient un paquet SOF émis toutes les ms et dans l’intervalle 8 paquets.
Utilisation de Mémoire tampon en mode isochrone
Le principe du bus USB nécessite une mise en mémoire tampon des échantillons avant transmission/traitement. Pour ce qui est des transferts logiciel -> pilote, le périphérique doit accumuler les trames de l’échantillon N jusqu’à réception du SOF de la trame de l’échantillon N+1. Durant la réception des données N+1, il peut librement transmettre au récepteur l’échantillon N. La fréquence d’échange est donc gérée séparément pour la dépose des éléments et pour la transmission sur le bus effective.
De même pour la réception d’information, le pilote accumule dans la mémoire tampon les échantillons reçus sur la trame N jusqu’à réception du SOF de la trame N+1. Une fois celui-ci reçu, l’échantillon complet est passé au logiciel en parallèle via les API du pilote.
De ce fait, l’échange d’information basé sur le SOF permet d’assurer une gigue et un décalage minimal sur le bus. Cette méthode permet également de faire varier la fréquence ou le débit sans perte de synchronisation d’horloge, le calage étant toujours fait sur réception du SOF.
La contrepartie d’utiliser une mémoire tampon et l’introduction d’un délai supplémentaire de gestion interne à l’instar des dispositifs qui accèdent au bus de manière cadencée directement pour déposer ou lire les informations qui y circulent calés sur le SOF
Gestion des erreurs en mode isochrone
Le mode de transfert isochrone n’apporte aucun mécanisme de réémission de données, il est cependant important d’implémenter une méthode permettant au minimum de savoir quand et comment se produisent les erreurs affectant la communication. Quatre mécanismes permettent de mettre en place un minimum de détection d’erreur (sans correction).
La périodicité à travers le débit fixé par un mécanisme de séquencement de données (PID – Packet ID) sur les périphériques à haute vitesse et large bande passante. Le mécanisme de transfert isochrone fonctionne sur une périodicité de multiples de 2 trames. Toute trame perdue entraine la perte des multiples correspondants.
La trame Start Of Frame. Naturellement la trame SOF peut être manquante ou endommagée, de ce fait le périphérique doit être capable de reconstruire l’information à partir des informations données par la norme USB
Un CRC (Code de redondance cyclique) pour se protéger de la corruption de données
Timeout du bus permettant d’abandonner la réception d’un groupe de trames et de passer au suivant. Suivant les trames perdues, le pilote peut être capable de reconstruire ou non l’information. Une perte d’une ou deux trames peut être sans conséquence sur l’ensemble d’un échantillon vocal.
Mise en mémoire tampon pour se caler sur le débit
Du fait que plusieurs horloges rentrent en jeu dans le mécanisme de transmission isochrone, la mise en mémoire tampon est indispensable pour permettre de recaler les débits sur le bus. Il doit y avoir un tampon dans le périphérique et également au niveau de l’hôte pour le logiciel. Ces tampons doivent être assez grands pour contenir suffisamment de données jusqu’à ce qu’il soit temps de les transférer sur le bus.
Voilà qui clôture un premier article sur le sujet,
Musiq