Pular para o conteúdo principal
Este tópico traz um breve passo a passo do uso da manipulação de áudio em tempo real. O Game Chat 2 oferece a opção de se inserir no pipeline de áudio do chat para inspecionar e manipular os dados de áudio do chat dos usuários. Isso pode ser útil para aplicar efeitos de áudio interessantes às vozes dos usuários no jogo. No Game Chat 2, a interação com o pipeline de manipulação de áudio é feita por meio de objetos de fluxo de áudio que podem ser consultados para obter dados de áudio. Em vez de usar callbacks, você pode usar esse modelo para inspecionar ou manipular o áudio na thread de processamento que for mais conveniente para você.

Inicializando o pipeline de manipulação de áudio

Por padrão, o Game Chat 2 não habilita a manipulação de áudio em tempo real. Para habilitá-la, o aplicativo precisa especificar quais formas de manipulação de áudio deseja habilitar em chat_manager::initialize definindo o parâmetro audioManipulationMode. No momento, as seguintes formas de manipulação de áudio são compatíveis e estão no enum game_chat_audio_manipulation_mode_flags.
  • game_chat_audio_manipulation_mode_flags::none: desabilita a manipulação de áudio. Essa é a configuração padrão. Nesse modo, o áudio do chat flui sem interrupções.
  • game_chat_audio_manipulation_mode_flags::pre_encode_stream_manipulation: habilita a manipulação de áudio antes da codificação. Nesse modo, todo o áudio do chat gerado pelos usuários locais passa pelo pipeline de manipulação de áudio antes de ser codificado. Mesmo que o aplicativo esteja apenas inspecionando os dados de áudio do chat, sem manipulá-los, ainda é responsabilidade do aplicativo enviar os buffers de áudio inalterados de volta ao Game Chat 2 para que possam ser codificados e transmitidos.
  • game_chat_audio_manipulation_mode_flags::post_decode_stream_manipulation: habilita a manipulação de áudio após a decodificação. Nesse modo, todo o áudio do chat recebido de usuários remotos passa pelo pipeline de manipulação de áudio depois de ser decodificado pelo receptor, mas antes de ser renderizado. Mesmo que o aplicativo esteja apenas inspecionando os dados de áudio do chat, sem manipulá-los, ainda é responsabilidade do aplicativo mixar e enviar os buffers de áudio inalterados de volta ao Game Chat 2 para que possam ser renderizados.

Processando alterações de estado dos fluxos de áudio

O Game Chat 2 fornece atualizações do estado dos fluxos de áudio por meio das estruturas game_chat_stream_state_change. Essas atualizações armazenam informações sobre qual fluxo foi atualizado e como ele foi atualizado. Essas atualizações podem ser consultadas por meio de chamadas ao par de métodos chat_manager::start_processing_stream_state_changes() e chat_manager::finish_processing_stream_state_changes(). Eles fornecem todas as atualizações de estado de fluxo de áudio mais recentes enfileiradas como uma matriz de ponteiros de estrutura game_chat_stream_state_change. Os aplicativos devem iterar pela matriz e tratar cada atualização adequadamente. Depois que todas as atualizações game_chat_stream_state_change disponíveis tiverem sido tratadas, essa matriz deverá ser passada de volta ao Game Chat 2 por meio de chat_manager::finish_processing_stream_state_changes(). Isso é mostrado no exemplo a seguir.

Manipulando os dados de áudio do chat antes da codificação

O Game Chat 2 fornece acesso aos dados de áudio do chat antes da codificação para os usuários locais por meio da classe pre_encode_audio_stream.

Tempo de vida do fluxo

Quando uma nova instância de pre_encode_audio_stream está pronta para uso pelo aplicativo, ela é entregue por meio de uma estrutura game_chat_stream_state_change com o campo state_change_type definido como game_chat_stream_state_change_type::pre_encode_audio_stream_created. Depois que essa alteração de estado do fluxo é devolvida ao Game Chat 2, o fluxo de áudio fica disponível para a manipulação de áudio antes da codificação. Quando um pre_encode_audio_stream existente fica indisponível para uso na manipulação de áudio, o aplicativo é notificado por meio de uma estrutura game_chat_stream_state_change com o campo state_change_type definido como game_chat_stream_state_change_type::pre_encode_audio_stream_closed. Essa é a oportunidade de o aplicativo começar a limpar os recursos associados a esse fluxo de áudio. Depois que essa alteração de estado do fluxo é devolvida ao Game Chat 2, o fluxo de áudio fica indisponível para a manipulação de áudio antes da codificação. Quando um pre_encode_audio_stream fechado tem todos os seus recursos devolvidos, o fluxo é destruído e o aplicativo é notificado por meio de uma estrutura game_chat_stream_state_change com o campo state_change_type definido como game_chat_stream_state_change_type::pre_encode_audio_stream_destroyed. Todas as referências ou ponteiros para esse fluxo devem ser limpos. Depois que essa alteração de estado do fluxo é devolvida ao Game Chat 2, a memória do fluxo de áudio se torna inválida.

