Gerätetopologien

Die DeviceTopology-API ermöglicht Clients die Kontrolle über eine Vielzahl interner Funktionen von Audioadaptern, auf die sie nicht über die MMDevice-API-, WASAPI-oder die EndpointVolume-APIzugreifen können.

Wie bereits erläutert, stellen die MMDevice-API, WASAPI-und die EndpointVolume-API Mikrofone, Lautsprecher, Kopfhörer und andere Audioeingabe- und Ausgabegeräte als Audioendpunktgeräte. Das Endpunktgerätemodell bietet Clients bequemen Zugriff auf Lautstärke- und Stummschaltungssteuerungen auf Audiogeräten. Clients, die nur diese einfachen Steuerelemente erfordern, können das Durchlaufen der internen Topologien von Hardwaregeräten in Audioadaptern vermeiden.

In Windows Vista konfiguriert das Audiomodul automatisch die Topologien von Audiogeräten für die Verwendung durch Audioanwendungen. Daher müssen Anwendungen die DeviceTopology-API für diesen Zweck nur selten verwenden. Angenommen, ein Audioadapter enthält einen Eingabe-Multiplexer, der einen Datenstrom entweder von einer Leitungseingabe oder einem Mikrofon erfassen kann, aber keine Datenströme von beiden Endpunktgeräten gleichzeitig erfassen kann. Gehen Sie davon aus, dass der Benutzer Exklusivmodusanwendungen aktiviert hat, um die Verwendung eines Audioendpunktgeräts durch Gemeinsam genutzte Anwendungen vorab zu nutzen, wie in Exclusive-Mode Streamsbeschrieben. Wenn eine Anwendung für den gemeinsam genutzten Modus einen Datenstrom aus der Leitungseingabe zum Zeitpunkt aufzeichnen, zu dem eine Exklusivmodusanwendung mit der Aufzeichnung eines Datenstroms vom Mikrofon beginnt, wechselt das Audiomodul automatisch vom Multiplexer von der Leitungseingabe in das Mikrofon. Im Gegensatz dazu würden in früheren Versionen von Windows, einschließlich Windows XP, die Exklusivmodusanwendung in diesem Beispiel die funktionen mixerXxx in der Windows-Multimedia-API verwenden, um die Topologien der Adaptergeräte zu durchlaufen, den Multiplexer zu ermitteln und den Multiplexer so zu konfigurieren, dass die Mikrofoneingabe ausgewählt wird. In Windows Vista sind diese Schritte nicht mehr erforderlich.

Einige Clients erfordern jedoch möglicherweise explizite Kontrolle über Typen von Audiohardwaresteuerelementen, auf die nicht über die MMDevice-API, WASAPI oder die EndpointVolume-API zugegriffen werden kann. Für diese Clients bietet die DeviceTopology-API die Möglichkeit, die Topologien von Adaptergeräten zu durchlaufen, um die Audiosteuerelemente auf den Geräten zu ermitteln und zu verwalten. Anwendungen, die die DeviceTopology-API verwenden, müssen sorgfältig entworfen werden, um eine Störung der Windows-Audiorichtlinie zu vermeiden und die internen Konfigurationen von Audiogeräten zu stören, die für andere Anwendungen freigegeben sind. Weitere Informationen zur Windows-Audiorichtlinie finden Sie unter User-Mode Audiokomponenten.

Die DeviceTopology-API stellt Schnittstellen zum Ermitteln und Verwalten der folgenden Arten von Audiosteuerelementen in einer Gerätetopologie bereit:

• Automatische Verstärkungskontrolle
• Basssteuerung
• Eingabeauswahl (Multiplexer)
• Lautstärkeregler
• Midrange-Steuerelement
• Steuerelement stummschalten
• Ausgabeauswahl (Demultiplexer)
• Spitzenzähler
• Treble-Steuerelement
• Lautstärkeregler

Darüber hinaus ermöglicht die DeviceTopology-API Clients das Abfragen von Adaptergeräten nach Informationen zu den von ihnen unterstützten Streamformaten. Die Headerdatei Devicetopology.h definiert die Schnittstellen in der DeviceTopology-API.

