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. En tant que tel, il contient un modèle de minutage plus complexe que celui fourni par un appareil UART pur.

Les événements sont remis au pilote miniport (et capturés à partir de) avec un horodatage associé. Cet horodatage est relatif à une horloge master. L’horloge master est la même que celle utilisée par tous les séquencements dans l’ensemble du système. L’heure de l’horloge principale est mesurée en unités de cycles de 100 nanosecondes.

Le pilote miniport obtient l’heure actuelle à partir de l’horloge master en appelant IMasterClock::GetTime. Au moment de la création de l’épingle, le pilote de port transmet l’interface IMasterClock en mode noyau au pilote miniport comme l’un des paramètres d’entrée de la méthode IMiniportDMus::NewStream . Actuellement, l’horloge master encapsule l’horloge en temps réel système. L’horloge master ne change jamais lorsqu’il existe des broches qui nécessitent qu’elle soit à l’état d’exécution. Il s’agit d’une horloge à fréquence constante qui ne s’interrompt jamais.

Tous les appareils de rendu ont une certaine latence entre le moment où ils acceptent un événement et le moment où 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 des événements suffisamment à l’avance pour qu’ils puissent être lus à 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 d’une broche, le pilote de port interroge le pilote miniport pour une durée delta en unités de 100 nanosecondes. Cette heure delta correspond à l’avance de l’heure de présentation de chaque événement que le pilote miniport souhaite recevoir l’événement. Le pilote de port fait de son mieux pour livrer des événements aussi loin devant. Si vous spécifiez une valeur très élevée pour ce delta (spécifié par le paramètre SchedulePreFetch de IMiniportDMus::NewStream), le pilote de port transmet les événements au pilote miniport dès qu’ils sont remis au pilote de port à partir du mode utilisateur.

• Informer les applications de la planification des événements. 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 les événements peuvent être soumis à leur heure de présentation, plus l’application et le synthé peuvent interagir de manière réactive. 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 où un événement peut être planifié pour être lu et toujours lu à l’heure. 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 du miniport est interrogé pour KSPROPSETID_Synth et KSPROPERTY_SYNTH_LATENCYCLOCK. Le gestionnaire de propriétés du pilote miniport doit retourner une horloge de latence qui spécifie, en termes d’horloge master, la prochaine fois que les données pourront être rendues à l’heure. Par exemple, si l’horloge master lit actuellement 50 et qu’il existe actuellement 25 unités de latence, l’horloge de latence indique 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 d’utilisation pour les applications que le delta.