Share via


Sessões de Áudio

Uma sessão de áudio é um grupo de fluxos de áudio relacionados que um cliente WASAPI pode gerenciar coletivamente. Os clientes podem controlar o nível de volume e o estado de silenciamento de cada sessão individual. O sistema aplica as configurações de volume e mudo especificadas pelo cliente uniformemente a todos os fluxos na sessão.

Quando um cliente inicializa um fluxo de áudio, ele atribui o fluxo de áudio a uma sessão de áudio. Para obter mais informações, consulte IAudioClient::Initialize.

Uma sessão de áudio contém fluxos de renderização ou fluxos de captura, mas não ambos. Por padrão, as configurações de volume e mudo para uma sessão de renderização são persistentes nas reinicializações do sistema. As configurações de volume e mudo para uma sessão de captura não são persistentes. (Uma sessão que contém fluxos que operam no modo de loopback é tratada da mesma forma que uma sessão de captura. Ou seja, as configurações da sessão não são persistentes. Para obter mais informações sobre o modo de loopback, consulte Gravação de loopback.)

Cada fluxo de áudio pertence exatamente a uma sessão. Um cliente atribui um fluxo de áudio a uma sessão específica no momento em que inicializa o objeto de fluxo. O fluxo mantém sua associação na sessão durante o tempo de vida do fluxo. Depois que um objeto de fluxo é criado, o objeto existe até que um cliente libere a última referência contada para o objeto e, em seguida, o objeto é excluído.

Embora um cliente não possa alterar a sessão à qual um fluxo existente é atribuído, ele pode obter um efeito semelhante excluindo o fluxo (liberando todas as referências a ele), criando um novo fluxo para substituir o fluxo excluído e atribuindo o novo fluxo a outra sessão.

Cada sessão de renderização representa um subconjunto dos fluxos que formam a mistura global que é reproduzida por meio de um dispositivo de ponto de extremidade de áudio específico. A combinação global combina todas as sessões de todos os aplicativos que compartilham o dispositivo.

Frequentemente, um aplicativo com vários fluxos atribui todos os seus fluxos à mesma sessão. No entanto, o aplicativo pode, como opção, atribuir fluxos diferentes a sessões diferentes. Qualquer fluxo que o aplicativo não atribua explicitamente a uma sessão pertence à sessão padrão.

Aplicativos de áudio típicos devem evitar modificar as configurações de volume e mudo das sessões. Em vez disso, os usuários controlam essas configurações por meio das interfaces de usuário dos programas de controle. Por exemplo, no Windows Vista, o programa fornecido pelo sistema, Sndvol.exe, exibe um controle de volume e um controle de mudo para cada sessão de renderização ativa ou recentemente ativa no sistema. Através desses controles, os usuários podem ajustar as configurações de volume e mudo para todas as sessões no sistema.

O programa Sndvol atualmente exibe controles de volume apenas para dispositivos de ponto de extremidade de renderização de áudio. Ele não exibe controles de volume para dispositivos de captura de áudio.

Uma sessão estará ativa se contiver um ou mais fluxos ativos. Um fluxo ativo está no estado de execução. Um fluxo inativo está no estado parado. Uma sessão torna-se ativa quando seu primeiro fluxo se torna ativo. Uma sessão torna-se inativa quando seu último fluxo ativo se torna inativo. Depois que uma sessão fica inativa por um período de tempo, o sistema altera o estado da sessão de inativa para expirada.

O Sndvol exibe controles de volume e mudo para todas as sessões de renderização ativas e inativas. O Sndvol remove os controles de volume e mudo de uma sessão quando o estado da sessão muda de inativo para expirado ou quando a sessão é encerrada. (Uma sessão termina quando o último de seus fluxos é excluído; ou seja, quando um cliente libera a contagem de referência final no último objeto de fluxo restante na sessão.) A única exceção a essa regra é para sons de notificação do sistema. O Sndvol sempre exibe os controles de volume e mudo para sons de notificação do sistema, independentemente do estado da sessão para esses sons.

Normalmente, um fluxo pertence a uma sessão que abrange apenas o processo que contém o aplicativo que criou o fluxo. No entanto, os aplicativos têm a opção de definir sessões entre processos que combinam fluxos de dois ou mais processos.

O WASAPI oferece suporte a sessões entre processos principalmente para que:

  • O programa Sndvol pode apresentar ao usuário um único controle de volume para gerenciar sons de notificação do sistema em todos os aplicativos.
  • Um media player executado em um processo pode transmitir conteúdo protegido para um programa de descriptografia executado em outro processo.

Semelhante às configurações de controle para sessões de renderização específicas do processo, as configurações de controle para sessões de renderização entre processos são, por padrão, persistentes nas reinicializações do sistema. O WASAPI fornece esse comportamento principalmente para o benefício dos sons de notificação do sistema, que devem manter as configurações de volume e mudo do usuário, pois a combinação de aplicativos varia ao longo do tempo.

O programa Sndvol rotula o controle de volume para cada sessão com um nome de exibição e um ícone. Um cliente tem a opção de atribuir explicitamente um nome de exibição e um ícone a uma sessão. Se o cliente não fornecer esses itens, o Sndvol exibirá um nome padrão e um ícone padrão. O nome padrão incorpora informações como o título da janela do aplicativo. O ícone padrão é o ícone da janela do aplicativo. Somente no caso de sessões específicas do processo, esses padrões fornecem informações significativas aos usuários. Observe que uma sessão entre processos pode ser associada a mais de um aplicativo. Nesse caso, apenas um nome de exibição e um ícone fornecidos pelo cliente são significativos.