Das folgende Diagramm zeigt ein Beispiel für mehrere verbundene Gerätetopologien für den Teil eines PCI-Adapters, der Audiodaten von einem Mikrofon, einer Leitungseingabe und einem CD-Player erfasst.

Das vorherige Diagramm zeigt die Datenpfade, die von den analogen Eingaben zum Systembus führen. Jedes der folgenden Geräte wird als Gerätetopologieobjekt mit einer IDeviceTopology--Schnittstelle dargestellt:

• Wave capture device
• Eingabe-Multiplexer-Gerät
• Endpunktgerät A
• Endpunktgerät B

Beachten Sie, dass das Topologiediagramm Adaptergeräte (Die Wellenerfassungs- und Eingabe-Multiplexer-Geräte) mit Endpunktgeräten kombiniert. Durch die Verbindungen zwischen Geräten werden Audiodaten von einem Gerät zum nächsten übergeben. Auf jeder Seite einer Verbindung handelt es sich um einen Verbinder (mit der Bezeichnung Con im Diagramm), über den Daten ein Gerät eingegeben oder verlassen werden.

Am linken Rand des Diagramms gelangen Signale aus den Leitungs- und Mikrofonbuchsen in die Endpunktgeräte.

Innerhalb des Wellenerfassungsgeräts und des Eingabe-Multiplexer-Geräts handelt es sich um Streamverarbeitungsfunktionen, die in der Terminologie der DeviceTopology-API als Untereinheiten bezeichnet werden. Die folgenden Typen von Untereinheiten werden im vorherigen Diagramm angezeigt:

• Lautstärkeregelung (mit Bezeichnung "Vol")
• Stummschalten-Steuerelement (bezeichnet als Stummschalten)
• Multiplexer (oder Eingabeauswahl; beschriftetes MUX)
• Analog-zu-Digital-Konverter (mit Bezeichnung ADC)

Die Einstellungen in den Volume-, Stummschalt- und Multiplexer-Untereinheiten können von Clients gesteuert werden, und die DeviceTopology-API stellt Steuerschnittstellen für Clients bereit, um sie zu steuern. In diesem Beispiel verfügt die ADC-Untereinheit über keine Steuerelementeinstellungen. Daher stellt die DeviceTopology-API keine Steuerungsschnittstelle für den ADC bereit.

In der Terminologie der DeviceTopology-API gehören Connectors und Untereinheiten zur gleichen allgemeinen Kategorie – Teile. Alle Teile stellen unabhängig davon, ob es sich um Verbinder oder Untereinheiten handelt, einen allgemeinen Satz von Funktionen bereit. Die DeviceTopology-API implementiert eine IPart- Schnittstelle, um die generischen Funktionen darzustellen, die für Connectors und Untereinheiten gemeinsam sind. Die API implementiert die IConnector- und ISubunit- Schnittstellen, um die spezifischen Aspekte von Connectors und Untereinheiten darzustellen.

Die DeviceTopology-API erstellt die Topologien des Wellenaufnahmegeräts und des Eingabe-Multiplexer-Geräts aus den Kernelstreamingfiltern (Kernel-Streaming, KS), die der Audiotreiber dem Betriebssystem zur Darstellung dieser Geräte verfügbar macht. (Der Audioadaptertreiber implementiert IMiniportWaveXxx und IMiniportTopology- Schnittstellen zur Darstellung der hardwareabhängigen Teile dieser Filter. Weitere Informationen zu diesen Schnittstellen und zu KS-Filtern finden Sie in der Windows DDK-Dokumentation.)

Die DeviceTopology-API erstellt triviale Topologien, um Endpunktgeräte A und B im vorherigen Diagramm darzustellen. Die Gerätetopologie eines Endpunktgeräts besteht aus einem einzigen Verbinder. Diese Topologie ist lediglich ein Platzhalter für das Endpunktgerät und enthält keine Untereinheiten für die Verarbeitung von Audiodaten. Tatsächlich enthalten Adaptergeräte alle Untereinheiten, die Clientanwendungen zum Steuern der Audioverarbeitung verwenden. Die Gerätetopologie eines Endpunktgeräts dient in erster Linie als Ausgangspunkt für die Untersuchung der Gerätetopologien von Adaptergeräten.

