Synchrone und asynchrone Codecbefehle

Die TransferCodecVerbs-Routine ermöglicht Funktionstreibern das Senden von Befehlen an Audio- und Modemcodecs, die mit einem HD-Audiocontroller verbunden sind. Die Codecbefehle können synchron oder asynchron ausgeführt werden:

• Wenn ein Aufruf von TransferCodecVerbs eine Liste von Befehlen sendet, die synchron verarbeitet werden sollen, gibt die Routine erst zurück, nachdem der Codec oder die Codecs alle Befehle verarbeitet haben.

• Wenn ein Aufruf von TransferCodecVerbs eine Liste von Befehlen übermittelt, die asynchron verarbeitet werden sollen, wird die Routine zurückgegeben, sobald der HD-Audiobustreiber die Befehle zur internen Befehlswarteschlange hinzufügt, ohne darauf zu warten, dass die Codecs oder Codecs die Befehle verarbeiten. Nachdem die Codecs die Befehle verarbeitet haben, benachrichtigt der Bustreiber den Funktionstreiber durch Aufrufen einer Rückrufroutine.

Je nach Art der gesendeten Codecbefehle verwendet der Funktionstreiber eine oder mehrere der folgenden Techniken, um Antworten von einem Codec abzurufen:

• Wenn der Funktionstreiber die Antwort des Codecs haben muss, bevor er eine zusätzliche Verarbeitung ausführen kann, verwendet er den synchronen Modus.

• Wenn der Funktionstreiber nicht warten muss, bis die Codecbefehle abgeschlossen sind, um die Codecantworten anzuzeigen und zu wissen, wann die Befehle abgeschlossen sind, ignoriert er den asynchronen Modus, ignoriert die Rückrufroutine (mit Ausnahme der Freisetzung des Speichers für die Codecbefehle), und verwirft oder ignoriert die Antworten auf die Codecbefehle.

• Wenn der Funktionstreiber wissen muss, wann die Codecbefehle abgeschlossen sind, die Antworten jedoch nicht angezeigt werden müssen, verwendet er den asynchronen Modus und basiert auf der Rückrufroutine für die Benachrichtigung. Sie verwirft oder ignoriert jedoch die Antworten auf die Codecbefehle. Die Rückrufroutine kann ein Kernelstreamingereignis (KS) verwenden, um die Benachrichtigung an den Hauptteil des Treibers zu senden.

• Wenn der Funktionstreiber sowohl wissen muss, wenn die Codecbefehle abgeschlossen sind als auch was die Antworten sind, aber die Verarbeitung sofort fortsetzen muss, anstatt auf den Abschluss der Befehle zu warten, verwendet er den asynchronen Modus und vermeidet das Lesen der Antworten, bis sie die Rückrufroutine empfängt. Entweder die Rückrufroutine oder der Hauptteil des Treibers kann die Antworten überprüfen.

TransferCodecVerbs gibt STATUS_SUCCESS zurück, wenn es erfolgreich ist, die Liste der Befehle zur internen Befehlswarteschlange des Bustreibers hinzuzufügen. Obwohl der Anruf erfolgreich war, sind die Antworten möglicherweise noch ungültig. Der Funktionstreiber muss die Statusbits in den Codecantworten überprüfen, um festzustellen, ob sie gültig sind. Diese Regel gilt sowohl für den synchronen als auch für den asynchronen Modus.

Die Ursache einer ungültigen Antwort ist wahrscheinlich eine der folgenden:

• Der Befehl hat den Codec nicht erreicht.

• Der Codec reagierte, aber die Antwort ging verloren, als ein FIFO-Überlauf (First In, First Out) im RIRB auftrat.

Das letztere Problem weist darauf hin, dass die RIRB FIFO nicht ausreichend groß ist.

Jede Codec-Antwort enthält ein IsValid-Flag , um anzugeben, ob die Antwort gültig ist, und ein HasFifoOverrun-Flag , um anzugeben, ob eine RIRB FIFO-Überlauf aufgetreten ist. Wenn IsValid = 0 ist, was darauf hinweist, dass eine Antwort ungültig ist, hilft das HasFifoOverrun-Flag, die Quelle des Fehlers zu identifizieren.

