Filterfabriken
Ein Audioadaptertreiber stellt Filterfabriken bereit, um die Instanziierung von Filtern zu verwalten. Jede Filterfactory kann einen oder mehrere KS-Filter eines bestimmten Typs instanziieren. Wenn ein Filtertyp eine bestimmte Hardwarefunktion kapselt, wird die Anzahl der Filter dieses Typs, die die Factory instanziieren kann, durch die zugrunde liegenden Hardwareressourcen begrenzt.
Da eine Filterfactory einen weitgehend autonomen Block von Hardwarefunktionen verwaltet, kann jede Filterfactory als eigenständiger Gerätetreiber betrachtet werden. Tatsächlich bezieht sich der Begriff Adaptertreiber, wie er im vorherigen Absatz verwendet wird, auf eine Sammlung verwandter Treiber (Filterfabriken), die zusammen verpackt sind, um die verschiedenen Hardwarefunktionen auf einem Adapter Karte zu verwalten.
Wie bei jedem anderen WdM-Treiber (Microsoft Windows Driver Model) übernimmt eine Filterfactory die Energieverwaltungs- und Setupfunktionen. Während der Installation registriert die INF-Datei für den Treiber mindestens einen Filtergerätenamen (siehe Geräteidentifikationszeichenfolgen). Dieser Prozess lädt die Namen in die Systemregistrierung und ordnet jede Filterfactory einer oder mehreren KS-Filterkategorien zu, wie unter Installieren von Geräteschnittstellen für einen Audioadapter beschrieben. Alle Audiogeräte werden unter KSCATEGORY_AUDIO klassifiziert, aber ein Audiogerät kann auch in zusätzliche Kategorien wie KSCATEGORY_RENDER (für ein Audiorenderinggerät) oder KSCATEGORY_CAPTURE (für ein Audioaufnahmegerät) klassifiziert werden. Der Treiber kündigt die allgemeinen Funktionen eines Geräts anhand der verschiedenen Kategorien an, unter denen er den Filter für dieses Gerät registriert. Wenn der SysAudio-Systemtreiber beispielsweise ein Audiogerät eines bestimmten Typs erfordert, sucht er in der Registrierung nach Geräten, die in die entsprechenden Kategorien fallen.
Das Betriebssystem verwendet die Setup-API, wie unter Geräteinstallationskomponenten beschrieben, um alle KSCATEGORY_AUDIO Filterfactorys in der Registrierung zu ermitteln und aufzulisten. Der Registrierungseintrag für jede Factory gibt sowohl den Anzeigenamen der Filterfactory als auch den Gerätenamen an. Hierbei handelt es sich um eine lange Zeichenfolge, die ein Client an den create-file-Aufruf übergibt, der den Filter instanziiert. Dieser Aufruf kann von ZwCreateFile aus dem Kernelmodus oder von CreateFile aus dem Benutzermodus erfolgen. Ein Filter ist ein Kernelmodusobjekt und wird durch ein Kernelhandle identifiziert. Der Create-file-Aufruf gibt ein instance-Handle zurück, das Clients verwenden können, um auf den Filter zu verweisen. Benutzermodusclients oder Upstream-Filter im Audiodiagramm können dieses Handle verwenden, um IOCTL-Anforderungen an den Filter zu senden oder weiterzuleiten. Weitere Informationen zu CreateFile finden Sie in der Dokumentation zu Microsoft Windows SDK.
Ein typischer WDM-Audioadapter Karte kann sich z. B. auf einem PCI-Bus befinden und mehrere E/A-Anschlüsse zum Rendern oder Erfassen von Wellendaten enthalten. Ein einzelnes Audiogerät auf dieser Karte kann analoge Audioausgangsbuchsen zum Anfahren einer Reihe von Lautsprechern und ein Lineoutkabel sowie analoge Audio-In-Buchsen zum Empfangen von Signalen von einem Mikrofon und einem Linein-Kabel enthalten. Das WDM-Audiosystem stellt das Gerät als Filter dar und stellt die Audiobuchsen als Pins an diesem Filter dar.
Der Filter für ein Audiogerät wird als separate Port- und Miniporttreiber implementiert, die miteinander verbunden sind, um gemeinsam zu handeln:
Der Miniporttreiber enthält den hardwarespezifischen Code.
Der Porttreiber enthält den generischen Code, der allen Filtern eines bestimmten Typs gemeinsam ist.
Der Hersteller schreibt den Miniporttreiber, der den gesamten proprietären Code enthält, den der Filter zum Verwalten der Audiohardware benötigt. Das Betriebssystem stellt den Porttreiber bereit, auf den über den PortCls-Systemtreiber zugegriffen werden kann (Portcls.sys; siehe Port Class Adapter Driver und PortCls System Driver). Die Aufteilung der Filterimplementierung in Port- und Miniporttreiber vereinfacht die Erstellung eines Treibers für ein proprietäres Gerät.
Wenn eine Filterfactory einen Filter instanziiert, erstellt sie zuerst das Miniporttreiberobjekt für den Filter. Anschließend erstellt die Filterfactory eine instance des entsprechenden Portobjekts und bindet das Miniporttreiberobjekt an dieses instance, um einen voll funktionsfähigen Filter zu bilden. Das Codebeispiel in der Untergeräteerstellung veranschaulicht diesen Vorgang. Die Port- und Miniporttreiber kommunizieren über klar definierte Softwareschnittstellen miteinander. Weitere Informationen zu diesen Schnittstellen finden Sie unter Miniport-Schnittstellen und Unterstützen eines Geräts.
Ein Audiofilter macht die Struktur des zugrunde liegenden Audiogeräts als Sammlung von Pinfactorys, Knoten und internen Verbindungen verfügbar. Der Miniporttreiber konsolidiert diese Informationen in einem Filterdeskriptor, der eine Struktur vom Typ PCFILTER_DESCRIPTOR ist. Diese Struktur enthält wiederum einzelne Deskriptoren für die Pinfactorys, Knoten und internen Verbindungen des Filters. Diese Deskriptoren sind Strukturen der folgenden Typen:
Um den Filterdeskriptor vom Miniporttreiber abzurufen, ruft der Porttreiber die IMiniport::GetDescription-Methode auf.
Ein Beispiel dafür, wie ein Treiber seine PCFILTER_DESCRIPTOR-Struktur einrichtet, finden Sie im Sysvad-Beispieltreiber, der unter Beispielaudiotreiber erläutert wird.