User-Mode Audiokomponenten

In Windows Vista dienen die kernigen Audio-APIs als Grundlage des Audiosubsystems im Benutzermodus. Die Kernaudio-APIs werden als dünne Schicht von Systemkomponenten für den Benutzermodus implementiert, die Benutzermodusclients von Kernelmodus-Audiotreibern und Audiohardware trennen. Audio-APIs auf höherer Ebene, z. B. DirectSound und die Windows-Multimediafunktionen, greifen über die Kernaudio-APIs auf Audiogeräte zu. Darüber hinaus kommunizieren einige Audioanwendungen direkt mit den Kernaudio-APIs.

Die kernigen Audio-APIs unterstützen das benutzerfreundliche Konzept eines Audioendpunktgeräts. Ein Audioendpunktgerät ist eine Software-Abstraktion, die ein physisches Gerät darstellt, das der Benutzer direkt bearbeitet. Beispiele für Audioendpunkte sind Lautsprecher, Kopfhörer und Mikrofone. Weitere Informationen finden Sie unter Audioendpunktgeräte.

Das folgende Diagramm zeigt die wichtigsten Audio-APIs und deren Beziehung zu den anderen Benutzermodus-Audiokomponenten in Windows Vista.

Der Einfachheit halber zeigt das vorherige Diagramm nur einen Audiorenderingdatenpfad zum Endpunktgerät. Das Diagramm zeigt keinen Audiodatenpfad. Zu den kernen Audio-APIs gehören die MMDevice-API, WASAPI, die DeviceTopology-API und die EndpointVolume-API, die in den systemmodulen Audioses.dll und Mmdevapi.dll Benutzermodus implementiert sind.

Wie im vorherigen Diagramm gezeigt, stellen die Kernaudio-APIs eine Grundlage für die folgenden APIs auf höherer Ebene bereit:

• Media Foundation
• Windows-Multimediafunktionen waveXxx und mixerXxx
• Directsound
• Directmusic

DirectSound, die Windows-Multimedia-Audiofunktionen und Media Foundation (über seine Streaming-Audiorenderer oder SAR-Komponente) kommunizieren direkt mit den Kernaudio-APIs. DirectMusic kommuniziert indirekt über DirectSound mit den Kernaudio-APIs.

Ein WASAPI-Client übergibt Daten über einen Endpunktpuffer an ein Endpunktgerät. Systemsoftware und Hardwarekomponenten verwalten die Verschiebung von Daten aus dem Endpunktpuffer auf das Endpunktgerät auf eine Weise, die für den Client weitgehend transparent ist. Darüber hinaus kann der Client für ein Endpunktgerät, das an einen Audioadapter mit Jack-Presence-Erkennung angeschlossen wird, einen Endpunktpuffer nur für ein Endpunktgerät erstellen, das physisch vorhanden ist. Weitere Informationen zur Erkennung von Jack-Presence finden Sie unter Audioendpunktgeräte.

Das obige Diagramm zeigt zwei Typen von Endpunktpuffern. Wenn ein Wasapi-Client einen Stream im freigegebenen Modus öffnet, schreibt der Client Audiodaten in den Endpunktpuffer, und die Windows-Audio-Engine liest die Daten aus dem Puffer. In diesem Modus teilt der Client die Audiohardware mit anderen Anwendungen, die in anderen Prozessen ausgeführt werden. Die Audio-Engine mischt die Streams aus diesen Anwendungen und gibt die resultierende Mischung über die Hardware wieder. Die Audio-Engine ist eine Systemkomponente (user-mode system component, Audiodg.dll), die alle ihre Streamverarbeitungsvorgänge in Software ausführt. Wenn ein Client hingegen einen Stream im exklusiven Modus öffnet, hat der Client exklusiven Zugriff auf die Audiohardware. In der Regel erfordert nur eine kleine Anzahl von Pro-Audio- oder RTC-Anwendungen den exklusiven Modus. Obwohl das Diagramm sowohl die Datenströme im gemeinsamen Modus als auch im exklusiven Modus zeigt, ist nur einer dieser beiden Streams (und der zugehörige Endpunktpuffer) vorhanden, je nachdem, ob der Client den Stream im freigegebenen Modus oder im exklusiven Modus öffnet.

Im exklusiven Modus kann der Client den Stream in einem beliebigen Audioformat öffnen, das vom Endpunktgerät unterstützt wird. Im freigegebenen Modus muss der Client den Stream in dem Mixformat öffnen, das derzeit von der Audio-Engine verwendet wird (oder einem Format, das dem Mixformat ähnelt). Die Eingabestreams der Audio-Engine und die Ausgabemischung der Engine haben alle dieses Format.

In Windows 7 wurde ein neues Feature namens Modus mit niedriger Latenz für Streams im Freigabemodus hinzugefügt. In diesem Modus wird die Audio-Engine im Pullmodus ausgeführt, in dem die Latenz erheblich reduziert wird. Dies ist sehr nützlich für Kommunikationsanwendungen, die eine geringe Audiostreamlatenz für schnelleres Streaming erfordern.

