Latence WavePci
Le pilote de port WavePci gère la mise en tampon d’un flux audio différemment du pilote WaveCyclic.
Si votre pilote miniport WavePci fournit un mixage matériel, DirectSound soumet un IRP au pilote de port WavePci contenant l’ensemble du flux audio DirectSound dans un seul tampon cyclique. DirectSound alloue le tampon comme un bloc contigu de mémoire virtuelle. Pour éviter de copier le tampon DirectSound, la couche de streaming du noyau mappe le tampon en mémoire virtuelle en mode noyau et génère une MDL (liste de descripteurs de mémoire) qui spécifie à la fois les adresses virtuelles et physiques des pages de mémoire dans le tampon cyclique. Le pilote de port WavePci partitionne le tampon cyclique en une séquence de trames d’allocation (veuillez consulter la section KS Allocators). Le pilote miniport spécifie la taille de trame d’allocation préférée lorsque sa méthode IMiniportWavePciStream::GetAllocatorFraming est appelée par le pilote de port lors de l’initialisation du flux. Cependant, SysAudio, le constructeur de graphes système, peut ignorer les préférences du pilote miniport pour répondre aux exigences des autres composants du graphe de filtre audio.
Le pilote de port WavePci expose le tampon cyclique au pilote miniport sous forme de séquence de mappages. Un mappage est soit une trame d’allocation entière, soit une partie d’une trame. Si une trame d’allocation se trouve entièrement dans une page, le pilote de port présente cette trame au pilote miniport comme un seul mappage. Si une trame d’allocation chevauche une ou plusieurs limites de page, le pilote de port divise la trame à chaque limite de page et la présente sous forme de deux ou plusieurs mappages. Chaque appel à IPortWavePciStream::GetMapping donne le mappage suivant dans la séquence.
Contrairement au cas WaveCyclic, où le pilote miniport a peu de contrôle sur le nombre de millisecondes de données mises en tampon par le matériel, le pilote miniport WavePci a un contrôle considérable sur le nombre de mappages qu’il a ouverts à tout moment. Le nombre de mappages ouverts augmente de un à chaque appel à GetMapping et diminue de un à chaque appel à ReleaseMapping. (Un appel à GetMapping peut échouer, bien sûr, donc le pilote n’-a pas un contrôle total sur le nombre de mappages.) En contrôlant le nombre de mappages ouverts et en gardant une trace de la taille cumulative des mappages, le pilote miniport peut déterminer (avec une tolérance dépendant de la taille du mappage) le nombre de millisecondes de mise en tampon disponibles pour le matériel. Votre pilote miniport WavePci doit demander suffisamment de mappages de pages pour réduire les risques de famine à des niveaux acceptables.
Si la politique de votre pilote miniport est de tamponner jusqu’à 50 millisecondes de données, par exemple, entre les pointeurs de lecture et d’écriture, rappelez-vous que cette limite représente la quantité maximale de données que votre pilote accumulera, mais ne représente pas et ne devrait pas représenter la contribution de votre pilote à la latence du flux. Votre pilote doit être conçu pour maintenir sa latence aussi faible que possible. Lorsqu’un pilote miniport obtient son ensemble initial de mappages avant de commencer à lire un nouveau flux, il peut continuer à demander des mappages jusqu’à ce qu’il atteigne sa limite de tampon (50 millisecondes dans cet exemple) ou qu’aucun mappage supplémentaire ne soit immédiatement disponible. Dans ce dernier cas, cependant, le pilote miniport ne doit pas attendre que d’autres mappages deviennent disponibles avant de commencer à lire le flux. Au lieu de cela, le pilote doit commencer immédiatement à lire les mappages qu’il a déjà obtenus. Plus tard, à mesure que d’autres mappages deviennent disponibles, le pilote peut continuer à acquérir des mappages supplémentaires jusqu’à ce qu’il atteigne sa limite de taille de tampon ou qu’aucun autre mappage ne soit immédiatement disponible.
En général, le matériel DMA d’un appareil WavePci doit être conçu pour accéder directement aux trames audio stockées à des alignements d’octets arbitraires et qui chevauchent les limites entre des pages de mémoire physique non contiguës. Si vous avez un appareil qui nécessite que les mappages soient un nombre entier de trames audio, cet appareil est limité dans les types de formats audio qu’il prend en charge. Bien sûr, un appareil avec cette limitation devrait toujours pouvoir gérer une taille de trame audio qui est une puissance de deux.
Par exemple, un appareil avec quatre canaux et une taille d’échantillon de 16 bits nécessite une taille de trame audio de huit octets. Un nombre entier de trames audio s’intègre parfaitement dans une page (ou toute autre taille de trame d’allocation qui est un multiple de huit octets). Cependant, dans le cas d’un flux à 5.1 canaux avec des échantillons de 16 bits, la taille de la trame audio est de 12 octets et un flux qui dépasse la taille d’une seule page contient nécessairement des trames audio qui chevauchent les limites des pages. (Les figures dans Wave Filters illustrent ce problème.) Le matériel qui ne peut pas gérer des alignements d’octets arbitraires et des mappages de longueur d’octets arbitraires doit dépendre du pilote pour effectuer une copie intermédiaire, ce qui dégrade les performances.
Le pilote d’adaptateur d’échantillon Ac97 dans le Kit de pilotes de Microsoft Windows (WDK) implémente une méthode GetAllocatorFraming. Le pilote miniport utilise cette méthode pour communiquer sa taille d’allocation de trame préférée. Dans Windows 2000 et Windows Me, le pilote de port appelle cette méthode uniquement lorsque le pilote système de répartiteur (Splitter.sys) est instancié au-dessus de la broche de sortie. Dans Windows XP et les versions ultérieures, le pilote de port appelle cette méthode pour les flux d’entrée également. Rappelez-vous que SysAudio peut choisir d’ignorer les préférences du pilote miniport lorsqu’il décide de la taille de l’allocation de trame.