Topologie urządzeń

Interfejs API DeviceTopology zapewnia klientom kontrolę nad różnymi funkcjami wewnętrznymi kart audio, do których nie mogą uzyskać dostępu za pośrednictwem interfejsu API MMDeviceWASAPIlub interfejsu API EndpointVolume API.

Jak wyjaśniono wcześniej, interfejs API MMDeviceWASAPIoraz EndpointVolume API prezentować mikrofony, głośniki, słuchawki i inne urządzenia wejściowe i wyjściowe audio klientom jako urządzenia punktu końcowego audio . Model urządzenia punktu końcowego zapewnia klientom wygodny dostęp do kontrolek głośności i wyciszenia na urządzeniach audio. Klienci, którzy wymagają tylko tych prostych kontrolek, mogą uniknąć przechodzenia przez wewnętrzne topologie urządzeń sprzętowych w adapterach audio.

W systemie Windows Vista aparat audio automatycznie konfiguruje topologie urządzeń audio do użytku przez aplikacje audio. W związku z tym aplikacje rzadko, jeśli kiedykolwiek, muszą korzystać z interfejsu API DeviceTopology w tym celu. Załóżmy na przykład, że karta audio zawiera multiplekser wejściowy, który może przechwytywać strumień z wejścia liniowego lub mikrofonu, ale nie może przechwytywać strumieni z obu urządzeń punktu końcowego w tym samym czasie. Załóżmy, że użytkownik włączył aplikacje w trybie wyłączności, aby wyprzedażyć korzystanie z urządzenia punktu końcowego audio przez aplikacje w trybie udostępnionym, zgodnie z opisem w Exclusive-Mode Streams. Jeśli aplikacja w trybie współużytkowania rejestruje strumień z danych wejściowych linii w momencie rozpoczęcia rejestrowania strumienia z mikrofonu przez aplikację w trybie wyłącznym, aparat audio automatycznie przełącza multiplekser z linii wejściowej do mikrofonu. Natomiast we wcześniejszych wersjach systemu Windows, w tym Windows XP, aplikacja trybu wyłącznego w tym przykładzie używałaby funkcji mikseraXxx w interfejsie API multimediów systemu Windows w celu przechodzenia przez topologie urządzeń adaptera, odnajdywania multipleksera i konfigurowania multipleksera w celu wybrania wejścia mikrofonu. W systemie Windows Vista te kroki nie są już wymagane.

Jednak niektórzy klienci mogą wymagać jawnej kontroli nad typami kontrolek sprzętu audio, do których nie można uzyskać dostępu za pośrednictwem interfejsu API MMDevice, WASAPI lub interfejsu API EndpointVolume. W przypadku tych klientów interfejs API DeviceTopology umożliwia przechodzenie przez topologie urządzeń adaptera w celu odnajdywania kontrolek audio na urządzeniach i zarządzania nimi. Aplikacje korzystające z interfejsu API DeviceTopology muszą być zaprojektowane z ostrożnością, aby uniknąć zakłócania zasad dźwięku systemu Windows i zakłócania wewnętrznych konfiguracji urządzeń audio udostępnianych innym aplikacjom. Aby uzyskać więcej informacji na temat zasad audio systemu Windows, zobacz User-Mode Audio Components.

Interfejs API DeviceTopology udostępnia interfejsy do odnajdywania następujących typów kontrolek audio i zarządzania nimi w topologii urządzenia:

• Automatyczna kontrola nad przyrostem
• Sterowanie basem
• Selektor danych wejściowych (multiplekser)
• Kontrolka głośności
• Kontrolka rozmieszczenia środkowego
• Wycisz kontrolkę
• Selektor danych wyjściowych (demultiplexer)
• Miernik szczytowy
• Kontrolka potrójne
• Sterowanie głośnością

Ponadto interfejs API DeviceTopology umożliwia klientom wykonywanie zapytań dotyczących urządzeń adapterów w celu uzyskania informacji o formatach strumieni, które obsługują. Plik nagłówkowy Devicetopology.h definiuje interfejsy w interfejsie API DeviceTopology.

Na poniższym diagramie przedstawiono przykład kilku topologii podłączonych urządzeń dla części karty PCI, która przechwytuje dźwięk z mikrofonu, wejścia liniowego i odtwarzacza CD.

Na powyższym diagramie przedstawiono ścieżki danych prowadzące z analogowych danych wejściowych do magistrali systemowej. Każde z następujących urządzeń jest reprezentowane jako obiekt topologii urządzenia z interfejsem IDeviceTopology:

• Urządzenie przechwytywania fal
• Wejściowe urządzenie multiplekserowe
• Urządzenie punktu końcowego A
• Urządzenie punktu końcowego B

