Eventos de hardware

Alguns dispositivos de áudio fornecem botões de controle de volume de hardware, comutadores mudo ou outros tipos de controles manuais. Os aplicativos podem responder a alterações nesses controles ajustando o volume ou alterando a maneira como o fluxo de áudio é reproduzido. Quando o usuário ajusta um controle de hardware, o driver de miniporta usa a interface IPortEvents para informar ao driver de porta que ocorreu um evento de hardware. O driver de porta, por sua vez, notifica o aplicativo do evento para que ele possa ler a nova configuração de controle do dispositivo.

O driver de miniporta pode consultar o driver de porta para a interface IPortEvents no momento em que ele atende à chamada init (consulte IMiniportWavePci::Init, por exemplo) do driver de porta. No Microsoft Windows 98 SE, Windows Me e Windows 2000 e posteriores, essa consulta é bem-sucedida. Para obter um exemplo de código, consulte o adaptador de áudio de exemplo Sb16 em versões anteriores do WDK (Windows Driver Kit).

Quando o driver de porta chama o método IMiniport::GetDescription do driver, o método gera uma estrutura PCFILTER_DESCRIPTOR que especifica, entre outras coisas, os eventos aos quais o dispositivo dá suporte. Os eventos podem ser especificados nas tabelas de automação para os membros Pins e Nodes do PCFILTER_DESCRIPTOR e no membro AutomationTable , que aponta para a tabela de automação do próprio filtro. Cada evento é especificado por uma estrutura PCEVENT_ITEM . O driver deve definir os membros Set e Id da estrutura PCEVENT_ITEM como KSEVENTSETID_AudioControlChange e KSEVENT_CONTROL_CHANGE e deve carregar um ponteiro para a rotina EventHandler do driver no membro Handler . O driver também deve definir o bit PCEVENT_ITEM_FLAG_BASICSUPPORT no membro Flags para indicar o suporte básico para eventos de alteração de controle e deve definir o PCEVENT_ITEM_FLAG_ONESHOT e/ou PCEVENT_ITEM_FLAG_ENABLE bits para indicar que ele dá suporte a uma notificação única e/ou recorrente.

Quando um aplicativo mais tarde chama a função mixerOpen (descrita na documentação do SDK do Microsoft Windows) para solicitar a notificação de um evento específico, o driver de porta chama a rotina EventHandler do driver com um ponteiro para uma estrutura PCEVENT_REQUEST. O membro verbo dessa estrutura é definido como PCEVENT_VERB_ADD e seu membro EventItem especifica o evento a ser habilitado. A estrutura PCEVENT_REQUEST também contém um ponteiro para uma estrutura KSEVENT_ENTRY que o driver deve tratar como dados opacos do sistema. Depois de habilitar o evento, o manipulador deve chamar IPortEvents::AddEventToEventList com o mesmo ponteiro KSEVENT_ENTRY. Com essa chamada, o manipulador reconhece que o evento está habilitado.

Quando o evento de hardware ocorre e a rotina de serviço de interrupção do driver detecta um mudo ou uma alteração de volume, o driver sinaliza o evento para o driver de porta chamando IPortEvents::GenerateEventList com um conjunto de parâmetros que descrevem o evento. Por exemplo, a chamada a seguir descreve uma alteração de controle em um nó de volume de lineout:

    pPE->GenerateEventList(NULL, KSEVENT_CONTROL_CHANGE,
                           FALSE, ULONG(-1), TRUE, LINEOUT_VOL);

Durante essa chamada, o driver de porta pesquisa sua lista de eventos para todos os eventos que correspondem aos parâmetros de chamada e envia notificação para os clientes que estão monitorando esses eventos. Neste exemplo, pPE é um ponteiro para o objeto IPortEvents e LINEOUT_VOL é a ID do nó que o driver de miniporto atribui ao nó lineout-volume. Parâmetros não especificados (como o GUID do conjunto de eventos e a ID do pino no exemplo anterior) são tratados como curingas e sempre correspondem aos parâmetros correspondentes na lista.