Usuários do fluxo

A lista de usuários associados a um fluxo pode ser inspecionada usando pre_encode_audio_stream::get_users().

Formatos de áudio

O formato de áudio dos buffers que o aplicativo recupera do Game Chat 2 pode ser inspecionado usando pre_encode_audio_stream::get_pre_processed_format(). O formato de áudio pré-processado é mono. O aplicativo deve estar preparado para tratar dados representados como floats de 32 bits, inteiros de 16 bits e inteiros de 32 bits. O aplicativo precisa informar ao Game Chat 2 o formato de áudio dos buffers manipulados que estão sendo enviados a ele para codificação e transmissão usando pre_encode_audio_stream::set_processed_format(). Os formatos processados dos fluxos de áudio antes da codificação precisam atender às seguintes pré-condições.
  • O formato precisa ser mono.
  • O formato precisa ser PCM float de 32 bits, PCM inteiro de 32 bits ou PCM inteiro de 16 bits.
  • A taxa de amostragem do formato precisa seguir pré-condições baseadas na plataforma. O XBOX One ERA e o XBOX Series X|S oferecem suporte a taxas de amostragem de 8 KHz, 12 KHz, 16 KHz e 24 KHz. A Plataforma Universal do Windows (UWP) para XBOX One e o Windows PC oferecem suporte a taxas de amostragem de 8 KHz, 12 KHz, 16 KHz, 24 KHz, 32 KHz, 44,1 KHz e 48 KHz.

Recuperando e enviando áudio antes da codificação

Os aplicativos podem consultar os fluxos de áudio antes da codificação para saber o número de buffers disponíveis para processar usando pre_encode_audio_stream::get_available_buffer_count(). Essa informação pode ser usada se o aplicativo quiser adiar o processamento de áudio até que um número mínimo de buffers esteja disponível. Apenas 10 buffers serão enfileirados em cada fluxo de áudio antes da codificação, e atrasos de áudio introduzirão latência no pipeline de áudio. Recomendamos que os aplicativos esvaziem seus fluxos de áudio antes da codificação antes que eles enfileirem mais de 4 buffers.

Recuperando buffers de áudio com get_next_buffer()

Os aplicativos podem recuperar buffers de áudio de um fluxo de áudio antes da codificação usando pre_encode_audio_stream::get_next_buffer(). Novos buffers de áudio ficam disponíveis, em média, uma vez a cada 40 ms. Os buffers retornados por esse método precisam ser liberados para pre_encode_audio_stream::return_buffer() quando não forem mais usados. Pode haver no máximo 10 buffers enfileirados ou não devolvidos a qualquer momento para um fluxo de áudio antes da codificação. Depois que esse limite é atingido, os novos buffers capturados da fonte de áudio do usuário são descartados até que alguns dos buffers pendentes sejam devolvidos.

Enviando buffers de áudio com submit_buffer()

Os aplicativos podem enviar seus buffers de áudio inspecionados e manipulados de volta ao Game Chat 2 para codificação e transmissão usando pre_encode_audio_stream::submit_buffer(). O Game Chat 2 oferece suporte à manipulação de áudio no próprio buffer (in-place) e em outro buffer (out-of-place). Os buffers enviados a pre_encode_audio_stream::submit_buffer() não precisam necessariamente ser os mesmos buffers recuperados de pre_encode_audio_stream::get_next_buffer(). A privacidade/os privilégios desses buffers enviados são aplicados com base nos usuários associados a esse fluxo. A cada 40 ms, os próximos 40 ms de áudio desse fluxo são codificados e transmitidos. Para evitar falhas no áudio, os buffers de áudio que devem ser ouvidos continuamente devem ser enviados a esse fluxo a uma taxa constante.

Contextos de fluxo

Os aplicativos podem gerenciar valores de contexto personalizados do tamanho de um ponteiro nos fluxos de áudio antes da codificação usando pre_encode_audio_stream::set_custom_stream_context() e pre_encode_audio_stream::custom_stream_context(). Esses contextos de fluxo personalizados são úteis para criar mapeamentos entre os fluxos de áudio do Game Chat 2 e dados auxiliares. Por exemplo, metadados do fluxo e estado do jogo.

Exemplo