Należy pamiętać, że diagram topologii łączy urządzenia adapterów (przechwytywanie fal i urządzenia multiplekserowe) z urządzeniami punktu końcowego. Za pośrednictwem połączeń między urządzeniami dane audio są przekazywane z jednego urządzenia do następnego. Po każdej stronie połączenia znajduje się łącznik (oznaczony etykietą Con na diagramie), za pomocą którego dane przechodzą lub opuszczają urządzenie.

Na lewej krawędzi diagramu sygnały z wejścia liniowego i gniazda mikrofonu wchodzą do urządzeń punktu końcowego.

Wewnątrz urządzenia przechwytywania fal i wejściowego urządzenia multipleksera są funkcje przetwarzania strumieniowego, które w terminologii interfejsu API DeviceTopology są nazywane podjęciami. Na powyższym diagramie są wyświetlane następujące typy podnitów:

• Kontrolka głośności (oznaczona etykietą Vol)
• Wycisz kontrolkę (oznaczona etykietą Wycisz)
• Multiplekser (lub selektor danych wejściowych; z etykietą MUX)
• Konwerter analogowo-cyfrowy (oznaczony jako ADC)

Ustawienia w podnitach woluminu, wyciszenia i multipleksera mogą być kontrolowane przez klientów, a interfejs API DeviceTopology udostępnia interfejsy sterowania klientom w celu ich kontrolowania. W tym przykładzie podwitię usługi ADC nie ma ustawień kontroli. W związku z tym interfejs API DeviceTopology nie zapewnia interfejsu sterowania dla usługi ADC.

W terminologii interfejsu APITopologii urządzeń łączniki i podnity należą do tej samej ogólnej kategorii — części. Wszystkie części, niezależnie od tego, czy są łącznikami, czy podnitami, zapewniają wspólny zestaw funkcji. Interfejs API DeviceTopology implementuje interfejs IPart reprezentujący funkcje ogólne wspólne dla łączników i podjedni. Interfejs API implementuje interfejsy IConnector i interfejsy ISubunit reprezentujące konkretne aspekty łączników i podjęciów.

Interfejs API DeviceTopology tworzy topologie urządzenia przechwytywania fal i wejściowego urządzenia multipleksera z filtrów przesyłania strumieniowego jądra (KS), które sterownik audio uwidacznia systemowi operacyjnemu w celu reprezentowania tych urządzeń. (Sterownik adaptera audio implementuje IMiniportWaveXxx i interfejsy IMiniportTopology reprezentujące części tych filtrów zależne od sprzętu; aby uzyskać więcej informacji na temat tych interfejsów i filtrów KS, zobacz dokumentację zestawu DDK systemu Windows).

Interfejs APITopologii urządzeń konstruuje proste topologie reprezentujące urządzenia punktu końcowego A i B na powyższym diagramie. Topologia urządzenia punktu końcowego składa się z jednego łącznika. Ta topologia jest tylko symbolem zastępczym urządzenia punktu końcowego i nie zawiera żadnych podjęci do przetwarzania danych audio. W rzeczywistości urządzenia adapterów zawierają wszystkie jednostki podrzędne używane przez aplikacje klienckie do sterowania przetwarzaniem dźwięku. Topologia urządzenia punktu końcowego służy przede wszystkim jako punkt wyjścia do eksplorowania topologii urządzeń adaptera.

Połączenia wewnętrzne między dwiema częściami topologii urządzenia są nazywane łączami. Interfejs API DeviceTopology udostępnia metody przechodzenia linków z jednej części do następnej w topologii urządzenia. Interfejs API udostępnia również metody przechodzenia połączeń między topologiami urządzeń.

Aby rozpocząć eksplorację zestawu topologii połączonych urządzeń, aplikacja kliencka aktywuje interfejs IDeviceTopology interfejsu urządzenia punktu końcowego audio. Łącznik w urządzeniu punktu końcowego łączy się z łącznikiem w karcie audio lub z siecią. Jeśli punkt końcowy łączy się z urządzeniem na karcie audio, metody w interfejsie API DeviceTopology umożliwiają aplikacji przechodzenie przez połączenie z punktu końcowego do karty przez uzyskanie odwołania do interfejsu IDeviceTopology interfejsu karty po drugiej stronie połączenia. Z drugiej strony sieć nie ma topologii urządzeń. Połączenie sieciowe potokuje strumień audio do klienta, który uzyskuje zdalny dostęp do systemu.

Interfejs API DeviceTopology zapewnia dostęp tylko do topologii urządzeń sprzętowych w adapterze audio. Urządzenia zewnętrzne na lewej krawędzi diagramu i składniki oprogramowania na prawej krawędzi wykraczają poza zakres interfejsu API. Linie przerywane po obu stronach diagramu reprezentują limity interfejsu API DeviceTopology. Klient może użyć interfejsu API do eksplorowania ścieżki danych, która rozciąga się od gniazda wejściowego do magistrali systemowej, ale interfejs API nie może przedostać się poza te granice.

