User-Mode Audiokomponenten
In Windows Vista dienen die wichtigsten Audio-APIs als Grundlage des Audiosubsystems für den Benutzermodus. Die wichtigsten Audio-APIs werden als dünne Schicht von Benutzermodussystemkomponenten 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 wichtigsten Audio-APIs auf Audiogeräte zu. Darüber hinaus kommunizieren einige Audioanwendungen direkt mit den kernigen Audio-APIs.
Die wichtigsten Audio-APIs unterstützen den benutzerfreundlichen Begriff eines Audioendpunktgeräts. Ein Audioendpunktgerät ist eine Softwarestraktion, die ein physisches Gerät darstellt, das der Benutzer direkt bearbeitet. Beispiele für Audioendpunktgeräte sind Lautsprecher, Kopfhörer und Mikrofone. Weitere Informationen finden Sie unter Audio-Endpunktgeräte.
Das folgende Diagramm zeigt die wichtigsten Audio-APIs und deren Beziehung zu den anderen Audiokomponenten für den Benutzermodus in Windows Vista.
Der Einfachheit halber zeigt das vorherige Diagramm nur einen Audiorenderungsdatenpfad zum Endpunktgerät an– das Diagramm zeigt keinen Datenpfad für die Audioaufnahme an. Die wichtigsten Audio-APIs umfassen die MMDevice-API, WASAPI-, die DeviceTopology-APIund die EndpointVolume-API-, die in den Audioses.dll- und Mmdevapi.dll Benutzermodussystemmodulen implementiert werden.
Wie im vorherigen Diagramm gezeigt, bieten die Kernaudio-APIs eine Grundlage für die folgenden APIs auf höherer Ebene:
- Media Foundation
- Windows Multimedia waveXxx und MixerXxx Funktionen
- DirectSound
- DirectMusic
DirectSound, die Windows-Multimedia-Audiofunktionen und Media Foundation (über seinen Streaming-Audiorenderer oder SAR, Komponenten) kommunizieren direkt mit den kernigen Audio-APIs. DirectMusic kommuniziert indirekt über DirectSound mit den kernigen Audio-APIs.
Ein Client von WASAPI übergibt Daten an ein Endpunktgerät über einen Endpunktpuffer. Systemsoftware- und Hardwarekomponenten verwalten die Verschiebung von Daten vom Endpunktpuffer auf das Endpunktgerät auf eine Weise, die weitgehend transparent für den Client ist. Darüber hinaus kann der Client für ein Endpunktgerät, das mit der Erkennung von Jack-Presence an einen Audioadapter angeschlossen ist, einen Endpunktpuffer nur für ein Endpunktgerät erstellen, das physisch vorhanden ist. Weitere Informationen zur Erkennung von Jack-Presence finden Sie unter Audio-Endpunktgeräte.
Das vorherige Diagramm zeigt zwei Typen von Endpunktpuffern. Wenn ein Client von WASAPI einen Datenstrom im gemeinsam genutzten Modusöffnet, schreibt der Client Audiodaten in den Endpunktpuffer, und das Windows-Audiomodul liest die Daten aus dem Puffer. In diesem Modus teilt der Client die Audiohardware mit anderen Anwendungen, die in anderen Prozessen ausgeführt werden. Das Audiomodul mischt die Datenströme aus diesen Anwendungen und gibt die resultierende Mischung über die Hardware wieder. Das Audiomodul ist eine Benutzermodus-Systemkomponente (Audiodg.dll), die alle Datenstromverarbeitungsvorgänge in Software ausführt. Wenn ein Client hingegen einen Datenstrom im exklusiven Modusöffnet, hat der Client exklusiven Zugriff auf die Audiohardware. In der Regel erfordern nur eine kleine Anzahl von "Pro-Audio" oder RTC-Anwendungen exklusiven Modus. Obwohl das Diagramm sowohl den Datenstrom für den gemeinsam genutzten Modus als auch den Exklusivmodus zeigt, ist je nachdem, ob der Client den Datenstrom im gemeinsam genutzten Modus oder im exklusiven Modus öffnet, nur einer dieser beiden Datenströme (und dessen entsprechender Endpunktpuffer) vorhanden.
Im exklusiven Modus kann der Client den Datenstrom in einem beliebigen Audioformat öffnen, das vom Endpunktgerät unterstützt wird. Im freigegebenen Modus muss der Client den Datenstrom im Mixformat öffnen, das derzeit vom Audiomodul verwendet wird (oder ein Format, das dem Mixformat ähnelt). Die Eingabedatenströme des Audiomoduls und die Ausgabemischung des Moduls sind in diesem Format enthalten.
In Windows 7 wurde ein neues Feature namens Modus mit niedriger Latenz für Datenströme im Freigabemodus hinzugefügt. In diesem Modus wird das Audiomodul im Pullmodus ausgeführt, in dem sich die Latenz erheblich verringert. Dies ist sehr nützlich für Kommunikationsanwendungen, die eine geringe Audiodatenstromlatenz für schnelleres Streaming erfordern.
Anwendungen, die Audiodatenströme 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 an 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 der eines "Audio"-Threads. Weitere Informationen zu MMCSS finden Sie in der Windows SDK-Dokumentation.
Die wichtigsten Audio-APIs unterstützen sowohl PCM- als auch Nicht-PCM-Streamformate. Das Audiomodul kann jedoch nur PCM-Datenströme mischen. Daher können nur Exklusivmodusdatenströme über Nicht-PCM-Formate verfügen. Weitere Informationen finden Sie unter Geräteformate.
Das Audiomodul wird in einem eigenen geschützten Prozess ausgeführt, der vom Prozess getrennt ist, in dem die Anwendung ausgeführt wird. Zur Unterstützung eines Datenstroms für den gemeinsam genutzten Modus weist der Windows-Audiodienst (das Feld mit der Bezeichnung "Audiodienst" im vorherigen Diagramm) einen prozessübergreifenden Endpunktpuffer zu, der sowohl für die Anwendung als auch für das Audiomodul zugänglich ist. Für den exklusiven Modus befindet sich der Endpunktpuffer im Arbeitsspeicher, der sowohl für die Anwendung als auch für die Audiohardware zugänglich ist.
Der Windows-Audiodienst ist das Modul, das die Windows-Audiorichtlinie implementiert. Die Audiorichtlinie ist eine Reihe interner Regeln, die das System auf die Interaktionen zwischen Audiostreams aus mehreren Anwendungen anwendet, die gemeinsam genutzt und für die Verwendung derselben Audiohardware konkurrieren. Der Windows-Audiodienst implementiert eine Audiorichtlinie, indem die Steuerungsparameter für das Audiomodul festgelegt werden. Zu den Aufgaben des Audiodiensts gehören:
- Verfolgen Sie die Audiogeräte, die der Benutzer dem System hinzufügt oder entfernt.
- Überwachen der Rollen, die den Audiogeräten im System zugewiesen sind.
- Verwalten der Audiodatenströme aus Aufgabengruppen, die ähnliche Klassen von Audioinhalten erzeugen (Konsole, Multimedia und Kommunikation).
- Steuern der Lautstärke des kombinierten Ausgabedatenstroms ("Submix") für jeden der verschiedenen Audioinhaltetypen.
- Informieren des Audiomoduls über die Verarbeitungselemente in den Datenpfaden für die Audiodatenströme.
In einigen Versionen von Windows ist der Windows-Audiodienst standardmäßig deaktiviert und muss explizit aktiviert sein, bevor das System Audio wiedergeben kann.
Im beispiel im vorherigen Diagramm ist das Endpunktgerät eine Reihe von Lautsprechern, die an den Audioadapter angeschlossen sind. Die Clientanwendung schreibt Audiodaten in den Endpunktpuffer, und das Audiomodul verarbeitet die Details des Transports der Daten vom 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. Bei einem Audioadapter 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. Bei einem High Definition Audio Controller und Codec auf einem PCI- oder PCI Express-Bus liefert das System den Adaptertreiber (Hdaudio.sys) und es ist kein vom Anbieter bereitgestellter Treiber erforderlich. Bei einem Audioadapter auf einem USB-Bus liefert das System den AVStream-Klassensystemtreiber (Ks.sys) plus den USB-Audiotreiber (Usbaudio.sys); auch hier ist kein vom Anbieter bereitgestellter Treiber erforderlich.
Der Einfachheit halber zeigt das vorherige Diagramm nur Renderingdatenströme an. Die wichtigsten Audio-APIs unterstützen jedoch auch Aufnahmedatenströme. Im freigegebenen Modus können mehrere Clients den aufgenommenen Datenstrom von einem Audiohardwaregerät freigeben. Im exklusiven Modus hat ein Client exklusiven Zugriff auf den erfassten Datenstrom vom Gerät.
Verwandte Themen