Horloges de latence

Le modèle de pilote miniport du synthétiseur est conçu pour permettre la synchronisation de la sortie audio entre plusieurs appareils. Par conséquent, il contient un modèle de minutage plus complexe que celui fourni par un appareil UART pur.

Les événements sont remis à (et capturés depuis) le pilote miniport avec un horodatage associé. Cet horodatage est relatif à une horloge principale. L’horloge principale est la même horloge utilisée par tous les séquencements dans l’ensemble du système. Le temps d’horloge maître est mesuré en unités de 100 nanosecondes.

Le pilote miniport obtient l’heure actuelle de l’horloge principale en appelant IMasterClock ::GetTime. Au moment de la création de la broche, le pilote de port transmet l'interface IMasterClock en mode kernel au pilote miniport comme paramètre d'entrée de la méthode IMiniportDMus::NewStream. Actuellement, l’horloge principale encapsule l’horloge en temps réel du système. L'horloge principale ne change jamais lorsque des broches nécessitent qu'elle soit dans l'état de fonctionnement. Il s’agit d’une horloge à taux constant qui ne s’interrompt jamais.

Tous les appareils de rendu ont une certaine latence entre le moment où ils acceptent un événement et l’heure à laquelle l’événement peut être entendu. Cette latence peut être constante ou variable (comme dans le cas d’un synthétiseur logiciel, où la latence dépend de la position de lecture actuelle de la mémoire tampon audio). Cette latence est compensée par :

• Permettre au pilote miniport DMus de recevoir les événements suffisamment à l’avance afin qu’ils puissent être exécutés à temps, malgré la latence de l’appareil. Les événements sont séquencés pour le pilote miniport par un moteur de séquenceur dans le pilote de port DMus.

  Au moment de la création de l'épingle, le pilote de port interroge le pilote miniport pour un temps delta en unités de 100 nanosecondes. Le délai delta représente l'avance avec laquelle le pilote miniport souhaite recevoir chaque événement par rapport à son heure de présentation. Le pilote de port fait de son mieux pour livrer les événements à l'avance. La spécification d’une très grande valeur pour ce delta (spécifiée par le paramètre SchedulePreFetch de IMiniportDMus::NewStream) oblige le pilote de port à passer les événements au pilote miniport dès qu’ils sont livrés au pilote de port depuis le mode utilisateur.

• Informer les applications de la distance temporelle jusqu’à laquelle les événements doivent être planifiés. L’utilisation de la latence maximale n’est pas souhaitable dans ce cas. Étant donné que les événements ne peuvent pas être annulés une fois qu’ils sont envoyés, plus tôt les événements peuvent être soumis au moment de leur présentation, plus l’application et le synthétiseur peuvent interagir. Pour gérer cette exigence, DirectMusic a introduit le concept d’horloge de latence.

  L’horloge de latence fournit l’heure la plus proche dans le futur à laquelle un événement peut être programmé pour être joué et être joué à temps. En d’autres termes, si l’application planifie la lecture d’un événement avant l’heure actuelle en fonction de l’horloge de latence, l’événement est lu en retard. Les pilotes miniport du synthétiseur fournissent une horloge de latence en répondant à l’élément de propriété KSPROPERTY_SYNTH_LATENCYCLOCK .

  Le pilote miniport est consulté pour KSPROPSETID_Synth et KSPROPERTY_SYNTH_LATENCYCLOCK. Le gestionnaire de propriétés du pilote miniport doit renvoyer une horloge de latence qui spécifie, en termes d’horloge principale, le moment où les données peuvent être rendues à temps. Par exemple, si l’horloge principale lit actuellement 50 et qu’il y a actuellement 25 unités de latence, l’horloge de latence lit 75. La raison pour laquelle l’horloge est implémentée de cette façon est que la latence n’a pas besoin d’être constante et que la valeur retournée est plus utilisée pour les applications que le delta.