Każdy łącznik na powyższym diagramie ma skojarzony typ połączenia, który wskazuje typ połączenia, które nawiązuje łącznik. W związku z tym łączniki po obu stronach połączenia zawsze mają identyczne typy połączeń. Typ połączenia jest wskazywany przez wartość wyliczenia ConnectorType — Physical_External, Physical_Internal, Software_Fixed, Software_IO lub Sieć. Połączenia między wejściowym urządzeniem multiplekserowym a urządzeniami końcowymi A i B są typu Physical_External, co oznacza, że połączenie reprezentuje fizyczne połączenie z urządzeniem zewnętrznym (innymi słowy, gniazdo audio dostępne dla użytkownika). Połączenie z sygnałem analogowym z wewnętrznego odtwarzacza CD jest typu Physical_Internal, co wskazuje fizyczne połączenie z urządzeniem pomocniczym zainstalowanym wewnątrz obudowy systemu. Połączenie między urządzeniem przechwytywania fal i urządzeniem multiplekserowym jest typu Software_Fixed, co wskazuje stałe połączenie, które jest stałe i nie można go skonfigurować pod kontrolą oprogramowania. Na koniec połączenie z magistralą systemową po prawej stronie diagramu jest typu Software_IO, co wskazuje, że dane we/wy dla połączenia są implementowane przez aparat DMA pod kontrolą oprogramowania. (Diagram nie zawiera przykładu typu połączenia sieciowego).

Klient rozpoczyna przechodzenie ścieżki danych na urządzeniu punktu końcowego. Najpierw klient uzyskuje interfejs IMMDevice reprezentujący urządzenie punktu końcowego, zgodnie z opisem w Wyliczanie urządzeń audio. Aby uzyskać interfejs IDeviceTopology dla urządzenia punktu końcowego, klient wywołuje metodę IMMDevice::Activate z parametrem identyfikator em iid ustawionym na identyfikator REFIID IID_IDeviceTopology.

W przykładzie na powyższym diagramie urządzenie wejściowe multiplekser zawiera wszystkie kontrolki sprzętowe (głośność, wyciszenie i multiplekser) dla strumieni przechwytywania z gniazd wejściowych i mikrofonowych. Poniższy przykład kodu pokazuje, jak uzyskać interfejs IDeviceTopology dla wejściowego urządzenia multipleksera z interfejsu IMMDevice dla urządzenia punktu końcowego dla wejścia wiersza lub mikrofonu:

//-----------------------------------------------------------
// 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;
}

Funkcja GetHardwareDeviceTopology w poprzednim przykładzie kodu wykonuje następujące kroki, aby uzyskać interfejs IDeviceTopology dla urządzenia wejściowego multipleksera:

1. Wywołaj metodę IMMDevice::Activate, aby uzyskać interfejs IDeviceTopology dla urządzenia punktu końcowego.
2. Za pomocą interfejsu IDeviceTopology uzyskanego w poprzednim kroku wywołaj metodę IDeviceTopology::GetConnector, aby pobrać interfejs IConnector pojedynczego łącznika (numer łącznika 0) na urządzeniu punktu końcowego.
3. Za pomocą interfejsu IConnector uzyskanego w poprzednim kroku wywołaj metodę IConnector::GetConnectedTo, aby pobrać interfejs IConnector łącznika w wejściowym urządzeniu multiplekserowym.
4. Wykonaj zapytanie dotyczące interfejsu IConnector uzyskanego w poprzednim kroku dla interfejsu IPart.
5. Za pomocą interfejsu IPart uzyskanego w poprzednim kroku wywołaj metodę IPart::GetTopologyObject, aby uzyskać interfejs IDeviceTopology dla urządzenia wejściowego multipleksera.

Zanim użytkownik będzie mógł nagrywać z mikrofonu na powyższym diagramie, aplikacja kliencka musi upewnić się, że multiplekser wybiera wejście mikrofonu. Poniższy przykład kodu pokazuje, jak klient może przejść ścieżkę danych z mikrofonu do momentu znalezienia multipleksera, który następnie programuje, aby wybrać wejście mikrofonu:

//-----------------------------------------------------------
// 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;
}

Interfejs API DeviceTopology implementuje interfejs IAudioInputSelector , aby hermetyzować multiplekser, taki jak ten na powyższym diagramie. (Interfejs IAudioOutputSelector hermetyzuje demultiplexer). W poprzednim przykładzie kodu wewnętrzna pętla funkcji SelectCaptureDevice wysyła zapytanie do każdego podnitu, który znajduje, aby dowiedzieć się, czy podnit jest multiplekserem. Jeśli podnit jest multiplekserem, funkcja wywołuje IAudioInputSelector::SetSelection metodę, aby wybrać dane wejściowe łączące się ze strumieniem z urządzenia punktu końcowego.

