Audioverarbeitung per Hardware-Offloading
Durch die hardwareausgeladene Audioverarbeitung können die Standard Audioverarbeitungsaufgaben außerhalb der Standard CPU des Computers ausgeführt werden.
Die Audioverarbeitung kann sehr rechenintensiv sein. Daher kann es in vielen Szenarien von Vorteil sein, einem dedizierten Prozessor die Verarbeitungsaufgaben zu ermöglichen, z. B. das Mischen und Anwenden von Effekten.
Wenn Sie einen Treiber für ausgeladene Audiodaten implementieren, entwickeln Sie einen Treiber, der in der Lage ist, ausgeladene Audiodatenströme zu verarbeiten und diese Möglichkeit für das Windows-Audiosystem verfügbar zu machen.
In den folgenden Themen in diesem Abschnitt werden die Treiberentwicklung, die Auswirkungen auf die Anwendung und andere Probleme erläutert, die Sie beachten sollten, wenn Sie einen Audiotreiber für einen Audioadapter entwickeln, der eine Hardwareaudio-Engine für die Verarbeitung von ausgeladenen Audiodatenströmen implementiert.
Implementierung des hardwareoffenen Audiotreibers
Hilfsschnittstellen für die Ausgelagerte Audioverarbeitung
Störungsberichterstattung für ausgeladene Audiodaten
Informationen zu ausgeladenen APOs finden Sie unter Hardware offloaded APO Effects.
Architektur der Hardware-Offloaded Audioverarbeitung
Die Softwareaudio-Engine
Das folgende Diagramm zeigt die Windows-Softwareaudio-Engine.
Audiodatenströme gelangen in der Softwareaudio-Engine von der WASAPI-Ebene (Windows Audio Session API) und möglicherweise über eine höherwertige API wie Media Foundation. In der Software-Audio-Engine können Streameffekte (SFX) pro Stream angewendet werden, bevor die separaten Streams gemischt werden, und dann durch alle verfügbaren Endpunkteffekte (EFX) übergeben und an die Renderinghardware und die Lautsprecher gesendet werden.
Die Hardwareaudio-Engine
Die Hardwareaudio-Engine ist im Audioadapter implementiert und spiegelt weitgehend die Funktionalität der Softwareaudio-Engine wieder. Obwohl Windows die hardwareoffene Audioverarbeitung unterstützt, ist der Audiotreiber für einen bestimmten Audioadapter für das Verfügbarmachen der zugrunde liegenden Funktionen der Audiohardware verantwortlich, wobei die im folgenden Diagramm gezeigte Topologie verwendet wird.
Die Hardwareaudio-Engine muss einen einzelnen Hostprozessstream und bis zu n ausgeladene Streams akzeptieren. Diese ausgelagerten Datenströme werden direkt von der Anwendungsschicht weitergeleitet, um sie in Hardware zu verarbeiten. Anders ausgedrückt: Die ausgeladenen Streams werden nicht über die Softwareaudio-Engine übergeben. Das Diagramm zeigt eine Implementierung, die für die Verarbeitung von bis zu drei ausgeladenen Streams konzipiert wurde. Der Hostprozessstream ist die endgültige Ausgabe des Softwaremixers aller Streams, die in der Softwareaudio-Engine verarbeitet wurden. Jede Hardwareaudio-Engine muss auch einen Hardwaremixer enthalten.
Um die Parität mit der Softwareaudio-Engine und der WASAPI-Schnittstelle zu erhalten, ist es erforderlich, dass die Hardwareaudio-Engine den endgültigen Audioausgabedatenstrom in Form eines Loopbackstreams an den Audiostapel zurückgibt. Dies ist besonders wichtig für Anwendungen und Szenarien, die auf der akustischen Echounterdrückung basieren, die Kenntnis des endgültigen Ausgabedatenstroms erfordert, um Echos abzubrechen und Feedback zu verhindern.
Um einen Pfad für einen Loopbackstream zu implementieren, ist der Audiotreiber dafür verantwortlich, einen Loopback-Pin verfügbar zu machen. Dieser Pin gibt die Audiodaten aus der endgültigen Audio-Engine-Ausgabe zurück, wenn die Daten in einem PCM-Format codiert sind. Andernfalls wird das Ergebnis nach dem Mischen (aber vor der Codierung) zurückgegeben. Dies bedeutet, dass bei Audiodaten, die mit einer Hardware-EFX verarbeitet werden, die in einem Nicht-PCM-Format codiert wird, der Loopbackdatenstrom direkt nach dem Hardwaremixer vor der EFX-Phase in der Hardwareaudio-Engine aufgenommen wird. Informationen zur KS-Filtertopologie, die die Hardwareaudio-Engine darstellt, finden Sie unter Hardware Offloaded Audio Driver Implementation.For information about the KS-filter topology that represents the hardware audio engine engine, see Hardware Offloaded Audio Driver Implementation.
Die integrierte Audioarchitektur
Das folgende Diagramm zeigt eine Übersicht über die resultierende Architektur, wenn eine Hardwareaudio-Engine mit der Windows-Softwareaudio-Engine arbeitet.
In einem Szenario, in dem der Audiotreiber seine Unterstützung für die ausgeladene Audioverarbeitung angegeben hat, werden die ersten initialisierten n (in diesem Fall drei) Datenströme direkt von der WASAPI-Ebene an die Hardwareaudio-Engine weitergeleitet, wobei die Softwareaudio-Engine umgangen wird. Alle neuen Audiostreams, die nach dem von der Hardwareaudio-Engine unterstützten n-Audiostreams erfolgen, werden zur Verarbeitung über die Softwareaudio-Engine weitergeleitet. Der resultierende Stream von der Softwareaudio-Engine wird dann als Hostprozessstream an die Hardwareaudio-Engine gesendet. Der Hostprozessstream wird mit den ersten n Streams gemischt, die EFX-Verarbeitung wird angewendet, und der resultierende Stream wird dann an die Lautsprecher gesendet.
Die KS-Filtertopologie
In Windows 8 und späteren Betriebssystemen wurde Unterstützung für eine onboard-Hardwareaudio-Engine zur Verarbeitung von Audiodatenströmen bereitgestellt. Wenn Sie einen solchen Audioadapter entwickeln, muss der zugehörige Audiotreiber diese Tatsache dem Audiosystem im Benutzermodus auf bestimmte Weise zur Verfügung stellen, damit das Audiosystem die Features dieses Adapters und seines Treibers erkennen, verwenden und ordnungsgemäß verfügbar machen kann.
Damit Audiotreiber die Hardwarefunktionen dieser neuen Audioadapter verfügbar machen können, Windows 8 eine KS-Filtertopologie eingeführt, die der Treiber verwenden muss:
Wie in der vorherigen Abbildung gezeigt, stellt eine KS-Filtertopologie die Datenpfade durch die Hardware dar und zeigt auch die Funktionen an, die auf diesen Pfaden verfügbar sind. Im Fall eines Audioadapters, der ausgeladene Audiodaten verarbeiten kann, gibt es die folgenden Ein- und Ausgänge (als Pins bezeichnet) im KS-Filter:
Ein Hostprozess-Pin. Dies stellt die Eingabe in den KS-Filter von der Softwareaudio-Engine dar.
Ein Loopback-Pin. Dies stellt eine Ausgabe der Hardwareaudio-Engine an die WASAPI-Ebene (Windows Audio Session API) dar.
Eine Reihe von ausgeladenen Audio-Pins. Obwohl die Abbildung nur einen Pin dieses Typs zeigt, kann ein IHV eine beliebige Anzahl (n) von Pins implementieren.
Der eigentliche Dienst im Audiosystem im Benutzermodus, der zur Ermittlung des Audioadapters und seines Treibers "führt", ist der AudioEndpointBuilder. Der AudioEndpointBuilder-Dienst überwacht die KSCATEGORY_AUDIO-Klasse auf Geräteschnittstellenein- und -entfernungen. Wenn ein Audiogerätetreiber eine neue instance der geräteschnittstellenklasse KSCATEGORY_AUDIO registriert, wird eine Benachrichtigung zum Eingang der Geräteschnittstelle ausgelöst. Der AudioEndpointBuilder-Dienst erkennt die Eingangsbenachrichtigung der Geräteschnittstelle und verwendet einen Algorithmus, um die Topologie der Audiogeräte im System zu untersuchen, damit die entsprechenden Maßnahmen ergriffen werden können.
Wenn Sie Ihren Audiotreiber so entwickeln, dass er einen Adapter unterstützt, der ausgeladenes Audio verarbeiten kann, muss Ihr Treiber den KSNODETYPE_AUDIO_ENGINE Audioendpunkt verwenden, um die Funktionen der Hardwareaudio-Engine verfügbar zu machen. Weitere Informationen zum Ermittlungsprozess für Audioendpunkte finden Sie unter AudioEndpunkt-Generator-Algorithmus.
Überlegungen zur Benutzeroberfläche
Sie haben Ihren Audiotreiber entwickelt, um die zugrunde liegenden Hardwarefunktionen eines Audioadapters zu steuern, der ausgeladenes Audio verarbeiten kann. Dies bedeutet, dass Ihr Treiber über die besten Kenntnisse darüber verfügt, wie die Features des Adapters gesteuert werden. Daher müssen Sie eine Benutzeroberfläche entwickeln, die die Features des Adapters für den Endbenutzer in Form von Optionen verfügbar macht, die er auswählen, aktivieren und/oder deaktivieren kann.
Wenn Sie jedoch bereits über eine Benutzeroberfläche verfügen, die zum Steuern von von Ihnen entwickelten Audioverarbeitungsobjekten (Audio Processing Objects, APOs) verwendet wird, kann diese Benutzeroberfläche erweitert werden, um mit Ihrem neuen Audioadapter zu arbeiten. In diesem Fall würden Ihre Erweiterungen der Benutzeroberfläche die Softwaresteuerung für die APOs und die Hardwaresteuerung für den Adapter bereitstellen.
Auswirkungen auf die Anwendung
Die für diesen neuen Audioadaptertyp und den zugehörigen Treiber beschriebenen Funktionen können von UWP-Apps über WASAPI, Media Foundation, Media Engine oder die HTML 5-Audiotags <> verwendet werden. Beachten Sie, dass Wave und DSound nicht verwendet werden können, da sie für UWP-Apps nicht verfügbar sind. Beachten Sie auch, dass Desktopanwendungen die Auslagerungsfunktionen von Audioadaptern nicht verwenden können, die hardwareoffene Audiodaten unterstützen. Diese Anwendungen können weiterhin Audio rendern, aber nur über den Host-Pin, der die Softwareaudio-Engine verwendet.
Wenn eine UWP-App Medieninhalte streamt und Media Foundation, Media Engine oder die HTML 5-Audiotags <> verwendet, wird die App automatisch für die Hardwareauslagerung aktiviert, solange die richtige Audiokategorie für den Stream festgelegt wurde. Die Anmeldung für die Hardwareauslagerung erfolgt pro Stream.
UWP-Apps, die WASAPI oder Streamingkommunikation verwenden, müssen sich explizit für die Hardwareausladung anmelden.