Commandes de codec synchrone et asynchrone

La routine TransferCodecVerbs permet aux pilotes de fonction d’envoyer des commandes aux codecs audio et modem connectés à un contrôleur audio HD. Les commandes de codec peuvent s’exécuter de manière synchrone ou asynchrone :

• Si un appel à TransferCodecVerbs envoie une liste de commandes à traiter de manière synchrone, la routine retourne uniquement une fois que le ou les codecs ont traité toutes les commandes.

• Si un appel à TransferCodecVerbs envoie une liste de commandes à traiter de manière asynchrone, la routine retourne dès que le pilote de bus Audio HD ajoute les commandes à sa file d’attente de commandes interne, sans attendre que le codec ou les codecs traitent les commandes. Une fois que les codecs ont traité les commandes, le pilote de bus avertit le pilote de fonction en appelant une routine de rappel.

Selon la nature des commandes de codec qu’il envoie, le pilote de fonction utilise une ou plusieurs des techniques suivantes pour récupérer des réponses à partir d’un codec :

• Si le pilote de fonction doit avoir la réponse du codec avant de pouvoir effectuer un traitement supplémentaire, il utilise le mode synchrone.

• Si le pilote de fonction n’a pas besoin d’attendre que les commandes de codec se terminent, pour voir les réponses du codec et pour savoir quand les commandes se terminent, il utilise le mode asynchrone, ignore la routine de rappel (sauf pour libérer le stockage pour les commandes de codec) et abandonne ou ignore les réponses aux commandes de codec.

• Si le pilote de fonction doit savoir quand les commandes du codec se terminent, mais qu’il n’a pas besoin de voir les réponses, il utilise le mode asynchrone et s’appuie sur la routine de rappel pour la notification. Toutefois, il ignore ou ignore les réponses aux commandes de codec. La routine de rappel peut utiliser un événement de diffusion en continu du noyau (KS) pour envoyer la notification au main partie du pilote.

• Si le pilote de fonction doit savoir à la fois quand les commandes de codec se terminent et quelles sont les réponses, mais doit reprendre le traitement immédiatement plutôt que d’attendre que les commandes se terminent, il utilise le mode asynchrone et évite de lire les réponses jusqu’à ce qu’il reçoive la routine de rappel. La routine de rappel ou la partie main du pilote peut inspecter les réponses.

TransferCodecVerbs retourne STATUS_SUCCESS s’il réussit à ajouter la liste des commandes à la file d’attente de commandes interne du pilote de bus. Même si l’appel réussit, les réponses peuvent toujours ne pas être valides. Le pilote de fonction doit case activée les bits status dans les réponses du codec pour déterminer s’ils sont valides. Cette règle s’applique au mode synchrone et au mode asynchrone.

La cause d’une réponse non valide est probablement l’une des suivantes :

• La commande n’a pas atteint le codec.

• Le codec a répondu, mais la réponse a été perdue lorsqu’un dépassement du premier entré, premier sorti (FIFO) s’est produit dans le RIRB.

Ce dernier problème indique que le FIFO RIRB est de taille insuffisante.

Chaque réponse de codec contient un indicateur IsValid pour indiquer si la réponse est valide et un indicateur HasFifoOverrun pour indiquer si un dépassement FIFO RIRB s’est produit. Si IsValid = 0, indiquant qu’une réponse n’est pas valide, l’indicateur HasFifoOverrun permet d’identifier la source de l’échec :

• Si HasFifoOverrun = 0, le codec n’a pas pu répondre dans l’intervalle de temps requis. La cause probable est que la commande n’a jamais atteint le codec.

• Si HasFifoOverrun = 1, la commande a probablement atteint le codec, mais la réponse a été perdue en raison d’un dépassement FIFO.

Pendant un appel à TransferCodecCommands, l’appelant fournit un pointeur vers un tableau de structures HDAUDIO_CODEC_TRANSFER . Chaque structure contient une commande et fournit de l’espace pour une réponse. Le pilote de bus écrit toujours chaque réponse dans la structure qui contient la commande qui a déclenché la réponse.

Pour chaque appel à TransferCodecCommands, l’ordre dans lequel les commandes sont traitées est déterminé par l’ordre des commandes dans le tableau. Le traitement de la première commande du tableau se termine toujours avant le début du traitement de la deuxième commande, et ainsi de suite.

En outre, si un client effectue un appel asynchrone à TransferCodecCommands , puis appelle TransferCodecCommands une deuxième fois sans attendre la routine de rappel du premier appel, l’ordre relatif dans lequel les deux groupes de commandes des deux appels sont traités est défini par l’ordre dans lequel le client a envoyé les deux groupes de commandes. Ainsi, le pilote de bus traite toutes les commandes du premier appel avant de commencer à traiter les commandes du deuxième appel.

Toutefois, l’ordre relatif des commandes envoyées par deux instances de pilote de fonction différentes n’est pas défini. (Chaque instance a son propre objet d’appareil physique.) Par exemple, si instance 1 appelle TransferCodecCommands pour envoyer les commandes A, B et C dans l’ordre A-B-C, et si instance 2 appelle TransferCodecCommands pour envoyer les commandes X, Y et Z dans l’ordre X-Y-Z, le pilote de bus peut exécuter les commandes dans l’ordre A-X-Y-B-Z-C.

Lorsque des threads de pilotes de fonction distincts partagent l’accès au même ensemble de ressources matérielles, l’ordre relatif des commandes provenant de différents threads de pilotes peut être important. Dans ce cas, le pilote de fonction est chargé de synchroniser le partage des ressources entre les threads.

Par exemple, l’interface matérielle permettant d’écrire une séquence d’octets de données dans un codec peut se composer d’un registre d’index et d’un registre de données 8 bits. Tout d’abord, le pilote de fonction envoie une commande de codec pour charger l’index de départ dans le registre d’index. Ensuite, le pilote envoie une commande pour écrire le premier octet de données dans le registre de données. Le registre d’index s’incrémente après chaque écriture successive dans le registre de données jusqu’à ce que le transfert soit terminé. Toutefois, si deux threads de pilote ne parviennent pas à synchroniser correctement leur accès à l’index et aux registres de données, l’ordre relatif de l’accès au registre individuel par les deux threads n’est pas défini et le résultat probable est une altération des données ou une configuration matérielle non valide.

La routine TransferCodecVerbs est disponible dans les deux versions de hd Audio DDI.