Interne Verbindungen zwischen zwei Teilen in einer Gerätetopologie werden als Verknüpfungen bezeichnet. Die DeviceTopology-API stellt Methoden zum Durchlaufen von Links von einem Teil zum nächsten in einer Gerätetopologie bereit. Die API stellt außerdem Methoden zum Durchlaufen der Verbindungen zwischen Gerätetopologien bereit.

Um mit der Erkundung einer Reihe verbundener Gerätetopologien zu beginnen, aktiviert eine Clientanwendung die IDeviceTopology Schnittstelle eines Audioendpunktgeräts. Der Connector in einem Endpunktgerät stellt entweder eine Verbindung mit einem Connector in einem Audioadapter oder mit einem Netzwerk dar. Wenn der Endpunkt eine Verbindung mit einem Gerät auf einem Audioadapter herstellt, können die Methoden in der DeviceTopology-API die Anwendung auf der anderen Seite der Verbindung vom Endpunkt zum Adapter durchlaufen, indem sie einen Verweis auf die IDeviceTopology Schnittstelle des Adaptergeräts auf der anderen Seite der Verbindung abrufen. Ein Netzwerk verfügt dagegen über keine Gerätetopologie. Eine Netzwerkverbindung übergibt einen Audiodatenstrom an einen Client, der remote auf das System zugreift.

Die DeviceTopology-API bietet nur Zugriff auf die Topologien der Hardwaregeräte in einem Audioadapter. Die externen Geräte am linken Rand des Diagramms und die Softwarekomponenten am rechten Rand liegen außerhalb des API-Bereichs. Die gestrichelten Linien auf beiden Seiten des Diagramms stellen die Grenzen der DeviceTopology-API dar. Der Client kann die API verwenden, um einen Datenpfad zu untersuchen, der sich von der Eingabebuchse bis zum Systembus erstreckt, die API kann jedoch nicht über diese Grenzen hinausdringen.

Jeder Verbinder im vorherigen Diagramm weist einen zugeordneten Verbindungstyp auf, der den Verbindungstyp angibt, den der Verbinder erstellt. So haben die Verbinder auf den beiden Seiten einer Verbindung immer identische Verbindungstypen. Der Verbindungstyp wird durch einen ConnectorType Enumerationswert angegeben – Physical_External, Physical_Internal, Software_Fixed, Software_IO oder Netzwerk. Die Verbindungen zwischen dem Eingabe-Multiplexer-Gerät und den Endpunktgeräten A und B sind vom Typ Physical_External, was bedeutet, dass die Verbindung eine physische Verbindung mit einem externen Gerät darstellt (d. h. eine benutzerfreundliche Audiobuchse). Die Verbindung mit dem analogen Signal vom internen CD-Player ist vom Typ Physical_Internal, der eine physische Verbindung mit einem Hilfsgerät angibt, das innerhalb des System-Chassis installiert ist. Die Verbindung zwischen dem Wellenaufnahmegerät und dem Eingabe-Multiplexer-Gerät ist vom Typ Software_Fixed, der eine dauerhafte Verbindung angibt, die fest ist und nicht unter der Softwaresteuerung konfiguriert werden kann. Schließlich ist die Verbindung mit dem Systembus auf der rechten Seite des Diagramms vom Typ Software_IO, der angibt, dass die Daten-E/A für die Verbindung durch ein DMA-Modul unter Softwaresteuerung implementiert wird. (Das Diagramm enthält kein Beispiel für einen Netzwerkverbindungstyp.)

Der Client beginnt mit dem Durchlaufen eines Datenpfads auf dem Endpunktgerät. Zuerst ruft der Client eine IMMDevice- Schnittstelle ab, die das Endpunktgerät darstellt, wie in Aufzählung von Audiogerätenerläutert. Um die IDeviceTopology Schnittstelle für das Endpunktgerät abzurufen, ruft der Client die IMMDevice::Activate-Methode mit parameter iid auf REFIID IID_IDeviceTopology festgelegt.

