Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die hardwareoffene Audioverarbeitung ermöglicht die Ausführung der wichtigsten Audioverarbeitungsaufgaben außerhalb der Haupt-CPU des Computers.
Die Audioverarbeitung kann sehr rechenintensiv sein. Daher kann es in vielen Szenarien von Vorteil sein, einem dedizierten Prozessor die Verarbeitungsaufgaben wie das Mischen und Anwenden von Effekten zu ermöglichen.
Wenn Sie einen Treiber für ausgelagerte Audio implementieren, entwickeln Sie einen Treiber, der ausgelagerte Audiodatenströme verarbeiten kann und diese Fähigkeit dem Windows-Audiosystem bereitstellt.
In den folgenden Themen in diesem Abschnitt werden die Treiberentwicklung, die Auswirkungen der Anwendung und andere Probleme erläutert, die Sie beachten sollten, wenn Sie einen Audiotreiber für einen Audioadapter entwickeln, der ein Hardwareaudiomodul zum Behandeln von deaktivierten Audiodatenströmen implementiert.
Hardware-Offloaded-Audio-Treiber-Implementierung
Hilfsschnittstellen für ausgelagerte Audiobearbeitung
Glitch-Berichterstellung für offloaded Audio
Informationen zu ausgelagerten APOs finden Sie unter "Hardware Offloaded APO Effects"
Hardware-Offloaded Architekturübersicht zur Audioverarbeitung
Das Softwareaudiomodul
Das folgende Diagramm zeigt das Windows-Softwareaudiomodul.
Diagramm, das die Architektur des Audiotreibers zeigt, wobei die Anwendung auf SFX-, MFX- und EFX-Effekte zugreift und eine Verbindung zu Treibern und Audio-Hardware herstellt.
Audiostreams kommen über die WASAPI-Ebene (Windows Audio Session API) in das Softwareaudiomodul und möglicherweise über eine API auf höherer Ebene wie Media Foundation ein. In den Software-Audio-Engine-Streameffekten (SFX) können Effekte auf Basis jedes einzelnen Streams angewendet werden, bevor die separaten Datenströme gemischt und dann über alle verfügbaren Endpunkteffekte (EFX) an die Rendering-Hardware und Lautsprecher gesendet werden.
Das Hardwareaudiomodul
Das Hardwareaudiomodul wird im Audioadapter implementiert und spiegelt weitgehend die Funktionalität des Softwareaudiomoduls wieder. Und obwohl Windows die hardwareoffene Audioverarbeitung unterstützt, ist der Audiotreiber für einen bestimmten Audioadapter dafür verantwortlich, die zugrunde liegenden Funktionen der Audiohardware unter Verwendung der im folgenden Diagramm dargestellten Topologie verfügbar zu macht.
Das Hardwareaudiomodul muss einen einzelnen Hostprozessdatenstrom und bis zu n ausgeladene Datenströme akzeptieren. Diese ausgelagerten Datenströme werden direkt aus der Anwendungsschicht zur Verarbeitung in der Hardware geroutet. Mit anderen Worten werden die ausgelagerten Datenströme nicht durch die Software-Audio-Engine geleitet. Das Diagramm zeigt eine Implementierung, die für die Verarbeitung von bis zu drei ausgeladenen Datenströmen konzipiert wurde. Der Hostprozessdatenstrom ist die endgültige Ausgabe des Softwaremixers aller Datenströme, die im Softwareaudiomodul verarbeitet wurden. Jedes Hardwareaudiomodul muss auch einen Hardwaremischer enthalten.
Um die Parität mit dem Softwareaudiomodul und der WASAPI-Schnittstelle aufrechtzuerhalten, ist es erforderlich, dass das Hardwareaudiomodul den endgültigen Audioausgabedatenstrom in Form eines Loopbackdatenstroms zurück zum Audiostapel bereitstellt. Dies ist besonders wichtig für Anwendungen und Szenarien, die auf Acoustic Echo Cancellation basieren, was Kenntnisse über den endgültigen Ausgabedatenstrom erfordert, um Echos abzubrechen und Feedback zu verhindern.
Um einen Pfad für einen Loopbackdatenstrom zu implementieren, ist der Audiotreiber für die Bereitstellung einer Loopback-Pin verantwortlich. Diese Pin gibt die Audiodaten aus der endgültigen Audiomodulausgabe zurück, wenn die Daten in einem PCM-Format codiert sind. Andernfalls wird das Ergebnis nach dem Mischen, aber vor dem Kodieren, zurückgegeben. Dies bedeutet, dass bei Audiodaten, die mit einem Hardware-EFX verarbeitet werden und in ein Nicht-PCM-Format codiert werden, der Loopback-Stream direkt nach dem Hardware-Mixer und vor der EFX-Phase in der Hardware-Engine übernommen wird. Informationen zur KS-Filtertopologie, die das Hardwareaudiomodul darstellt, finden Sie unter Hardware Offloaded Audio Driver Implementation.
Integrierte Audioarchitektur
Das folgende Diagramm zeigt eine Übersicht über die resultierende Architektur, wenn ein Hardwareaudiomodul mit dem Windows-Softwareaudiomodul arbeitet.
In einem Szenario, in dem der Audiotreiber seine Unterstützung für die entladene Audioverarbeitung angegeben hat, werden die ersten n (in diesem Fall drei) Datenströme, die initialisiert werden, direkt von der WASAPI-Ebene an das Hardwareaudiomodul weitergeleitet, wobei das Softwareaudiomodul umgangen wird. Alle neuen Audiodatenströme, die nach dem n vom Hardwareaudiomodul unterstützt werden, werden zur Verarbeitung über das Softwareaudiomodul weitergeleitet. Der resultierende Datenstrom des Softwareaudiomoduls wird dann als Hostprozessstream an das Hardwareaudiomodul gesendet. Der Hostprozessdatenstrom wird mit den ersten n Streams gemischt, die EFX-Verarbeitung wird angewendet, und der resultierende Datenstrom wird dann an die Lautsprecher gesendet.
Die KS-Filtertopologie
In Windows 8 und höheren Betriebssystemen wurde Unterstützung für ein Hardwareaudiomodul zur Verarbeitung von Audiostreams bereitgestellt. Wenn Sie einen solchen Audioadapter entwickeln, muss der zugehörige Audiotreiber diese Tatsache dem Audiosystem für den Benutzermodus auf eine bestimmte Weise verfügbar machen, damit das Audiosystem die Features dieses Adapters und seines Treibers ermitteln, verwenden und ordnungsgemäß verfügbar machen kann.
Damit Audiotreiber die Hardwarefunktionen dieser neuen Audioadapter verfügbar machen können, hat Windows 8 eine KS-Filtertopologie eingeführt, die der Treiber verwenden muss:
Wie in der vorherigen Abbildung dargestellt, stellt eine KS-Filtertopologie die Datenpfade über die Hardware dar und zeigt auch die Funktionen an, die auf diesen Pfaden verfügbar sind. Bei einem Audioadapter, der entladene Audio 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 des Softwareaudiomoduls dar.
Eine Loopback-Pin. Dies stellt eine Ausgabe des Hardwareaudiomoduls auf die WASAPI-Ebene (Windows Audio Session API) dar.
Eine Anzahl von ausgelagerten Audio-Pins. Obwohl die Abbildung nur einen Pin dieses Typs zeigt, kann ein IHV eine beliebige Zahl (n) von Pins implementieren.
Der tatsächliche 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 die Ankunft und die Entfernungen der Geräteschnittstelle. Wenn ein Audiogerätetreiber eine neue Instanz der KSCATEGORY_AUDIO Geräteschnittstellenklasse registriert, wird eine Benachrichtigung über die Ankunft der Geräteschnittstelle ausgelöst. Der AudioEndpointBuilder-Dienst erkennt die Ankunftsbenachrichtigung der Geräteschnittstelle und verwendet einen Algorithmus, um die Topologie der Audiogeräte im System zu untersuchen, damit sie geeignete Maßnahmen ergreifen kann.
Wenn Sie Ihren Audiotreiber entwickeln, um einen Adapter zu unterstützen, der offloaded-audio verarbeiten kann, muss Ihr Treiber den KSNODETYPE_AUDIO_ENGINE Audioendpunkt verwenden, um die Funktionen des Hardwareaudiomoduls verfügbar zu machen. Weitere Informationen zum Ermittlungsprozess für Audioendpunkte finden Sie im Audio-Endpunkt-Generator-Algorithmus.
Überlegungen zur Benutzeroberfläche
Sie haben Ihren Audiotreiber entwickelt, um die zugrunde liegenden Hardwarefunktionen eines Audioadapters zu steuern, der offloaded-audio verarbeiten kann. Dies bedeutet, dass Ihr Treiber das beste Wissen über die Steuerung der Adapterfeatures hat. Sie müssen also 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 für die Steuerung von Audioverarbeitungsobjekten (APOs) verwendet wird, die Sie entwickelt haben, kann diese Benutzeroberfläche erweitert werden, um mit Ihrem neuen Audioadapter zu arbeiten. In diesem Fall würden Ihre Erweiterungen auf der Benutzeroberfläche Softwaresteuerelemente für die APOs und Hardwaresteuerelemente für den Adapter bereitstellen.
Auswirkungen der 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 außerdem, dass Desktopanwendungen die Offloading-Funktionen von Audioadaptern nicht verwenden können, die hardware-ausgelagerte Audio unterstützen. Diese Anwendungen können weiterhin Audio rendern, aber nur über den Host-Pin, der das Softwareaudiomodul verwendet.
Wenn eine UWP-App Medieninhalte streamt und Media Foundation, Media Engine oder die HTML 5-Audiotags <> verwendet, wird die App automatisch für das Hardware offloading aktiviert, solange die richtige Audiokategorie für den Datenstrom festgelegt wurde. Die Anmeldung für das Hardware-Offloading erfolgt pro Datenstrom.
UWP-Apps, die WASAPI oder Streamingkommunikation verwenden, müssen sich explizit für das Hardware-Offloading anmelden.