Anwendungen, die Audiostreams mit geringer Latenz verwalten, können den Multimedia Class Scheduler Service (MMCSS) in Windows Vista verwenden, um die Priorität von Anwendungsthreads zu erhöhen, die auf Endpunktpuffer zugreifen. MIT MMCSS können Audioanwendungen mit hoher Priorität ausgeführt werden, ohne CPU-Ressourcen für Anwendungen mit niedrigerer Priorität zu verweigern. MMCSS weist einem Thread basierend auf seinem Aufgabennamen eine Priorität zu. Windows Vista unterstützt beispielsweise die Aufgabennamen "Audio" und "Pro Audio" für Threads, die Audiostreams verwalten. Standardmäßig ist die Priorität eines "Pro Audio"-Threads höher als die eines "Audio"-Threads. Weitere Informationen zu MMCSS finden Sie in der Windows SDK-Dokumentation.

Die Kernaudio-APIs unterstützen sowohl PCM- als auch Nicht-PCM-Streamformate. Die Audio-Engine kann jedoch nur PCM-Streams mischen. Daher können nur Datenströme im exklusiven Modus Nicht-PCM-Formate aufweisen. Weitere Informationen finden Sie unter Geräteformate.

Die Audio-Engine wird in einem eigenen geschützten Prozess ausgeführt, der vom Prozess getrennt ist, in dem die Anwendung ausgeführt wird. Um einen Stream im freigegebenen Modus zu unterstützen, weist der Windows-Audiodienst (das Feld im vorherigen Diagramm mit der Bezeichnung "Audiodienst") einen prozessübergreifenden Endpunktpuffer zu, auf den sowohl die Anwendung als auch die Audio-Engine zugreifen können. Im exklusiven Modus befindet sich der Endpunktpuffer im Arbeitsspeicher, auf den sowohl die Anwendung als auch die Audiohardware zugreifen können.

Der Windows-Audiodienst ist das Modul, das die Windows-Audiorichtlinie implementiert. Bei der Audiorichtlinie handelt es sich um eine Reihe interner Regeln, die das System auf die Interaktionen zwischen Audiostreams von mehreren Anwendungen anwendet, die dieselbe Audiohardware gemeinsam nutzen und konkurrieren. Der Windows-Audiodienst implementiert eine Audiorichtlinie, indem er die Steuerungsparameter für die Audio-Engine festlegt. Zu den Aufgaben des Audiodiensts gehören:

• Nachverfolgen der Audiogeräte, die der Benutzer dem System hinzufügt oder daraus entfernt.
• Überwachen der Rollen, die den Audiogeräten im System zugewiesen sind.
• Verwalten der Audiodatenströme aus Aufgabengruppen, die ähnliche Klassen von Audioinhalten (Konsole, Multimedia und Kommunikation) erzeugen.
• Steuern der Lautstärke des kombinierten Ausgabestreams ("Submix") für jeden der verschiedenen Arten von Audioinhalten.
• Informieren Sie die Audio-Engine über die Verarbeitungselemente in den Datenpfaden für die Audiostreams.

In einigen Versionen von Windows ist der Windows-Audiodienst standardmäßig deaktiviert und muss explizit aktiviert werden, bevor das System Audio wiedergeben kann.

Im Beispiel, das im vorherigen Diagramm gezeigt wird, besteht das Endpunktgerät aus einer Reihe von Lautsprechern, die an den Audioadapter angeschlossen sind. Die Clientanwendung schreibt Audiodaten in den Endpunktpuffer, und die Audio-Engine verarbeitet die Details zum Transport der Daten aus dem Puffer zum Endpunktgerät.

Das Feld mit der Bezeichnung "Audiotreiber" im vorherigen Diagramm kann eine Kombination aus vom System bereitgestellten und vom Anbieter bereitgestellten Treiberkomponenten sein. Im Fall eines Audioadapters auf einem PCI- oder PCI-Express-Bus stellt das System den Port Class-Systemtreiber (Portcls.sys) bereit, der eine Reihe von Porttreibern für die verschiedenen Audiofunktionen im Adapter implementiert, und der Hardwareanbieter stellt einen Adaptertreiber bereit, der eine Reihe von Miniporttreibern implementiert, um gerätespezifische Vorgänge für die Porttreiber zu verarbeiten. Im Falle eines High Definition-Audiocontrollers und -Codecs auf einem PCI- oder PCI Express-Bus stellt das System den Adaptertreiber (Hdaudio.sys) bereit, und es wird kein vom Anbieter bereitgestellter Treiber benötigt. Im Falle eines Audioadapters auf einem USB-Bus stellt das System den AVStream-Klassensystemtreiber (Ks.sys) sowie den USB-Audiotreiber (Usbaudio.sys) bereit. auch hier ist kein vom Anbieter bereitgestellter Treiber erforderlich.

Der Einfachheit halber zeigt das obige Diagramm nur Renderingstreams. Die Kernaudio-APIs unterstützen jedoch auch Aufzeichnungsstreams. Im freigegebenen Modus können mehrere Clients den erfassten Stream von einem Audiohardwaregerät gemeinsam nutzen. Im exklusiven Modus hat ein Client exklusiven Zugriff auf den erfassten Stream vom Gerät.

Zugehörige Themen

Programmierhandbuch