Im Beispiel im vorherigen Diagramm enthält das Eingabe-Multiplexer-Gerät alle Hardwaresteuerelemente (Lautstärke, Stummschaltung und Multiplexer) für die Aufnahmedatenströme aus den Leitungs- und Mikrofonbuchsen. Das folgende Codebeispiel zeigt, wie Sie die IDeviceTopology Schnittstelle für das Eingabe-Multiplexer-Gerät über die IMMDevice- Schnittstelle für das Endpunktgerät für die Leitungseingabe oder das Mikrofon abrufen:

//-----------------------------------------------------------
// The input argument to this function is a pointer to the
// IMMDevice interface of an endpoint device. The function
// outputs a pointer (counted reference) to the
// IDeviceTopology interface of the adapter device that
// connects to the endpoint device.
//-----------------------------------------------------------
#define EXIT_ON_ERROR(hres)  \
              if (FAILED(hres)) { goto Exit; }
#define SAFE_RELEASE(punk)  \
              if ((punk) != NULL)  \
                { (punk)->Release(); (punk) = NULL; }

const IID IID_IDeviceTopology = __uuidof(IDeviceTopology);
const IID IID_IPart = __uuidof(IPart);

HRESULT GetHardwareDeviceTopology(
            IMMDevice *pEndptDev,
            IDeviceTopology **ppDevTopo)
{
    HRESULT hr = S_OK;
    IDeviceTopology *pDevTopoEndpt = NULL;
    IConnector *pConnEndpt = NULL;
    IConnector *pConnHWDev = NULL;
    IPart *pPartConn = NULL;

    // Get the endpoint device's IDeviceTopology interface.

    hr = pEndptDev->Activate(
                      IID_IDeviceTopology, CLSCTX_ALL,
                      NULL, (void**)&pDevTopoEndpt);
    EXIT_ON_ERROR(hr)

    // The device topology for an endpoint device always
    // contains just one connector (connector number 0).

    hr = pDevTopoEndpt->GetConnector(0, &pConnEndpt);
    EXIT_ON_ERROR(hr)

    // Use the connector in the endpoint device to get the
    // connector in the adapter device.

    hr = pConnEndpt->GetConnectedTo(&pConnHWDev);
    EXIT_ON_ERROR(hr)

    // Query the connector in the adapter device for
    // its IPart interface.

    hr = pConnHWDev->QueryInterface(
                         IID_IPart, (void**)&pPartConn);
    EXIT_ON_ERROR(hr)

    // Use the connector's IPart interface to get the
    // IDeviceTopology interface for the adapter device.

    hr = pPartConn->GetTopologyObject(ppDevTopo);

Exit:
    SAFE_RELEASE(pDevTopoEndpt)
    SAFE_RELEASE(pConnEndpt)
    SAFE_RELEASE(pConnHWDev)
    SAFE_RELEASE(pPartConn)

    return hr;
}

Die GetHardwareDeviceTopology-Funktion im vorherigen Codebeispiel führt die folgenden Schritte aus, um die IDeviceTopology- Schnittstelle für das Eingabe-Multiplexer-Gerät abzurufen:

1. Rufen Sie die IMMDevice::Activate-Methode auf, um die IDeviceTopology--Schnittstelle für das Endpunktgerät abzurufen.
2. Rufen Sie mit der IDeviceTopology Schnittstelle, die im vorherigen Schritt abgerufen wurde, die IDeviceTopology::GetConnector-Methode auf, um die IConnector- Schnittstelle des einzelnen Verbinders (Verbindernummer 0) auf dem Endpunktgerät abzurufen.
3. Rufen Sie mit der IConnector Schnittstelle, die im vorherigen Schritt abgerufen wurde, die IConnector::GetConnectedTo-Methode auf, um die IConnector- Schnittstelle des Verbinders auf dem Eingabe-Multiplexer-Gerät abzurufen.
4. Abfragen der IConnector- Schnittstelle, die im vorherigen Schritt für die IPart--Schnittstelle abgerufen wurde.
5. Rufen Sie mit der im vorherigen Schritt abgerufenen IPart- Schnittstelle die IPart::GetTopologyObject--Methode auf, um die IDeviceTopology- Schnittstelle für das Eingabe-Multiplexer-Gerät abzurufen.

