Streamlatenz während der Aufzeichnung
Während sich ein Audiodatenstrom im Zustand Ausführen befindet, ist die Rolle des WaveRT-Porttreibers minimal. Wie im folgenden Diagramm dargestellt, erfasst das Audiogerät während des Aufzeichnungsprozesses Audiodaten und schreibt sie in den zyklischen Puffer. Die Audio-Engine liest diese Daten dann aus dem Puffer. Für diese Aktivität ist kein Eingriff des Porttreibers erforderlich. Mit anderen Worten: Audiodaten fließen direkt zwischen der Audiohardware und der Anwendung im Benutzermodus, ohne dass sie von Kernelmodus-Softwarekomponenten berührt werden.
Im folgenden Diagramm werden die Datensatz- und Lesepositionen kontinuierlich von links nach rechts ausgeführt, während der Stream den Puffer durchläuft. Wenn der Datensatz oder die Leseposition das Ende des Puffers erreicht, wird er bis zum Anfang des Puffers umschließen.
Im vorherigen Diagramm wird die Aufzeichnungsposition als Pufferspeicherort des Beispiels identifiziert, das das Audiogerät derzeit aufzeichnet (Aufzeichnung vom Mikrofon über den Analog-Digital-Konverter (ADC). Beachten Sie, dass die Datensatzposition der zukünftige Pufferspeicherort ist, in den das Audiogerät das Beispiel schreibt, nachdem es das FIFO durchlaufen hat. Die Leseposition ist die Pufferposition, aus der die Audio-Engine das nächste Beispiel liest.
Die Latenz zwischen dem Zeitpunkt, zu dem das Audiogerät ein Audiobeispiel im ADC erfasst, bis der Client es liest, ist einfach die Trennung zwischen den Aufzeichnungs- und Lesepositionen. Diese Trennung ist die Summe der folgenden Latenzquellen (im Diagramm als A und B gekennzeichnet):
Latenz A: Nach dem Erfassen von Daten aus dem ADC speichert das Audiogerät die Daten in einem Hardware-FIFO, bis es die Daten in den zyklischen Puffer schreiben kann.
Latenz B: Nachdem das Audiogerät Daten in den zyklischen Puffer geschrieben hat, befinden sich die Daten im Puffer, bis der Client die Daten liest.
Der Client hat keine Kontrolle über Latenz A, die ausschließlich von der Hardware abhängt. Ein typisches FIFO kann etwa 64 Proben aus dem ADC speichern. Der Client steuert jedoch die Latenz B. Wenn Die Latenz B zu groß ist, führt zu unnötigen Verzögerungen im System, aber wenn er zu klein ist, besteht die Gefahr, dass Daten zu früh gelesen werden, bevor das Audiogerät in den Puffer geschrieben wurde.
Obwohl der Client einen Timer einrichten kann, um seinen Pufferlesethread regelmäßig zu aktivieren, erreicht diese Methode nicht die geringste Latenz. Um die Latenz weiter zu verringern, kann der Client das Audiogerät so konfigurieren, dass jedes Mal eine Hardwarebenachrichtigung generiert wird, wenn das Gerät mit dem Schreiben eines neuen Blocks von Aufzeichnungsdaten in den Puffer fertig ist. In diesem Fall wird der Clientthread durch Hardwarebenachrichtigungen statt durch einen Timer aktiviert.
Wenn das Audiogerät die Audio-Engine regelmäßig benachrichtigt, kann der Client die Latenz verringern, als es andernfalls praktisch wäre.
Der Client (in der Regel die Audio-Engine) kann eine Zusammenfassung der Verzögerungen abrufen, die das Audiogerät zur Streamlatenz beiträgt, indem eine KSPROPERTY_RTAUDIO_HWLATENCY Anforderung an den WaveRT-Porttreiber gesendet wird.
Nachdem der Client ermittelt hat, wie viel Trennung zwischen datensatz- und leseposition beibehalten werden soll, überwacht der Client Änderungen an der Datensatzposition, um zu bestimmen, wie stark die Leseposition verzögert werden soll. Unter Windows Server 2008 und höher sendet der Client eine KSPROPERTY_AUDIO_POSITION- oder KSPROPERTY_RTAUDIO_POSITIONREGISTER-Eigenschaftsanforderung, um die Datensatzposition zu bestimmen. Die letztere Anforderungsmethode ist effizienter, da der Client die Datensatzposition direkt lesen kann, ohne dass die Informationen in eine Kernelmodusroutine übergehen.