Embora as configurações de volume e mudo para uma sessão de renderização sejam, por padrão, persistentes nas reinicializações do sistema, o nome de exibição e o ícone fornecidos pelo cliente não são. Para garantir que o Sndvol exiba o nome e o ícone fornecidos pelo cliente, o cliente deve atribuir explicitamente o nome e o ícone à sessão no momento em que o cliente atribui o primeiro fluxo à sessão. O sistema retém o nome de exibição e o ícone de uma sessão somente até que a sessão seja encerrada.

Cada sessão é identificada por um GUID de sessão. No momento em que um cliente abre um fluxo, o cliente atribui esse fluxo a uma sessão específica. O cliente fornece as duas informações a seguir para identificar essa sessão:

  • Um GUID de sessão.
  • Se a sessão é um processo cruzado ou uma sessão específica do processo — uma sessão específica do processo contém apenas fluxos do processo do cliente.

Essas informações são suficientes para distinguir uma sessão específica de todas as outras sessões no mesmo computador. O GUID de sessão para uma sessão específica do processo identifica exclusivamente a sessão somente dentro do escopo do processo que possui a sessão. Por outro lado, o GUID de sessão para uma sessão entre processos é exclusivo dentro do escopo de todos os processos em execução no computador.

No caso de uma sessão específica do processo, o sistema usa uma combinação de GUID de sessão e ID de processo para identificar exclusivamente a sessão dentro do escopo do computador. Assim, se os clientes em dois processos diferentes atribuem seus respectivos fluxos a duas sessões específicas do processo com GUIDs de sessão idênticos, o sistema tratará as sessões como separadas porque suas IDs de processo são diferentes. Além disso, se uma sessão entre processos usar o mesmo GUID de sessão como uma ou mais sessões específicas do processo, o sistema tratará a sessão entre processos como distinta das sessões específicas do processo, mesmo que elas compartilhem o mesmo GUID de sessão.

Por exemplo, no Windows Vista, APIs de nível superior, como as funções waveOutXxx multimídia do Windows e DirectSound, geralmente atribuem os fluxos de áudio criados a sessões padrão específicas do processo que são identificadas pelo valor GUID da sessão GUID_NULL. Para clientes dessas APIs, a sessão padrão para cada processo de cliente é separada das sessões padrão para outros processos de cliente, mesmo que as sessões tenham GUIDs de sessão idênticos. Além disso, se um ou mais aplicativos atribuírem fluxos à sessão entre processos identificada pelo valor GUID da sessão GUID_NULL, o sistema tratará essa sessão entre processos como separada das sessões padrão específicas do processo que compartilham o mesmo GUID de sessão. Consequentemente, o programa Sndvol exibe um controle de volume separado para cada sessão padrão do cliente, específica do processo, e exibe um controle de volume adicional para a sessão de processo cruzado que é identificado pelo valor GUID da sessão GUID_NULL, se essa sessão existir.

Cada sessão está associada a apenas um dispositivo de ponto de extremidade de áudio. Se duas sessões tiverem GUIDs de sessão e IDs de processo idênticos, mas estiverem associadas a dispositivos diferentes, o sistema tratará as duas sessões como separadas. Uma sessão nunca pode conter fluxos de captura e renderização porque um fluxo de captura pode ser associado apenas a um dispositivo de captura e um fluxo de renderização pode ser associado apenas a um dispositivo de renderização.

Como mencionado anteriormente, as configurações de volume e mudo de uma sessão são persistentes nas reinicializações do sistema. Duas ou mais instâncias de um aplicativo podem criar sessões específicas do processo com GUIDs de sessão idênticos. Através do programa Sndvol, o usuário pode selecionar diferentes configurações de volume e mudo para cada uma dessas sessões. Depois que essas sessões terminam, o sistema mantém as configurações de controle de apenas uma dessas sessões — a última sessão a ser encerrada. Posteriormente, se uma nova instância do aplicativo criar uma sessão específica do processo com o mesmo GUID de sessão anterior, essa sessão herdará as configurações de volume e mudo salvas anteriormente.

Um aplicativo não deve tentar adicionar um fluxo ou controlar o nível de volume de uma sessão que pertence a outro aplicativo não relacionado. Além disso, um aplicativo não deve tentar controlar o nível de volume da sessão gerenciada pelo sistema para sons de notificação. No entanto, um aplicativo pode reproduzir um som através da sessão do sistema para sons de notificação chamando a função PlaySound . Para obter mais informações, consulte Sons de notificação para aplicativos de áudio herdados.

Um aplicativo pode se registrar para receber notificações quando o estado de uma sessão for alterado. Para obter mais informações, consulte Eventos de sessão de áudio.

Em casos raros, um aplicativo que cria uma sessão específica do processo pode precisar consolidar o controle das sessões específicas do processo para duas ou mais instâncias de aplicativo em um único controle de volume no Sndvol. Para obter mais informações, consulte Parâmetros de agrupamento.

Guia de programação