Bevor der Benutzer im vorherigen Diagramm vom Mikrofon aufzeichnen kann, muss die Clientanwendung sicherstellen, dass der Multiplexer die Mikrofoneingabe auswählt. Im folgenden Codebeispiel wird gezeigt, wie ein Client den Datenpfad vom Mikrofon durchläuft, bis er das Multiplexer findet, das dann zum Auswählen der Mikrofoneingabe programmiert wird:

//-----------------------------------------------------------
// The input argument to this function is a pointer to the
// IMMDevice interface for a capture endpoint device. The
// function traverses the data path that extends from the
// endpoint device to the system bus (for example, PCI)
// or external bus (USB). If the function discovers a MUX
// (input selector) in the path, it selects the MUX input
// that connects to the stream from the endpoint device.
//-----------------------------------------------------------
#define EXIT_ON_ERROR(hres)  \
              if (FAILED(hres)) { goto Exit; }
#define SAFE_RELEASE(punk)  \
              if ((punk) != NULL)  \
                { (punk)->Release(); (punk) = NULL; }

const IID IID_IDeviceTopology = __uuidof(IDeviceTopology);
const IID IID_IPart = __uuidof(IPart);
const IID IID_IConnector = __uuidof(IConnector);
const IID IID_IAudioInputSelector = __uuidof(IAudioInputSelector);

HRESULT SelectCaptureDevice(IMMDevice *pEndptDev)
{
    HRESULT hr = S_OK;
    DataFlow flow;
    IDeviceTopology *pDeviceTopology = NULL;
    IConnector *pConnFrom = NULL;
    IConnector *pConnTo = NULL;
    IPart *pPartPrev = NULL;
    IPart *pPartNext = NULL;
    IAudioInputSelector *pSelector = NULL;

    if (pEndptDev == NULL)
    {
        EXIT_ON_ERROR(hr = E_POINTER)
    }

    // Get the endpoint device's IDeviceTopology interface.
    hr = pEndptDev->Activate(
                      IID_IDeviceTopology, CLSCTX_ALL, NULL,
                      (void**)&pDeviceTopology);
    EXIT_ON_ERROR(hr)

    // The device topology for an endpoint device always
    // contains just one connector (connector number 0).
    hr = pDeviceTopology->GetConnector(0, &pConnFrom);
    SAFE_RELEASE(pDeviceTopology)
    EXIT_ON_ERROR(hr)

    // Make sure that this is a capture device.
    hr = pConnFrom->GetDataFlow(&flow);
    EXIT_ON_ERROR(hr)

    if (flow != Out)
    {
        // Error -- this is a rendering device.
        EXIT_ON_ERROR(hr = AUDCLNT_E_WRONG_ENDPOINT_TYPE)
    }

    // Outer loop: Each iteration traverses the data path
    // through a device topology starting at the input
    // connector and ending at the output connector.
    while (TRUE)
    {
        BOOL bConnected;
        hr = pConnFrom->IsConnected(&bConnected);
        EXIT_ON_ERROR(hr)

        // Does this connector connect to another device?
        if (bConnected == FALSE)
        {
            // This is the end of the data path that
            // stretches from the endpoint device to the
            // system bus or external bus. Verify that
            // the connection type is Software_IO.
            ConnectorType  connType;
            hr = pConnFrom->GetType(&connType);
            EXIT_ON_ERROR(hr)

            if (connType == Software_IO)
            {
                break;  // finished
            }
            EXIT_ON_ERROR(hr = E_FAIL)
        }

        // Get the connector in the next device topology,
        // which lies on the other side of the connection.
        hr = pConnFrom->GetConnectedTo(&pConnTo);
        EXIT_ON_ERROR(hr)
        SAFE_RELEASE(pConnFrom)

        // Get the connector's IPart interface.
        hr = pConnTo->QueryInterface(
                        IID_IPart, (void**)&pPartPrev);
        EXIT_ON_ERROR(hr)
        SAFE_RELEASE(pConnTo)

        // Inner loop: Each iteration traverses one link in a
        // device topology and looks for input multiplexers.
        while (TRUE)
        {
            PartType parttype;
            UINT localId;
            IPartsList *pParts;

            // Follow downstream link to next part.
            hr = pPartPrev->EnumPartsOutgoing(&pParts);
            EXIT_ON_ERROR(hr)

            hr = pParts->GetPart(0, &pPartNext);
            pParts->Release();
            EXIT_ON_ERROR(hr)

            hr = pPartNext->GetPartType(&parttype);
            EXIT_ON_ERROR(hr)

            if (parttype == Connector)
            {
                // We've reached the output connector that
                // lies at the end of this device topology.
                hr = pPartNext->QueryInterface(
                                  IID_IConnector,
                                  (void**)&pConnFrom);
                EXIT_ON_ERROR(hr)

                SAFE_RELEASE(pPartPrev)
                SAFE_RELEASE(pPartNext)
                break;
            }

            // Failure of the following call means only that
            // the part is not a MUX (input selector).
            hr = pPartNext->Activate(
                              CLSCTX_ALL,
                              IID_IAudioInputSelector,
                              (void**)&pSelector);
            if (hr == S_OK)
            {
                // We found a MUX (input selector), so select
                // the input from our endpoint device.
                hr = pPartPrev->GetLocalId(&localId);
                EXIT_ON_ERROR(hr)

                hr = pSelector->SetSelection(localId, NULL);
                EXIT_ON_ERROR(hr)

                SAFE_RELEASE(pSelector)
            }

            SAFE_RELEASE(pPartPrev)
            pPartPrev = pPartNext;
            pPartNext = NULL;
        }
    }

Exit:
    SAFE_RELEASE(pConnFrom)
    SAFE_RELEASE(pConnTo)
    SAFE_RELEASE(pPartPrev)
    SAFE_RELEASE(pPartNext)
    SAFE_RELEASE(pSelector)
    return hr;
}