• Wenn HasFifoOverrun = 0 ist, konnte der Codec nicht innerhalb des erforderlichen Zeitintervalls reagieren. Die wahrscheinliche Ursache ist, dass der Befehl nie den Codec erreicht hat.

• Wenn HasFifoOverrun = 1, dann hat der Befehl wahrscheinlich den Codec erreicht, aber die Antwort wurde aufgrund eines FIFO-Überlaufs verloren.

Während eines Aufrufs von TransferCodecCommands stellt der Aufrufer einen Zeiger auf ein Array von HDAUDIO_CODEC_TRANSFER Strukturen bereit. Jede Struktur enthält einen Befehl und stellt Platz für eine Antwort bereit. Der Bustreiber schreibt immer jede Antwort in die Struktur, die den Befehl enthält, der die Antwort ausgelöst hat.

Für jeden Aufruf von TransferCodecCommands wird die Reihenfolge, in der die Befehle verarbeitet werden, durch die Reihenfolge der Befehle im Array bestimmt. Die Verarbeitung des ersten Befehls im Array wird immer abgeschlossen, bevor die Verarbeitung des zweiten Befehls beginnt usw.

Wenn ein Client einen asynchronen Aufruf von TransferCodecCommands vorgibt und dann TransferCodecCommands ein zweites Mal aufruft, ohne auf die Rückrufroutine vom ersten Aufruf zu warten, wird die relative Reihenfolge, in der die beiden Befehlsgruppen aus den beiden Aufrufen verarbeitet werden, durch die Reihenfolge definiert, in der der Client die beiden Befehlsgruppen übermittelt hat. Daher verarbeitet der Bustreiber alle Befehle aus dem ersten Aufruf, bevor er mit der Verarbeitung der Befehle aus dem zweiten Aufruf beginnt.

Die relative Reihenfolge der Befehle, die von zwei verschiedenen Funktionstreiberinstanzen gesendet werden, ist jedoch nicht definiert. (Jede Instanz verfügt über ein eigenes physisches Geräteobjekt.) Wenn beispielsweise " TransferCodecCommands " zum Senden von Befehlen A, B und C in der Reihenfolge A-B-C und instanz 2 "TransferCodecCommands " aufruft, um Befehle "X", "Y" und "Z" in der Reihenfolge "X-Y-Z" zu senden, kann der Bustreiber die Befehle in der Reihenfolge A-X-Y-B-Z-C ausführen.

Wenn separate Funktionstreiberthreads den Zugriff auf dieselbe Gruppe von Hardwareressourcen teilen, kann die relative Reihenfolge von Befehlen aus verschiedenen Treiberthreads wichtig sein. In diesem Fall ist der Funktionstreiber dafür verantwortlich, die Nutzung der Ressourcen zwischen den Threads zu synchronisieren.

Die Hardwareschnittstelle zum Schreiben einer Sequenz von Datenbytes in einen Codec kann z. B. aus einem Indexregister und einem 8-Bit-Datenregister bestehen. Zuerst sendet der Funktionstreiber einen Codecbefehl, um den Startindex in das Indexregister zu laden. Als Nächstes sendet der Treiber einen Befehl, um das erste Byte von Daten in das Datenregister zu schreiben. Das Indexregister wird nach jedem aufeinanderfolgenden Schreiben in das Datenregister erhöht, bis die Übertragung abgeschlossen ist. Wenn jedoch zwei Treiberthreads den Zugriff auf die Index- und Datenregister nicht ordnungsgemäß synchronisieren, ist die relative Reihenfolge des einzelnen Registerzugriffs durch die beiden Threads nicht definiert, und das wahrscheinliche Ergebnis ist Datenbeschädigung oder eine ungültige Hardwarekonfiguration.

Die TransferCodecVerbs-Routine ist in beiden Versionen des HD Audio DDI verfügbar.