Veja a seguir um exemplo simplificado de ponta a ponta de como usar os fluxos de áudio antes da codificação em um quadro de processamento de áudio.

Manipulando os dados de áudio do chat após a decodificação

O Game Chat 2 fornece acesso aos dados de áudio do chat após a decodificação por meio das classes post_decode_audio_source_stream e post_decode_audio_sink_stream. Isso significa que os usuários podem manipular o áudio dos usuários remotos de forma exclusiva para cada receptor local do áudio do chat.

Fontes e coletores

Diferentemente do pipeline antes da codificação, o modelo para lidar com os dados de áudio após a decodificação é dividido em duas classes: post_decode_audio_source_stream e post_decode_audio_sink_stream. O áudio decodificado dos usuários remotos pode ser recuperado dos objetos post_decode_audio_source_stream, manipulado e enviado aos objetos post_decode_audio_sink_stream para renderização. Isso permite a integração entre o pipeline de processamento de áudio após a decodificação do Game Chat 2 e middlewares de áudio úteis.

Tempo de vida do fluxo

Quando uma nova instância de post_decode_audio_source_stream ou post_decode_audio_sink_stream está pronta para uso pelo aplicativo, ela é entregue por meio de uma estrutura game_chat_stream_state_change com o campo state_change_type definido como game_chat_stream_state_change_type::post_decode_audio_source_stream_created ou game_chat_stream_state_change_type::post_decode_audio_sink_stream_created, respectivamente. Depois que essa alteração de estado do fluxo é devolvida ao Game Chat 2, o fluxo de áudio fica disponível para a manipulação de áudio após a decodificação. Quando um post_decode_audio_source_stream ou post_decode_audio_sink_stream existente fica indisponível para uso na manipulação de áudio, o aplicativo é notificado por meio de uma estrutura game_chat_stream_state_change com o campo state_change_type definido como game_chat_stream_state_change_type::post_decode_audio_source_stream_closed ou game_chat_stream_state_change_type::post_decode_audio_sink_stream, respectivamente. Essa é a oportunidade de o aplicativo começar a limpar os recursos associados a esse fluxo de áudio. Depois que essa alteração de estado do fluxo é devolvida ao Game Chat 2, o fluxo de áudio fica indisponível para a manipulação de áudio após a decodificação. Para fluxos de origem, isso significa que mais nenhum buffer é enfileirado para manipulação. Para fluxos coletores, isso significa que os buffers enviados não são mais renderizados. Quando um post_decode_audio_source_stream ou post_decode_audio_sink_stream fechado tem todos os seus recursos devolvidos, o fluxo é destruído e o aplicativo é notificado por meio de uma estrutura game_chat_stream_state_change com o campo state_change_type definido como game_chat_stream_state_change_type::post_decode_audio_source_stream_destroyed ou game_chat_stream_state_change_type::post_decode_audio_sink_stream_destroyed, respectivamente. Todas as referências ou ponteiros para esse fluxo devem ser limpos. Depois que essa alteração de estado do fluxo é devolvida ao Game Chat 2, a memória do fluxo de áudio se torna inválida.

Usuários do fluxo

A lista de usuários remotos associados a um fluxo de origem após a decodificação pode ser inspecionada usando post_decode_audio_source_stream::get_users(). A lista de usuários locais associados a um fluxo coletor após a decodificação pode ser inspecionada usando post_decode_audio_sink_stream::get_users().

Formatos de áudio

O formato de áudio dos buffers que o aplicativo recupera do Game Chat 2 pode ser inspecionado usando post_decode_audio_source_stream::get_pre_processed_format(). O formato de áudio pré-processado é sempre mono, PCM inteiro de 16 bits. O aplicativo precisa informar ao Game Chat 2 o formato de áudio dos buffers manipulados que estão sendo enviados a ele para renderização usando post_decode_audio_sink_stream::set_processed_format(). Os formatos processados dos fluxos coletores de áudio após a decodificação precisam atender às seguintes pré-condições.
  • O formato precisa ter menos de 64 canais.
  • O formato precisa ser PCM inteiro de 16 bits (ideal), PCM inteiro de 20 bits (em um contêiner de 24 bits), PCM inteiro de 24 bits, PCM inteiro de 32 bits ou PCM float de 32 bits (formato preferencial depois do PCM inteiro de 16 bits).
  • A taxa de amostragem do formato precisa estar entre 1.000 e 200.000 amostras por segundo.

Recuperando e enviando áudio após a decodificação