Die DeviceTopology-API implementiert eine IAudioInputSelector- Schnittstelle, um einen Multiplexer zu kapseln, z. B. die im vorherigen Diagramm. (Ein IAudioOutputSelector Schnittstelle kapselt einen Demultiplexer.) Im vorherigen Codebeispiel fragt die innere Schleife der SelectCaptureDevice-Funktion jede Untereinheit ab, die ermittelt wird, ob es sich bei der Untereinheit um ein Multiplexer handelt. Wenn die Untereinheit ein Multiplexer ist, ruft die Funktion die IAudioInputSelector::SetSelection Methode auf, um die Eingabe auszuwählen, die eine Verbindung mit dem Datenstrom vom Endpunktgerät herstellt.

Im vorherigen Codebeispiel durchläuft jede Iteration der äußeren Schleife eine Gerätetopologie. Beim Durchlaufen der Gerätetopologien im vorherigen Diagramm durchläuft die erste Iteration das Eingabe-Multiplexer-Gerät und die zweite Iteration durchläuft das Wellenaufnahmegerät. Die Funktion wird beendet, wenn sie den Verbinder am rechten Rand des Diagramms erreicht. Beendigung tritt auf, wenn die Funktion einen Verbinder mit einem Software_IO Verbindungstyp erkennt. Dieser Verbindungstyp identifiziert den Punkt, an dem das Adaptergerät eine Verbindung mit dem Systembus herstellt.

Der Aufruf der IPart::GetPartType -Methode im vorherigen Codebeispiel ruft einen IPartType Enumerationswert ab, der angibt, ob es sich bei dem aktuellen Teil um einen Connector oder eine Audioverarbeitungsuntereinheit handelt.