W poprzednim przykładzie kodu każda iteracja pętli zewnętrznej przechodzi jedną topologię urządzenia. Podczas przechodzenia przez topologie urządzeń na powyższym diagramie pierwsza iteracja przechodzi przez urządzenie wejściowe multipleksera, a druga iteracja przechodzi przez urządzenie przechwytywania fali. Funkcja zakończy się po dotarciu do łącznika po prawej krawędzi diagramu. Zakończenie występuje, gdy funkcja wykrywa łącznik z typem połączenia Software_IO. Ten typ połączenia identyfikuje punkt, w którym urządzenie karty łączy się z magistralą systemową.

Wywołanie metody IPart::GetPartType w poprzednim przykładzie kodu uzyskuje IPartType wartość wyliczenia wskazującą, czy bieżąca część jest łącznikiem, czy podnitem przetwarzania audio.

Pętla wewnętrzna w poprzednim przykładzie kodu kroków między linkiem z jednej części do następnej przez wywołanie metody IPart::EnumPartsOutgoing. (Istnieje również IPart::EnumPartsIncoming metoda przechodzenia w przeciwnym kierunku). Ta metoda pobiera obiektIPartsList zawierający listę wszystkich części wychodzących. Jednak każda część oczekiwana przez funkcję SelectCaptureDevice na urządzeniu przechwytywania zawsze będzie miała dokładnie jedną część wychodzącą. W związku z tym kolejne wywołanie metody IPartsList::GetPart zawsze żąda pierwszej części listy, numer części 0, ponieważ funkcja zakłada, że jest to jedyna część listy.

Jeśli funkcja SelectCaptureDevice napotka topologię, dla której to założenie jest nieprawidłowe, funkcja może nie poprawnie skonfigurować urządzenia. Aby uniknąć takiego błędu, bardziej ogólnego przeznaczenia wersja funkcji może wykonywać następujące czynności:

• Wywołaj metodę IPartsList::GetCount, aby określić liczbę części wychodzących.
• Dla każdej części wychodzącej wywołaj metodę IPartsList::GetPart, aby rozpocząć przechodzenie ścieżki danych prowadzącej z tej części.

Niektóre, ale niekoniecznie wszystkie, części mają skojarzone mechanizmy kontroli sprzętu, które klienci mogą ustawić lub uzyskać. Określona część może mieć zero, co najmniej jedną kontrolkę sprzętową. Sterowanie sprzętem jest reprezentowane przez następującą parę interfejsów:

• Ogólny interfejs sterowania IControlInterface, który ma metody wspólne dla wszystkich kontrolek sprzętowych.
• Interfejs specyficzny dla funkcji (na przykład IAudioVolumeLevel), który uwidacznia parametry sterowania dla określonego typu kontroli sprzętu (na przykład sterowanie głośnością).

Aby wyliczyć kontrolki sprzętowe dla części, klient najpierw wywołuje IPart::GetControlInterfaceCount metodę w celu określenia liczby kontrolek sprzętowych skojarzonych z częścią. Następnie klient wykonuje serię wywołań do metody IPart::GetControlInterface w celu uzyskania interfejsu IControlInterface dla każdej kontroli sprzętu. Na koniec klient uzyskuje interfejs specyficzny dla funkcji dla każdej kontrolki sprzętu przez wywołanie metody IControlInterface::GetIID metody w celu uzyskania identyfikatora interfejsu. Klient wywołuje metodę IPart::Activate za pomocą tego identyfikatora, aby uzyskać interfejs specyficzny dla funkcji.

Część łącznika może obsługiwać jeden z następujących interfejsów sterowania specyficznych dla funkcji:

• IKsFormatSupport
• IKsJackDescription

Część, która jest podnitem, może obsługiwać co najmniej jeden z następujących interfejsów sterowania specyficznych dla funkcji:

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

Część obsługuje interfejs IDeviceSpecificProperty tylko wtedy, gdy podstawowa kontrolka sprzętowa ma wartość sterowania specyficzną dla urządzenia, a kontrolka nie może być odpowiednio reprezentowana przez inny interfejs specyficzny dla funkcji na powyższej liście. Zazwyczaj właściwość specyficzna dla urządzenia jest przydatna tylko dla klienta, który może wywnioskować znaczenie wartości właściwości z informacji, takich jak typ części, podtyp części i nazwa części. Klient może uzyskać te informacje, wywołując metody IPart::GetPartType, IPart::GetSubTypei metody IPart::GetName.

Tematy pokrewne

Przewodnik programowania