Os aplicativos podem consultar os fluxos de origem de áudio após a decodificação para saber o número de buffers disponíveis para processar usando post_decode_audio_source_stream::get_available_buffer_count(). Essa informação pode ser usada se o aplicativo quiser adiar o processamento de áudio até que um número mínimo de buffers esteja disponível. Apenas 10 buffers são enfileirados em cada fluxo de origem de áudio após a decodificação, e atrasos de áudio introduzem latência no pipeline de áudio. Recomendamos que os aplicativos esvaziem seus fluxos de áudio após a decodificação antes que eles enfileirem mais de 4 buffers.

Recuperando buffers de áudio com get_next_buffer()

Os aplicativos podem recuperar buffers de áudio de um fluxo de origem de áudio após a decodificação usando post_decode_audio_source_stream::get_next_buffer(). Novos buffers de áudio ficam disponíveis, em média, uma vez a cada 40 ms. Os buffers retornados por esse método precisam ser liberados para post_decode_audio_source_stream::return_buffer() quando não forem mais usados. Pode haver no máximo 10 buffers enfileirados ou não devolvidos a qualquer momento para um fluxo de origem de áudio após a decodificação. Depois que esse limite é atingido, os novos buffers decodificados do usuário remoto são descartados até que alguns dos buffers pendentes sejam devolvidos.

Enviando buffers de áudio com submit_buffer()

Os aplicativos podem enviar seus buffers inspecionados e manipulados de volta ao Game Chat 2 por meio dos fluxos coletores de áudio após a decodificação para renderização usando post_decode_audio_sink_stream::submit_mixed_buffer(). O Game Chat 2 oferece suporte à manipulação de áudio no próprio buffer (in-place) e em outro buffer (out-of-place). Os buffers enviados a post_decode_audio_sink_stream::submit_mixed_buffer() não precisam necessariamente ser os mesmos buffers recuperados de post_decode_audio_source_stream::get_next_buffer(). A cada 40 ms, os próximos 40 ms de áudio desse fluxo são renderizados. Para evitar falhas no áudio, os buffers de áudio que devem ser ouvidos continuamente devem ser enviados a esse fluxo a uma taxa constante.

Privacidade e mixagem

Devido ao modelo de origem e coletor do pipeline após a decodificação, é responsabilidade do aplicativo mixar os buffers recuperados dos objetos post_decode_audio_source_stream e enviar os buffers mixados aos objetos post_decode_audio_sink_stream para renderização. Isso também significa que é responsabilidade do aplicativo fazer a mixagem aplicando corretamente a privacidade e os privilégios. O Game Chat 2 fornece post_decode_audio_sink_stream::can_receive_audio_from_source_stream() para tornar a consulta dessas informações simples e eficiente.

Indicadores de chat

A manipulação de áudio após a decodificação não afeta o estado do indicador de chat de cada usuário. Por exemplo, quando um usuário remoto está silenciado, o áudio é fornecido ao aplicativo. No entanto, o indicador de chat desse usuário remoto ainda indica que ele está silenciado. Quando um usuário remoto está falando, o áudio dele é fornecido. No entanto, o indicador de chat indica que ele está falando, independentemente de o aplicativo fornecer uma mixagem de áudio que contenha o áudio desse usuário. Para obter mais informações sobre a interface e o indicador de chat, consulte Usando o Game Chat 2. Se forem usadas restrições extras específicas do aplicativo para determinar quais usuários estão presentes em uma mixagem de áudio, é responsabilidade do aplicativo considerar essas mesmas restrições ao ler os indicadores de chat fornecidos pelo Game Chat 2.

Contextos de fluxo

Os aplicativos podem gerenciar valores de contexto personalizados do tamanho de um ponteiro nos fluxos de áudio após a decodificação usando os métodos post_decode_audio_source_stream::set_custom_stream_context e post_decode_audio_source_stream::custom_stream_context. Esses contextos de fluxo personalizados são úteis para criar mapeamentos entre os fluxos de áudio do Game Chat 2 e dados auxiliares. Por exemplo, metadados do fluxo e estado do jogo.

Exemplo

Veja a seguir um exemplo simplificado de ponta a ponta de como usar os fluxos de áudio após a decodificação em um quadro de processamento de áudio.

Tempo de vida dos usuários do chat

Habilitar a manipulação de áudio em tempo real afeta o tempo de vida dos usuários do chat. Se chat_manager::remove_user(chatUserX) for chamado, o objeto chat_user apontado por chatUserX permanecerá válido até que todos os fluxos de áudio que fazem referência a chatUserX tenham sido destruídos. Considere o cenário a seguir.

Documentação de referência da API

Confira também

Introdução ao Game Chat 2 Usando a API C++ do Game Chat 2 Conteúdo da API (GameChat2) Microsoft Game Development Kit
Última modificação em 8 de outubro de 2026