Die innere Schleife im vorherigen Codebeispiel führt die Verknüpfung zwischen einem Teil und der nächsten durch Aufrufen der IPart::EnumPartsOutgoing-Methode durch. (Es gibt auch eine IPart::EnumPartsIncoming Methode für das Schrittweise in die entgegengesetzte Richtung.) Diese Methode ruft ein IPartsList Objekt ab, das eine Liste aller ausgehenden Teile enthält. Jeder Teil, den die SelectCaptureDevice-Funktion erwartet, hat jedoch immer genau einen ausgehenden Teil. Daher fordert der nachfolgende Aufruf von IPartsList::GetPart immer den ersten Teil in der Liste an, Teilnummer 0, da die Funktion davon ausgeht, dass dies der einzige Teil in der Liste ist.

Wenn die SelectCaptureDevice-Funktion auf eine Topologie trifft, für die diese Annahme ungültig ist, kann die Funktion das Gerät möglicherweise nicht ordnungsgemäß konfigurieren. Um einen solchen Fehler zu vermeiden, kann eine allgemeinere Version der Funktion folgendes tun:

• Rufen Sie die IPartsList::GetCount-Methode auf, um die Anzahl der ausgehenden Teile zu bestimmen.
• Rufen Sie für jeden ausgehenden Teil IPartsList::GetPart auf, um mit dem Durchlaufen des Datenpfads zu beginnen, der vom Teil aus führt.

Einige, aber nicht unbedingt alle Teile verfügen über zugeordnete Hardwaresteuerelemente, die Clients festlegen oder abrufen können. Ein bestimmter Teil kann null, ein oder mehrere Hardwaresteuerelemente aufweisen. Ein Hardwaresteuerelement wird durch das folgende Schnittstellenpaar dargestellt:

• Eine generische Steuerelementschnittstelle, IControlInterface, die Methoden aufweist, die für alle Hardwaresteuerelemente gemeinsam sind.
• Eine funktionsspezifische Schnittstelle (z. B. IAudioVolumeLevel), die die Steuerelementparameter für einen bestimmten Typ von Hardwaresteuerelement (z. B. ein Lautstärkesteuerelement) verfügbar macht.

Zum Aufzählen der Hardwaresteuerelemente für einen Teil ruft der Client zuerst die IPart::GetControlInterfaceCount Methode auf, um die Anzahl der Hardwaresteuerelemente zu bestimmen, die dem Teil zugeordnet sind. Als Nächstes führt der Client eine Reihe von Aufrufen der IPart::GetControlInterface Methode aus, um die IControlInterface Schnittstelle für jedes Hardwaresteuerelement abzurufen. Schließlich ruft der Client die funktionsspezifische Schnittstelle für jedes Hardwaresteuerelement ab, indem er die IControlInterface::GetIID Methode aufruft, um die Schnittstellen-ID abzurufen. Der Client ruft die IPart::Activate-Methode mit dieser ID auf, um die funktionsspezifische Schnittstelle abzurufen.

Ein Teil, der ein Verbinder ist, unterstützt möglicherweise eine der folgenden funktionsspezifischen Steuerschnittstellen:

• IKsFormatSupport-
• IKsJackDescription

Ein Teil, der eine Untereinheit ist, unterstützt möglicherweise eine oder mehrere der folgenden funktionsspezifischen Steuerschnittstellen:

• IAudioAutoGainControl
• IAudioBass-
• IAudioChannelConfig
• IAudioInputSelector-
• IAudioLoudness
• IAudioMidrange
• IAudioMute-
• IAudioOutputSelector-
• IAudioPeakMeter
• IAudioTreble-
• IAudioVolumeLevel-
• IDeviceSpecificProperty

Ein Teil unterstützt die IDeviceSpecificProperty Schnittstelle nur, wenn das zugrunde liegende Hardwaresteuerelement einen gerätespezifischen Steuerelementwert aufweist und das Steuerelement nicht durch eine andere funktionsspezifische Schnittstelle in der vorherigen Liste angemessen dargestellt werden kann. In der Regel ist eine gerätespezifische Eigenschaft nur für einen Client nützlich, der die Bedeutung des Eigenschaftswerts von Informationen wie dem Teiltyp, dem Teiluntertyp und dem Teilnamen ableiten kann. Der Client kann diese Informationen abrufen, indem er die methoden IPart::GetPartType, IPart::GetSubTypeund IPart::GetName Methoden aufruft.

Verwandte Themen

Programmierhandbuch