BR112021000163A2 - Aparelho de áudio para um sistema de distribuição de áudio que compreende um servidor de áudio para receber áudio de entrada de uma pluralidade de clientes remotos e para transmitir áudio derivado do áudio de entrada para pelo alguns dentre a pluralidade de clientes remotos, sistema de distribuição de áudio, método de operação de um aparelho de áudio para um sistema de distribuição de áudio, e produto de programa de computador - Google Patents

Abstract

aparelho de áudio para um sistema de distribuição de áudio que compreende um servidor de áudio para receber áudio de entrada de uma pluralidade de clientes remotos e para transmitir áudio derivado do áudio de entrada para pelo alguns dentre a pluralidade de clientes remotos, sistema de distribuição de áudio, método de operação de um aparelho de áudio para um sistema de distribuição de áudio, e produto de programa de computador. trata-se de um sistema de distribuição que compreende um servidor de áudio (101) para receber áudio de entrada a partir de clientes remotos (103) e para transmitir áudio derivado do áudio de entrada para os clientes remotos (103). um aparelho de áudio compreende: um receptor de áudio (401) que recebe dados que compreendem: dados de áudio para uma pluralidade de componentes de áudio que representam o áudio de um cliente remoto dentre a pluralidade de clientes remotos; e dados de proximidade para pelo menos um dos componentes de áudio. os dados de proximidade são indicativos de proximidade entre clientes remotos. um gerador (403) do aparelho gera uma mixagem de áudio dentre os componentes de áudio em resposta aos dados de proximidade. por exemplo, um componente de áudio indicado como proximal a um cliente remoto pode ser excluído de uma mixagem de áudio para esse cliente remoto.

Description

APARELHO DE ÁUDIO PARA UM SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO QUE COMPREENDE UM SERVIDOR DE ÁUDIO PARA RECEBER ÁUDIO DE ENTRADA DE UMA PLURALIDADE DE CLIENTES REMOTOS E PARA TRANSMITIR ÁUDIO DERIVADO DO ÁUDIO DE ENTRADA PARA PELO ALGUNS DENTRE A PLURALIDADE DE CLIENTES REMOTOS, SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, MÉTODO DE OPERAÇÃO DE UM APARELHO DE ÁUDIO PARA UM SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, E PRODUTO DE

PROGRAMA DE COMPUTADOR Campo da invenção

[001] A invenção se refere a um aparelho de áudio, sistema de distribuição de áudio e método para os mesmos e, em particular, mas não exclusivamente, ao uso desse aparelho para suportar um aplicativo de conferência de realidade aumentada/virtual. Antecedentes da invenção

[002] A variedade e a gama de experiências baseadas em conteúdo audiovisual aumentaram substancialmente nos últimos anos com novos serviços e maneiras de utilizar e consumir tal conteúdo sendo continuamente desenvolvidos e introduzidos. Em particular, muitas experiências, aplicativos e serviços espaciais e interativos estão sendo desenvolvidos para proporcionar aos usuários uma experiência mais envolvente e imersiva.

[003] Exemplos de tais aplicativos são os aplicativos de Realidade Virtual (VR, Virtual Reality) e Realidade Aumentada (AR, Augmented Reality) que estão se tornando rapidamente convencionais, com uma série de soluções sendo direcionadas para o mercado consumidor. Vários padrões também estão em desenvolvimento por vários organismos de padronização. Essas atividades de padronização estão desenvolvendo ativamente padrões para os vários aspectos dos sistemas de VR/AR, incluindo transmissão contínua, difusão, renderização etc.

[004] Os aplicativos de VR tendem a fornecer experiências de usuário correspondentes ao usuário que está em um mundo/ambiente/cena diferente, enquanto os aplicativos de AR (incluindo Realidade Mista (MR, Mixed Reality)) tendem a fornecer experiências de usuário correspondentes ao usuário que está no ambiente atual, mas com informações adicionais ou objetos virtuais ou informações sendo adicionadas. Dessa forma, os aplicativos de VR tendem a fornecer uma cena/cena gerada sinteticamente totalmente imersiva, enquanto os aplicativos AR tendem a fornecer um mundo/cena parcialmente sintético que é sobreposto à cena real na qual o usuário está fisicamente presente. No entanto, os termos são frequentemente usados de forma intercambiável e têm um alto grau de sobreposição. A seguir, o termo Realidade Virtual/VR será usado para denotar tanto Realidade Virtual como Realidade Aumentada.

[005] Como exemplo, um serviço cada vez mais popular é o fornecimento de imagens e áudio de forma que um usuário possa interagir ativa e dinamicamente com o sistema para alterar os parâmetros da renderização de modo que isso se adapte ao movimento e às alterações na posição e orientação do usuário. Um recurso muito interessante em muitos aplicativos é a capacidade de alterar a posição de visualização e a direção de visualização efetivas do espectador, por exemplo, possibilitando que o mesmo se mova e “olhe ao redor” na cena que está sendo apresentada.

[006] Esse recurso pode, especificamente, possibilitar que uma experiência de realidade virtual seja fornecida a um usuário. Isso pode possibilitar que o usuário se mova de forma (relativamente) livre em um ambiente virtual e altere dinamicamente sua posição e a direção na qual ele está olhando. Geralmente, tais aplicativos de realidade virtual se baseiam em um modelo tridimensional da cena, com o modelo sendo calculado dinamicamente para fornecer a visualização específica solicitada. Essa abordagem é também bem conhecida, por exemplo, em aplicativos de jogos, como na categoria de atiradores em primeira pessoa, para computadores e consoles.

[007] É também desejável, em particular, para aplicativos de realidade virtual, que a imagem que é apresentada seja uma imagem tridimensional. De fato, para otimizar a imersão do espectador, é geralmente preferencial que o usuário experimente a cena apresentada como uma cena tridimensional. De fato, uma experiência de realidade virtual deve, de preferência, possibilitar que um usuário selecione sua própria posição, ponto de visualização da câmera e momento no tempo em relação a um mundo virtual.

[008] Tipicamente, os aplicativos de realidade virtual são inerentemente limitados pelo fato de se basearem em um modelo predeterminado da cena, e tipicamente em um modelo artificial de um mundo virtual. Em alguns aplicativos, uma experiência de realidade virtual pode ser fornecida com base na captura do mundo real. Em muitos casos, tal abordagem tende a se basear em um modelo virtual do mundo real que é construído a partir das capturas do mundo real. A experiência de realidade virtual é então gerada por meio da avaliação desse modelo.

[009] Muitas abordagens atuais tendem a ficar abaixo do ideal e frequentemente tendem a ter alto requisito de recursos computacionais ou de comunicação e/ou fornecer uma experiência de usuário abaixo do ideal, por exemplo com qualidade reduzida ou liberdade limitada.

[010] Como exemplo de um aplicativo, os óculos de realidade virtual entraram no mercado, o que possibilita que os espectadores experimentem vídeos capturados de 360 ° (panorâmicos) ou 180°. Esses vídeos 360° são frequentemente pré-capturados com o uso de equipamentos de câmera onde imagens individuais são reunidas em um único mapeamento esférico. Os formatos estéreo comuns para vídeo 180° ou 360° são superior/inferior e esquerdo/direito. De forma similar ao vídeo estéreo não panorâmico, as imagens do olho esquerdo e do olho direito são compactadas, por exemplo, como parte de um único fluxo de vídeo H.264.

[011] Além da renderização visual, a maioria dos aplicativos de VR/AR fornece ainda uma experiência de áudio correspondente. Em muitos aplicativos, o áudio oferece, de preferência, uma experiência de áudio espacial onde as fontes de áudio são percebidas como recebidas de posições que correspondem às posições dos objetos correspondentes na cena visual. Assim, as cenas de áudio e vídeo são, de preferência, consideradas consistentes, sendo que ambas fornecem uma experiência espacial completa.

[012] Para áudio, o foco tem sido, até agora, principalmente na reprodução de fones de ouvido que usam a tecnologia de renderização de áudio binaural. Em muitos cenários, a reprodução dos fones de ouvido possibilita uma experiência altamente imersiva e personalizada para o usuário. Com o uso de rastreamento de cabeça, a renderização pode ser feita em resposta aos movimentos da cabeça do usuário, o que aumenta muito a sensação de imersão.

[013] Recentemente, tanto no mercado como nas discussões de padrões, começam a ser propostos casos de uso que envolvem um aspecto “social” ou “compartilhado” de VR (e AR), isto é, a possibilidade de compartilhar uma experiência com outras pessoas. Essas podem ser pessoas em locais diferentes, mas também pessoas no mesmo local (ou uma combinação de ambas). Por exemplo, várias pessoas na mesma sala podem compartilhar a mesma experiência de VR com uma projeção (áudio e vídeo) de cada participante presente no conteúdo/cena de VR. Por exemplo, em um jogo em que várias pessoas participam, cada jogador pode ter um local diferente na cena do jogo e, consequentemente, uma projeção diferente da cena de áudio e vídeo.

[014] Como um exemplo específico, o MPEG tenta padronizar um fluxo de bits e um decodificador para experiências realistas e imersivas de AR/VR com seis graus de liberdade. A VR social é um recurso importante e possibilita que os usuários interajam em um ambiente compartilhado (jogos, teleconferências, compras on-line etc.). O conceito de VR social também facilita tornar uma experiência de VR uma atividade mais social para os usuários fisicamente no mesmo local, mas onde, por exemplo, um monitor montado na cabeça ou outro headset de VR fornece um isolamento perceptivo do ambiente físico.

[015] Um exemplo específico de aplicativos de VR social é um aplicativo de conferência em que os usuários em locais diferentes podem compartilhar uma “sala de reuniões” virtual com usuários, por exemplo, sendo representados por avatares. Como outro exemplo, cada usuário pode ser apresentado com uma representação de outros participantes sendo virtualmente renderizados no próprio ambiente local do usuário, por exemplo pela sobreposição do mundo real com o uso de óculos de realidade aumentada com avatares correspondentes a outros usuários, de modo que os avatares deem a impressão de estarem presentes na sala. Além disso, o usuário individual pode receber uma cena de áudio que inclui o áudio relevante de todos os outros participantes, sendo que esse áudio é renderizado espacialmente nas posições adequadas da fonte de áudio percebida. Essa renderização de áudio e vídeo é realizada de forma que as posições visuais e de áudio de um determinado participante correspondam umas às outras.

[016] Para fornecer a experiência ideal, é desejável que a percepção de áudio e vídeo se alinhe estreitamente, e, em particular, para aplicativos de AR, é desejável que isso se alinhe ainda mais com a cena do mundo real. No entanto, isso é muitas vezes difícil de ser alcançado, pois pode haver uma série de problemas que podem afetar a percepção do usuário. Por exemplo, na prática, o usuário tipicamente usará o aparelho em um local que não se pode garantir que seja totalmente silencioso ou escuro. Embora os headsets possam tentar bloquear a luz e o som, isso tipicamente só será obtido parcialmente. Além disso, em aplicativos de AR, frequentemente faz parte da experiência que o usuário também pode experimentar no ambiente local, e, portanto, não é prático bloquear completamente esse ambiente.

[017] Assim, uma abordagem melhorada para gerar áudio, em particular para uma experiência/aplicativo de realidade virtual/aumentada, como, por exemplo, um aplicativo de conferência VR/AR, seria vantajosa. Em particular, uma abordagem que possibilita uma melhor operação, maior flexibilidade, complexidade reduzida, implementação facilitada, uma experiência de áudio melhorada, uma percepção mais consistente de uma cena audiovisual, sensibilidade a erros reduzida para fontes em um ambiente local; uma experiência de realidade virtual aprimorada e/ou melhor desempenho e/ou operação seria vantajosa. Sumário da invenção

[018] Consequentemente, a invenção busca, de preferência, mitigar, aliviar ou eliminar uma ou mais das desvantagens mencionadas acima, individualmente ou em qualquer combinação.

[019] De acordo com um aspecto da invenção, é fornecido um aparelho de áudio para um sistema de distribuição de áudio que compreende um servidor de áudio para receber áudio de entrada de uma pluralidade de clientes remotos e para transmitir áudio derivado do áudio de entrada para pelo alguns dentre a pluralidade de clientes remotos; sendo que o aparelho compreende: um receptor para receber dados que compreendem: dados de áudio para uma pluralidade de componentes de áudio, sendo que cada componente de áudio representa o áudio de um cliente remoto dentre a pluralidade de clientes remotos; dados de proximidade para pelo menos um dos componentes de áudio, sendo que os dados de proximidade são indicativos da proximidade física entre clientes remotos em um ambiente acústico do mundo real; e um gerador para gerar uma mixagem de áudio da pluralidade de componentes de áudio em resposta aos dados de proximidade; sendo que o gerador é disposto para gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

[020] A invenção pode fornecer uma experiência de usuário aprimorada em muitas modalidades e pode fornecer especificamente uma distribuição de áudio aprimorada em muitos aplicativos, como aplicativos de conferência especificamente baseados em uma abordagem de AR/VR. A abordagem pode fornecer uma melhor percepção de áudio em cenários em que os usuários/participantes estão, por exemplo, na mesma sala. Uma percepção melhor e mais natural da cena de áudio pode ser obtida tipicamente e, em muitos cenários, a interferência e a inconsistência resultantes de usuários/clientes colocalizados podem ser atenuadas ou reduzidas. A abordagem pode ser particularmente vantajosa para aplicativos de Realidade Virtual, VR (incluindo Realidade Aumentada, AR). Ela pode, por exemplo, fornecer uma experiência de usuário aprimorada, por exemplo, para aplicativos sociais de VR/AR, sendo que uma pluralidade de participantes está presente no mesmo local.

[021] A abordagem pode, em muitas modalidades, fornecer desempenho aprimorado ao mesmo tempo em que mantém baixa complexidade e uso de recursos.

[022] Os dados de proximidade podem ser especificamente dados de proximidade acústica. Os dados de proximidade podem incluir indicações de proximidade para conjuntos (tipicamente pares) de clientes remotos. Uma indicação de proximidade para um conjunto de clientes remotos pode ser indicativa de uma distância espacial entre os clientes remotos e/ou fontes/usuários de áudio associados ou, por exemplo, pode ser indicativa de uma atenuação acústica entre os clientes remotos e/ou fontes/usuários de áudio associados.

[023] A mixagem de áudio pode ser um conjunto de sinais/canais de áudio (potencialmente) que compreende contribuições de uma pluralidade dos componentes de áudio.

[024] Os dados de proximidade podem ser indicativos de uma proximidade real/absoluta/física entre clientes remotos. Os dados de proximidade refletem especificamente a proximidade física real entre clientes remotos no ambiente acústico do mundo real.

[025] O gerador é disposto de modo a gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

[026] Isso pode fornecer uma experiência de usuário aprimorada e/ou melhor desempenho e percepção de áudio em muitos cenários. Isso pode, em particular, possibilitar uma melhor adaptação da percepção de áudio combinada à potencial interferência de áudio entre a cena de áudio renderizado e a cena de áudio do mundo real. A atenuação na primeira mixagem de áudio do segundo componente de áudio para o segundo cliente remoto pode ser em resposta a uma indicação de proximidade nos dados de proximidade, sendo que a indicação de proximidade é indicativa de proximidade/distância entre o primeiro cliente remoto e o segundo cliente remoto.

[027] De acordo com um recurso opcional da invenção, o gerador é disposto de modo a atenuar o segundo componente de áudio na primeira mixagem de áudio para os dados de proximidade que atendem a um critério de proximidade para o primeiro cliente remoto e o segundo cliente remoto.

[028] Isso pode fornecer uma experiência de usuário aprimorada e/ou melhor desempenho e percepção de áudio em muitos cenários. O gerador pode ser disposto de modo a atenuar o segundo componente de áudio para os dados de proximidade, indicando uma medida de distância entre o primeiro cliente remoto e o segundo cliente remoto abaixo de um limite. A atenuação pode ser infinita. Especificamente, o gerador pode ser disposto de modo a suprimir/descartar/excluir o segundo componente de áudio para os dados de proximidade que atendem ao critério de proximidade para o primeiro cliente remoto e o segundo cliente remoto.

[029] De acordo com um recurso opcional da invenção, o aparelho de áudio faz parte do servidor de áudio.

[030] Isso pode fornecer um alto desempenho e/ou uma implementação eficiente em muitas modalidades.

[031] De acordo com um recurso opcional da invenção, o aparelho de áudio faz parte de um cliente remoto dentre a pluralidade de clientes remotos.

[032] Isso pode fornecer alto desempenho e implementação eficiente em muitas modalidades.

[033] De acordo com um recurso opcional da invenção, os dados de proximidade incluem uma indicação de proximidade escalar para pelo menos um primeiro cliente remoto e um segundo cliente remoto, a indicação de proximidade escalar é indicativa de uma atenuação acústica de uma fonte de áudio do segundo cliente remoto para um elemento de captura do primeiro cliente remoto.

[034] Isso pode fornecer uma operação particularmente vantajosa em muitas modalidades. Em algumas modalidades, a indicação de proximidade escalar pode ser uma indicação de proximidade binária que indica se os clientes remotos correspondentes estão próximos ou não (por exemplo, na mesma sala).

[035] De acordo com um recurso opcional da invenção, os dados de proximidade compreendem uma indicação de proximidade de um primeiro cliente remoto para um segundo cliente remoto diferente da proximidade do segundo cliente remoto para o primeiro cliente remoto.

[036] Isso pode fornecer uma operação vantajosa em muitos cenários. A abordagem pode possibilitar e suportar indicações assimétricas de proximidade, por exemplo refletir diferenças acústicas locais (como ao se usar microfones direcionais ou um participante usar fones de ouvido fechados).

[037] De acordo com um recurso opcional da invenção, o receptor é disposto de modo a receber dados de proximidade que se adaptam dinamicamente a mudanças em posições de pelo menos um dentre a pluralidade de clientes remotos.

[038] Isso pode fornecer uma operação eficiente e pode fornecer uma abordagem que se adapta dinamicamente aos movimentos do usuário.

[039] De acordo com um aspecto da invenção, é fornecido um sistema de distribuição de áudio que compreende: uma pluralidade de clientes remotos; um servidor de áudio para receber áudio de entrada da pluralidade de clientes remotos e para transmitir áudio derivado do áudio de entrada para pelo menos um dentre a pluralidade de clientes remotos; sendo que ao menos um dentre o servidor de áudio e um dentre a pluralidade de clientes remotos compreendem: um receptor para receber dados compreendendo: dados de áudio para uma pluralidade de componentes de áudio, sendo que cada componente de áudio representa o áudio de um cliente remoto dentre a pluralidade de clientes remotos; dados de proximidade para pelo menos um dos componentes de áudio, sendo que os dados de proximidade são indicativos da proximidade física entre clientes remotos em um ambiente acústico do mundo real; e um gerador para gerar uma mixagem de áudio da pluralidade de componentes de áudio em resposta aos dados de proximidade; sendo que o gerador é disposto para gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

[040] De acordo com um recurso opcional da invenção, o sistema de distribuição de áudio compreende um detector de proximidade disposto de modo a determinar uma indicação de proximidade para um primeiro cliente remoto e um segundo cliente remoto em resposta a uma comparação de um primeiro componente de áudio para o primeiro cliente remoto e um segundo componente de áudio para um segundo cliente remoto; e um transmissor para transmitir dados de proximidade que compreendem a indicação de proximidade ao receptor.

[041] Isso pode fornecer um desempenho e uma baixa complexidade particularmente vantajosos em muitas modalidades.

[042] De acordo com um recurso opcional da invenção, o detector de proximidade faz parte do servidor de áudio.

[043] Isso pode fornecer desempenho particularmente vantajoso e baixa complexidade em muitas modalidades.

[044] De acordo com uma característica opcional da invenção, um primeiro cliente remoto dentre a pluralidade de clientes remotos compreende: uma entrada para gerar um sinal de microfone correspondente ao áudio capturado por um conjunto de microfones; um detector de proximidade disposto de modo a determinar uma indicação de proximidade para o primeiro cliente remoto em resposta a uma comparação do sinal do microfone e do áudio recebido do servidor de áudio; e um transmissor para transmitir dados de áudio acústico que compreendem a indicação de proximidade ao servidor de áudio.

[045] Isso pode fornecer desempenho particularmente vantajoso e baixa complexidade em muitas modalidades. O conjunto de microfones pode, em algumas modalidades, incluir um único microfone ou, por exemplo, compreender uma pluralidade de microfones, como, por exemplo, um conjunto de microfones, por exemplo, usados para formação de feixes/captura direcional.

[046] De acordo com um recurso opcional da invenção, o transmissor é disposto de modo a transmitir dados de proximidade que são indicativos de que um cliente remoto atualmente ativo está sendo determinado como proximal em resposta ao primeiro detector de proximidade que detecta uma alta correlação entre o sinal do microfone e o áudio recebido do servidor de áudio.

[047] Isso pode fornecer desempenho particularmente vantajoso e baixa complexidade em muitas modalidades.

[048] De acordo com um aspecto da invenção, é fornecido um método de operação de um aparelho de áudio para um sistema de distribuição de áudio que compreende um servidor de áudio para receber áudio de entrada de uma pluralidade de clientes remotos e para transmitir áudio derivado do áudio de entrada para pelo menos alguns dentre a pluralidade de clientes remotos; sendo que o método compreende: receber dados que compreendem: dados de áudio para uma pluralidade de componentes de áudio, sendo que cada componente de áudio representa o áudio de um cliente remoto da pluralidade de clientes remotos; dados de proximidade para pelo menos um dos componentes de áudio, sendo que os dados de proximidade são indicativos da proximidade física entre clientes remotos em um ambiente acústico do mundo real; e gerar uma mixagem de áudio da pluralidade de componentes de áudio em resposta aos dados de proximidade, sendo que a geração compreende gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

[049] Esses e outros aspectos, recursos e vantagens da invenção ficarão evidentes e serão elucidados com referência às uma ou mais modalidades descritas a seguir. Breve descrição dos desenhos

[050] As modalidades da invenção serão descritas, apenas a título de exemplo, com referência aos desenhos, nos quais:

[051] A Figura 1 ilustra um exemplo de um sistema de distribuição de áudio;

[052] A Figura 2 ilustra um exemplo de um sistema de distribuição de áudio;

[053] A Figura 3 ilustra um exemplo de um sistema de distribuição de áudio para audioconferência;

[054] A Figura 4 ilustra um exemplo de elementos de um aparelho de áudio de acordo com algumas modalidades da invenção;

[055] A Figura 5 ilustra um exemplo de elementos de um sistema de distribuição de áudio de acordo com algumas modalidades da invenção; e

[056] A Figura 6 ilustra um exemplo de elementos de um cliente remoto para um sistema de distribuição de áudio de acordo com algumas modalidades da invenção. Descrição detalhada de algumas modalidades da invenção

[057] As experiências virtuais (incluindo aumentadas) que possibilitam que um usuário se mova em um mundo virtual ou aumentado estão se tornando cada vez mais populares e os serviços estão sendo desenvolvidos para satisfazer tais demandas. Em muitas dessas abordagens, os dados visuais e de áudio podem ser gerados dinamicamente para refletir a pose atual de um usuário (ou espectador).

[058] No campo, os termos “posicionamento” e “pose” são usados como um termo comum para posição e/ou direção/orientação. A combinação da posição e da direção/orientação, por exemplo de um objeto, uma câmera, uma cabeça ou uma vista, pode ser chamada de uma pose ou posicionamento. Dessa forma, uma indicação de posicionamento ou pose pode compreender até seis valores/componentes/graus de liberdade com cada valor/componente descrevendo tipicamente uma propriedade individual da posição/localização ou da orientação/direção do objeto correspondente. Naturalmente, em muitas situações, um posicionamento ou uma pose podem ser considerados ou representados com menos componentes, por exemplo se um ou mais componentes forem considerados fixos ou irrelevantes (por exemplo se todos os objetos forem considerados como estando na mesma altura e tiverem uma orientação horizontal, quatro componentes podem fornecer uma representação completa da pose de um objeto). No texto a seguir, o termo “pose” é usado para se referir a uma posição e/ou orientação que pode ser representada por um a seis valores (correspondentes ao número máximo de graus de liberdade possíveis).

[059] Muitos aplicativos de VR se baseiam em uma pose que tem o número máximo de graus de liberdade, isto é, três graus de liberdade de cada uma dentre a posição e a orientação, resultando em um total de seis graus de liberdade. Uma pose pode, dessa forma, ser representada por um conjunto ou vetor de seis valores que representam os seis graus de liberdade e, dessa forma, um vetor de pose pode fornecer uma posição tridimensional e/ou uma indicação de direção tridimensional. Entretanto, será reconhecido que, em outras modalidades, a pose pode ser representada por menos valores.

[060] Um sistema ou entidade com base no fornecimento do grau máximo de liberdade para o espectador é tipicamente conhecido como tendo 6 graus de liberdade (6DoF). Muitos sistemas e entidades fornecem apenas uma orientação ou posição e são tipicamente conhecidos como tendo 3 graus de liberdade (3DoF).

[061] Tipicamente, o aplicativo de realidade virtual gera uma saída tridimensional na forma de imagens de visualização separadas para os olhos esquerdo e direito. Elas podem ser apresentadas ao usuário por meios adequados, como, tipicamente, exibições individuais dos olhos esquerdo e direito de um headset de VR. Em outras modalidades, uma ou mais imagens de visualização podem, por exemplo, ser apresentadas em uma exibição autoestereoscópica ou, de fato, em algumas modalidades, apenas uma única imagem bidimensional pode ser gerada (por exemplo, com o uso de uma exibição bidimensional convencional).

[062] Da mesma forma, para um determinado espectador/usuário/ouvinte, uma representação de áudio da cena pode ser fornecida. A cena de áudio é tipicamente renderizada para fornecer uma experiência espacial em que as fontes de áudio são percebidas como originadas das posições desejadas. Como as fontes de áudio podem ser estáticas na cena, as alterações na pose do usuário resultarão em uma alteração na posição relativa da fonte de áudio em relação à pose do usuário. Assim, a percepção espacial da fonte de áudio deve mudar para refletir a nova posição em relação ao usuário. A renderização de áudio pode ser adaptada de acordo com a pose do usuário.

[063] Em muitas modalidades, a renderização de áudio é uma renderização binaural que usa funções de transferência relacionadas à cabeça (HRTFs, Head Related Transfer Functions) ou respostas de impulsos de sala binaural (BRIRs, Binaural Room Impulse Responses) (ou similares) para fornecer o efeito espacial desejado para um usuário com fones de ouvido. Entretanto, deve-se considerar que, em alguns sistemas, o áudio pode ser renderizado com o uso de um sistema de alto-falantes e os sinais para cada alto-falante podem ser renderizados de forma que o efeito geral no usuário corresponda à experiência espacial desejada.

[064] A ação de posição do usuário ou do espectador pode ser determinada de diferentes maneiras em diferentes aplicativos. Em muitas modalidades, o movimento físico de um usuário pode ser rastreado diretamente. Por exemplo, uma câmera que pesquisa uma área do usuário pode detectar e rastrear a cabeça do usuário (ou até mesmo os olhos (rastreamento ocular)). Em muitas modalidades, o usuário pode usar um headset de VR que pode ser rastreado por meios externos e/ou internos. Por exemplo, o headset pode incluir acelerômetros e giroscópios que fornecem informações sobre o movimento e a rotação do headset e, portanto, da cabeça. Em alguns exemplos, o headset de VR pode transmitir sinais ou compreender identificadores (por exemplo, visuais) que possibilitam que um sensor externo determine a posição do headset de VR.

[065] Em alguns sistemas, a pose do espectador pode ser fornecida por meios manuais, por exemplo, pelo usuário que controla manualmente um joystick ou uma ação manual similar. Por exemplo, o usuário pode mover manualmente o espectador virtual na cena virtual controlando um primeiro joystick analógico com uma mão e controlando manualmente a direção na qual o espectador virtual está olhando, movendo manualmente um segundo joystick analógico com a outra mão.

[066] Em alguns aplicativos, uma combinação de abordagens manuais e automatizadas pode ser usada para gerar a pose do espectador de entrada. Por exemplo, um headset pode rastrear a orientação da cabeça e o movimento/posição do espectador na cena pode ser controlado pelo usuário usando um joystick.

[067] Em alguns sistemas, o aplicativo de VR pode ser fornecido localmente a um espectador, por exemplo, por um dispositivo independente que não usa, ou mesmo tem acesso a, quaisquer dados ou processamento de VR remotos. Por exemplo, um dispositivo como um console de jogos pode compreender uma loja para armazenar os dados da cena, ação para receber/gerar a pose do espectador e um processador para gerar as imagens correspondentes a partir dos dados da cena.

[068] Em outros sistemas, o aplicativo de VR pode ser implementado e executado remotamente a partir do espectador. Por exemplo, um dispositivo local para o usuário pode detectar/receber movimento/apresentar dados que são transmitidos para um dispositivo remoto que processa os dados para gerar a pose do espectador. O dispositivo remoto pode então gerar imagens de visualização adequadas para a pose do espectador com base nos dados da cena que descrevem a cena. As imagens de visualização são então transmitidas ao dispositivo local para o espectador onde são apresentadas. Por exemplo, o dispositivo remoto pode gerar diretamente uma transmissão de vídeo (tipicamente uma transmissão de vídeo estéreo/3D) que é apresentada diretamente pelo dispositivo local. De modo similar, o dispositivo remoto pode gerar uma cena de áudio refletindo o ambiente de áudio virtual. Isso pode ser feito em muitas modalidades, gerando-se sinais de áudio que correspondem à posição relativa de diferentes fontes de áudio no ambiente de áudio virtual, por exemplo, aplicando-se o processamento binaural aos componentes de áudio individuais correspondentes à posição atual desses em relação à pose da cabeça. Assim, nesse exemplo, o dispositivo local não pode executar nenhum processamento de VR, exceto para transmitir dados de movimento e apresentar dados de vídeo e áudio recebidos.

[069] Da mesma forma, o dispositivo de VR remoto pode gerar dados de áudio que representam uma cena de áudio e pode transmitir componentes/objetos de áudio correspondentes a diferentes fontes de áudio na cena de áudio juntamente com informações de posição indicativas da posição desses componentes (que podem, por exemplo, mudar dinamicamente para objetos em movimento). O dispositivo de VR local pode então processar esses sinais de forma adequada, por exemplo, aplicando o processamento binaural adequado que reflete a posição relativa das fontes de áudio para os componentes de áudio.

[070] Para o lado do áudio, um servidor central pode, em conformidade, em algumas modalidades, gerar uma combinação de áudio espacial que pode ser renderizada diretamente pelo dispositivo cliente remoto. Por exemplo, o servidor central pode gerar áudio espacial como vários canais de áudio para renderização direta por meio de uma configuração de alto-falante de som surround. Entretanto, mais comumente, o servidor central pode gerar uma mixagem processando-se binauralmente todos os sinais de áudio na cena a serem renderizados e, em seguida, combinando-os em um sinal estéreo binaural que pode ser renderizado diretamente no lado do cliente com o uso de um conjunto de fones de ouvido.

[071] Em muitos aplicativos, o servidor central pode, em vez disso, fornecer vários objetos ou componentes de áudio, sendo que cada um deles corresponde tipicamente a uma única fonte de áudio. O cliente pode então processar tais objetos/componentes para gerar a cena de áudio desejada.

Especificamente, ele pode processar binauralmente cada objeto de áudio com base na posição desejada e combinar os resultados.

[072] Nesses sistemas, os dados de áudio transmitidos a um cliente remoto podem incluir dados para uma pluralidade de componentes ou objetos de áudio. O áudio pode, por exemplo, ser representado como áudio codificado para um determinado componente de áudio que deve ser renderizado. Os dados de áudio podem ainda incluir dados de posição que indicam uma posição da fonte do componente de áudio. Os dados posicionais podem, por exemplo, incluir dados de posição absoluta que definem uma posição da fonte de áudio na cena. O aparelho local pode, em tal modalidade, determinar uma posição relativa da fonte de áudio em relação à pose atual do usuário. Assim, os dados da posição recebida podem ser independentes dos movimentos do usuário e uma posição relativa para as fontes de áudio pode ser determinada localmente para refletir a posição da fonte de áudio em relação ao usuário. Essa posição relativa pode indicar a posição relativa de onde o usuário deve perceber a origem da fonte de áudio e, consequentemente, varia de acordo com os movimentos da cabeça do usuário. Em outras modalidades, os dados de áudio podem incluir dados de posição que descrevem diretamente a posição relativa.

[073] A Figura 1 ilustra um exemplo de um sistema de VR no qual um servidor central 101 se liga com vários clientes remotos 103, por exemplo, através de uma rede 105, como a Internet. O servidor central 101 pode ser disposto de modo a suportar simultaneamente um número potencialmente grande de dispositivos clientes 103.

[074] Essa abordagem pode, em muitos cenários, fornecer um melhor trade-off, por exemplo, entre a complexidade e as demandas de recursos para diferentes dispositivos, requisitos de comunicação etc. por exemplo, a pose do espectador e os dados de cena correspondentes podem ser transmitidos com intervalos maiores, com o dispositivo local processando a pose do espectador e os dados de cena recebidos localmente para fornecer uma experiência de atraso baixo em tempo real. Isso pode, por exemplo, reduzir substancialmente a largura de banda de comunicação necessária, enquanto fornece uma experiência de baixa latência e enquanto possibilita que os dados da cena sejam armazenados, gerados e mantidos centralmente. Isso pode, por exemplo, ser adequado para aplicativos em que uma experiência de VR é fornecida a uma pluralidade de dispositivos remotos.

[075] Um aplicativo de VR/AR particularmente atraente é um aplicativo de teleconferência virtual em que usuários/participantes podem estar em locais diferentes. Um exemplo desse tipo de aplicativo é ilustrado na Figura 2 que mostra um servidor central 101, correspondendo ao servidor central da Figura 1, que suporta a uma pluralidade de clientes remotos (áudio) 103. Como pode ser visto, todos os clientes remotos 103 se comunicam diretamente com o servidor central 101 em vez de se comunicarem entre si. Assim, cada cliente remoto 103 fazer upload de um componente de áudio correspondente a uma ou mais fontes de áudio locais para o cliente remoto 103 para o servidor central 101. O servidor central 101 pode transmitir dados de áudio para o cliente remoto individual 103 que representa o áudio de outros clientes remotos 103. Tipicamente, cada usuário ou participante terá um dispositivo separado que implementa um cliente remoto 103, embora, obviamente, um cliente remoto possa, em algumas modalidades e cenários, ser compartilhado por uma pluralidade de usuários/participantes.

[076] Entretanto, os inventores perceberam que um problema para muitos desses sistemas e aplicativos práticos é que o áudio no ambiente local pode afetar a experiência do usuário. Na prática, tende a ser difícil suprimir completamente o áudio no ambiente local e mesmo quando se usa fones de ouvido, há tipicamente uma contribuição perceptível do ambiente local para o áudio percebido. Em alguns casos, esses sons podem ser suprimidos com o uso de, por exemplo, cancelamento de ruído ativo. Entretanto, isso não é prático para fontes de áudio que têm uma contraparte direta na cena de VR e frequentemente tendem a ser imperfeitas.

[077] Na verdade, o problema de interferência entre sons reais do ambiente e sons de cena de áudio é particularmente problemático para aplicativos que fornecem uma experiência de VR que também reflete o ambiente local, como, por exemplo, muitas experiências de AR.

[078] Por exemplo, aplicativos que incluem um aspecto “social” ou “compartilhado” da VR estão sendo procurados, onde, por exemplo, uma pluralidade de pessoas no mesmo ambiente local (por exemplo, sala) compartilham uma experiência comum. Tais casos de uso “social” ou “compartilhado” estão sendo propostos, por exemplo, em MPEG, e agora são uma das principais classes de experiência para a atividade de padronização atual de MPEG-I. Um exemplo de tal aplicativo é onde várias pessoas na mesma sala podem compartilhar a mesma experiência de VR com uma projeção (áudio e vídeo) de cada participante também presente no conteúdo/cena de VR.

[079] Nesse tipo de aplicativo, o ambiente de VR pode incluir uma fonte de áudio correspondente a cada participante, mas além disso, o usuário pode, por exemplo, devido a um vazamento típico de fones de ouvido, ouvir também outros participantes diretamente se estiverem localmente presentes. Na verdade, em muitas situações, um participante pode usar intencionalmente fones de ouvido abertos para ouvir o ambiente local. Essa interferência pode ser prejudicial à experiência do usuário e pode reduzir a imersão do participante. Entretanto, a realização de cancelamento de ruído no componente de som real é muito difícil e é computacionalmente muito dispendiosa. A maioria das técnicas típicas de cancelamento de ruído se baseia em um microfone dentro do fone de ouvido, juntamente com um laço de retroinformação que minimiza (de preferência completamente) qualquer componente de sinal real no sinal do microfone (o sinal do microfone pode ser considerado o sinal de erro que aciona o laço). No entanto, essa abordagem não é viável quando se deseja que a fonte de áudio esteja realmente presente no áudio percebido.

[080] Os inventores perceberam que, para um sistema de conferência como o da Figura 2, a experiência de áudio pode ser degradada especialmente quando diferentes usuários/participantes estão no mesmo local físico e cada usuário tem seu próprio microfone e conexão com o servidor de conferência, ou seja, quando diferentes usuários colocalizados usam diferentes clientes remotos. Um servidor de conferência pode enviar a cada cliente remoto uma combinação exclusiva, incluindo todos os sinais de entrada de outros clientes remotos. Caso os usuários estejam no mesmo local físico, eles tipicamente ouvem os outros usuários no local acusticamente (dependendo da abertura acústica dos fones de ouvido), mas também através dos fones de ouvido, pois o áudio recebido inclui o componente de áudio do cliente remoto do outro usuário. O atraso nessa conexão de conferência é geralmente grande o suficiente para tornar essa experiência muito desagradável.

[081] Este é um problema significativo em particular para AR/VR, pois isso adiciona um componente visual. Se uma pessoa remota participa de uma experiência de AR, essa pessoa também poderá ser renderizada visualmente, por exemplo, por meio de um avatar.

[082] Mesmo que todos os usuários usem conjuntos de fones de ouvido suficientemente fechados para reduzir os níveis de som externos para o usuário (o caso de uso mais provável para VR), existe ainda um componente (acústico direto) da fala de cada usuário para todos os sinais de microfone que são gravados na localização comum. Isso pode causar artefatos, porque a fala chega com atrasos ligeiramente diferentes nos diferentes microfones e, dessa forma, é misturada com atrasos ligeiramente diferentes (e versões mais atenuadas) de si mesma. Um resultado pode ser um efeito correspondente a um filtro tipo pente sendo aplicado.

[083] Assim, as fontes de som locais podem interferir tanto na percepção de áudio do usuário do estágio de áudio renderizado quanto na captura do som do participante individual.

[084] Embora os sistemas de conferência possam silenciar ou atenuar usuários com sinais de microfone de baixo nível para melhorar a inteligibilidade da fala ativa, removendo ruídos ou sons de fundo de microfones de participantes que não estão falando, isso tende a não resolver completamente o problema. Por exemplo, se os microfones de outros participantes captam a fala com um nível suficientemente alto, eles podem não ser silenciados ou atenuados, resultando em uma taxa reduzida de sinal para ruído.

[085] A questão pode ser ilustrada pelo exemplo da Figura 3. O cenário da Sala A resulta em artefatos possivelmente graves nos sistemas de conferência atuais. Com duas conexões com o servidor, o dispositivo do usuário A1 reproduz a fala atrasada do usuário A2 e vice-versa.

[086] Tipicamente, para duas ou mais conexões sendo usadas na mesma sala, ou pelo menos nas proximidades de cada um, o áudio de cada usuário do servidor de conferência excluirá seu próprio sinal de microfone, mas incluirá o áudio de todos os outros usuários com uma latência determinada pelo codec de conferência, sistema, e as conexões entre os usuários e o servidor etc. Para sistemas de conferência típicos, esses atrasos serão inferiores a 500 ms.

[087] Esta situação tem várias desvantagens: - Um usuário que ouve seu próprio discurso com um atraso (retroinformação auditivo atrasado) é muito irritante e conhecido por causar o stress mental. - Se o usuário A1 estiver falando, irá afetar negativamente a inteligibilidade da voz para a(s) outra(s) pessoa(s) na sala, o que aumenta o esforço de audição e a fadiga. - Se o usuário A1 estiver falando, o atraso no discurso dos oradores clientes de outros usuários na sala também é captado pelo microfone do usuário A1, que será novamente reproduzido pelos alto-falantes dos outros usuários, etc., causando, possivelmente, um retroinformação acústica (‘toque'). - Se o usuário A1 estiver falando, também será captado pelos microfones de todos os outros usuários, o que pode causar problemas para o sistema de conferência determinar qual pessoa que está falando (impedindo que o sistema silencie ou atenue outros para administrar o SNR), ou fazer com haja acúmulo de nível de sinal.

[088] A seguir, será descrita uma abordagem que pode tipicamente mitigar tais efeitos e desvantagens. A abordagem é baseada na geração e distribuição de metadados indicativos da relação acústica/espacial entre diferentes clientes remotos. Por exemplo, metadados podem ser gerados, o que indica quais (se houver) clientes remotos estão colocados, e indica especificamente se os clientes remotos estão na mesma sala (a posição de um cliente remoto pode, por exemplo, ser considerada como correspondente à posição da captura de áudio local, como, por exemplo, a posição de um ou mais microfones capturando o áudio local). Os metadados podem ser distribuídos, por exemplo, para um servidor central ou (outros) clientes remotos onde eles podem ser usados na geração de áudio adequado (bem como potencialmente também para outros propósitos).

[089] A Figura 4 ilustra exemplos de um aparelho de áudio para um sistema de distribuição de áudio que inclui um servidor de áudio que atende a uma pluralidade de clientes remotos e que está disposto de modo a receber e transmitir áudio de/para os clientes remotos. A descrição a seguir se concentrará em um sistema de distribuição de áudio na forma de um sistema de conferência de VR e será especificamente descrita com referência a um sistema como o das Figuras 1 a 3.

Entretanto, deve-se se considerar que a abordagem e os princípios gerais não se limitam a um tal sistema de conferência de áudio, mas podem ser aplicados a muitos outros sistemas e aplicativos de distribuição de áudio, como outros serviços de AR sociais.

[090] Assim, o servidor central 101 será, a seguir, chamado de servidor de áudio 101. Ele suporta especificamente um aplicativo de conferência de áudio e, portanto, pode ser considerado um servidor de conferência. Da mesma forma, cada um dos clientes remotos 103 representa um participante/usuário da conferência (ou potencialmente uma pluralidade) e serve a função de capturar/gerar um componente de áudio representando o som/áudio do participante e de renderizar a cena combinada de áudio da conferência para o usuário. Cada cliente remoto pode, além disso, incluir funcionalidades para gerar uma cena visual correspondente, por exemplo, gerando uma cena totalmente virtual com avatares representando outros participantes, ou por exemplo, gerando sobreposições visuais para um headset de AR. As cenas de áudio e visual são geradas para serem consistentes e para fornecer uma renderização integrada de um cenário de conferência adequado.

[091] Tipicamente, cada cliente remoto é composto por pelo menos um microfone disposto de modo a capturar o som. O cliente remoto é disposto de modo a gerar um componente de áudio a partir do sinal do microfone capturado e esse componente de áudio pode ser transmitido para o servidor de áudio 101.

[092] O servidor de áudio 101 recebe os componentes de áudio dos diferentes clientes remotos 103. O servidor de áudio 101 então transmite áudio para cada um dos clientes remotos 103 refletindo os componentes de áudio recebidos de outros clientes remotos 103. Em algumas modalidades, o servidor de áudio 101 pode encaminhar os componentes de áudio recebidos de modo que os clientes remotos 103 recebam componentes de áudio de outros clientes remotos

103. Em outras modalidades, o servidor de áudio 101 pode gerar uma representação combinada de mistura de áudio (por exemplo, um sinal de som surround, sinais binaurais ou um sinal mono) combinando os componentes de áudio para os clientes remotos apropriados 103. Em tais modalidades, o servidor de áudio 101 pode gerar uma mixagem de redução (downmix) de áudio específico para cada cliente remoto 103. A mixagem de áudio pode incluir sinais de áudio representando componentes de áudio de uma pluralidade de clientes remotos 103.

[093] O aparelho de áudio da Figura 2 inclui um receptor 401 que é disposto de modo a receber dados de áudio e metadados associados que compreendem dados de proximidade.

[094] O receptor 401 é especificamente disposto de modo a receber uma pluralidade de componentes de áudio, cada um representando o som de um cliente remoto. Assim, o aparelho de áudio recebe uma pluralidade de componentes de áudio, sendo que cada um deles está associado a um cliente remoto 103 do qual é recebido. Cada componente de áudio pode corresponder especificamente ao áudio/som capturado por um conjunto de microfones no cliente remoto 103.

[095] Além disso, o receptor 401 recebe dados de proximidade para pelo menos um e, tipicamente alguns ou, de fato, todos os componentes de áudio. Os dados de proximidade fornecem dados de relação que fornecem informações sobre a relação acústica/espacial entre clientes remotos 103.

[096] Os dados de proximidade são especificamente indicativos da proximidade entre clientes remotos da pluralidade de clientes remotos. A indicação de proximidade de um primeiro cliente remoto para um segundo cliente remoto pode refletir a atenuação acústica (real) (especificamente a propagação do som por vibrações no ar ou outros meios) de uma fonte de áudio para o primeiro cliente remoto (como um participante falante associado ao primeiro cliente remoto) a uma posição associada ao segundo cliente remoto. Essa posição pode ser especificamente a posição de um microfone do primeiro cliente remoto que captura um sinal do qual o componente de áudio do primeiro cliente remoto é gerado, ou pode, por exemplo, ser uma posição de um usuário (e especificamente os ouvidos de um usuário) ou usuários.

[097] Assim, os dados de proximidade podem ser especificamente dados de proximidade acústica e podem incluir indicações de proximidade para clientes remotos, como indicações de proximidade para pares ou conjuntos de clientes remotos 103.

[098] Os dados de proximidade/indicação de proximidade podem refletir de acordo a função/atenuação de transferência acústica de uma posição do primeiro cliente remoto para uma posição do segundo cliente remoto. A indicação de proximidade de um primeiro cliente remoto para um segundo cliente remoto pode refletir o grau ou nível de áudio associado ao segundo cliente remoto interfere no áudio associado ao primeiro cliente remoto.

[099] A indicação de proximidade de um primeiro cliente remoto para um segundo cliente remoto pode refletir especificamente a quantidade de áudio de uma fonte de áudio associada ao segundo cliente remoto que é capturado no componente de áudio do primeiro cliente remoto. Especificamente, a indicação de proximidade pode refletir quanto do áudio de um alto-falante/participante do segundo cliente remoto é capturado pelo primeiro cliente remoto.

[100] Os dados/indicações de proximidade podem, em muitos cenários, corresponder diretamente a uma proximidade espacial e o termo “proximidade espacial” pode ser usado. Os dados de proximidade podem, portanto, ser dados indicativos da proximidade espacial de diferentes clientes remotos. Em muitas modalidades, os dados de proximidade podem fornecer informações sobre quais clientes remotos são proximais e especificamente colocalizados. Clientes remotos podem ser considerados como colocalizados/proximais se o áudio representado pelo componente de áudio de um cliente remoto também puder ser capturado por outro cliente remoto. Em algumas modalidades, os clientes remotos podem ser considerados colocalizados/proximais se as posições dos clientes remotos atenderem a um critério de distância, como por exemplo, se a distância espacial for menor que um limite ou se os clientes remotos estiverem na mesma sala. Em algumas modalidades, a histerese pode ser incorporada ao limite para evitar a alternância da decisão.

[101] Os dados de proximidade podem ser indicativos de uma proximidade real entre os clientes remotos e, especificamente, da proximidade real de propagação acústica/sonora entre clientes remotos. A indicação de proximidade pode ser independente das posições desejadas do áudio correspondente na cena de áudio gerada da mixagem de áudio. A indicação de proximidade pode ser independente das posições da cena virtual (áudio). A indicação/dados de proximidade podem ser indicativos de propriedades espaciais/acústicas reais. Assim, em vez de refletir alguma forma de proximidade desejada entre o áudio a ser renderizado, os dados de proximidade refletem essa proximidade física real e o ambiente acústico entre clientes remotos. Os dados de proximidade não estão refletindo alguma forma de proximidade imaginária, teórica, virtual ou desejada, por exemplo, de alguma esfera não física, mas refletem a proximidade do mundo real (tipicamente acústica).

[102] Em muitas modalidades, as indicações de proximidade podem ser simétricas, ou seja, a mesma indicação/medida de proximidade pode se aplicar à proximidade de um primeiro cliente remoto a um segundo cliente remoto, bem como do segundo cliente remoto ao primeiro cliente remoto. Entretanto, em algumas modalidades, podem ser aplicadas indicações assimétricas de proximidade. Por exemplo, para clientes remotos que usam microfones direcionais, a atenuação em um segundo cliente remoto de um alto-falante associado a um primeiro cliente remoto pode ser diferente da atenuação no primeiro cliente remoto de um alto-falante associado ao segundo cliente remoto. De modo similar, quando os dados de proximidade incluem uma posição aos ouvidos de um participante/usuário do primeiro cliente remoto usando fones de ouvido, a atenuação depende da atenuação acústica exercida pelos fones de ouvido e pode ser diferente da atenuação para os ouvidos de um participante/usuário do segundo cliente remoto.

[103] O receptor 401 recebe dados de proximidade que podem representar inter-relações espaciais/acústicas entre os clientes remotos 103 e, especificamente, pode indicar quais clientes remotos 103 estão colocalizados/proximais, como, por exemplo, na mesma sala.

[104] O receptor 401 está acoplado a um gerador 403 que recebe os componentes de áudio e os dados de proximidade. O gerador está disposto de modo a gerar uma mixagem de áudio da pluralidade de componentes de áudio em resposta aos dados de proximidade. A mixagem de áudio pode compreender uma pluralidade de componentes de áudio a partir de diferentes clientes remotos combinados em um conjunto de sinais. Ao menos um dos sinais pode compreender áudio de uma pluralidade de componentes de áudio/clientes remotos.

[105] Por exemplo, o gerador 403 pode gerar uma mixagem de redução de som surround ou um sinal estéreo binaural mediante a combinação/execução da mixagem de redução do componente de áudio em canais. A mixagem de redução é feita ainda dependendo dos dados de proximidade, de modo que, por exemplo, o nível dos componentes de áudio seja dependente dos dados de proximidade.

[106] O gerador 403 pode ser especificamente disposto de modo a gerar um sinal de áudio para um cliente remoto específico combinando todos os componentes de áudio, exceto os componentes de áudio de clientes remotos que são indicados pelos dados de proximidade a serem colocados no cliente remoto específico para o qual o áudio o sinal é gerado.

[107] No sistema, os metadados que compreendem dados de proximidade são incluídos nos fluxos de bits de um sistema de distribuição de áudio indicando, por exemplo, quais usuários/clientes compartilham um local físico. Os metadados podem, por exemplo, ser usados para determinar quais sinais reproduzir em cada participante da conferência. Por exemplo, os sinais de áudio reproduzidos para os participantes que compartilham um local comum podem não incluir os sinais capturados uns dos outros, mas apenas de usuários remotos, enquanto sua fala é enviada para usuários remotos. Isso pode, por exemplo, evitar estresse mental, fadiga e artefatos de áudio devido à latência do sistema de conferência, evitar retroinformação acústica e/ou reduzir a SNR.

[108] Em vez de excluir diretamente o áudio para usuários/clientes remotos colocalizados, o gerador 403 pode, em vez disso, fornecer uma atenuação mais gradual do componente de áudio de outros usuários colocalizados.

[109] Assim, em muitas modalidades, o gerador 403 pode ser disposto de modo a gerar a mixagem para um primeiro cliente remoto em que a atenuação/ponderação de um componente de áudio de um segundo cliente remoto depende de os dados de proximidade indicarem que o segundo cliente remoto está próximo do primeiro cliente remoto.

[110] Em algumas modalidades, os dados de proximidade podem incluir um valor escalar indicativo da distância entre o primeiro e o segundo cliente remoto. O gerador 403 pode, em algumas dessas modalidades, ser disposto de modo a determinar a atenuação como uma função monotonicamente decrescente da distância, de modo que quanto mais próximo o segundo cliente remoto estiver do primeiro cliente remoto, menor será o peso/maior será a atenuação do componente de áudio. Se o segundo cliente remoto estiver muito próximo do primeiro cliente remoto, o primeiro cliente remoto pode, consequentemente, renderizar uma cena de áudio na qual o áudio do segundo cliente remoto é substancialmente atenuado. Isso pode refletir que, nessas situações, o usuário do primeiro cliente remoto poderá ouvir o usuário do segundo cliente remoto diretamente. No entanto, quanto mais distante estiver o segundo cliente remoto, mais alto será o áudio renderizado.

[111] Isso pode fornecer um desempenho particularmente atrativo em muitas modalidades. Por exemplo, em uma situação em que o aplicativo de audioconferência é usado por um grupo de pessoas dentre as quais algumas estão em um concerto em uma grande sala de concertos, o participante individual na sala de concertos pode receber uma apresentação de áudio personalizada, sendo que para outros participantes não presentes o áudio é renderizado em volume total, enquanto para os participantes muito próximos, o áudio é renderizado com volume muito baixo e para participantes na sala de concertos, mas em distâncias adicionais, o áudio é renderizado com volume intermediário. A abordagem pode, em muitas situações, fornecer um melhor equilíbrio entre o áudio recebido diretamente pela transmissão acústica no ambiente local e o áudio fornecido pelo aplicativo de conferência.

[112] Em algumas modalidades, o gerador 403 pode atenuar um componente de áudio se os dados de proximidade dos dois clientes remotos atenderem a um critério de proximidade. A atenuação pode ser feita por uma quantidade predeterminada que, em muitas modalidades, pode ser uma atenuação infinita (correspondente ao componente de áudio que não está sendo renderizado ou incluído na mixagem de áudio gerada).

[113] Em muitas modalidades, o critério de proximidade pode incluir um requisito de que uma indicação de proximidade para os dois clientes remotos deve indicar uma distância abaixo de um limite. Se a indicação de proximidade atender ao requisito, o gerador 403 pode continuar a não selecionar o componente de áudio correspondente para inclusão na mixagem de áudio gerada. O limiar pode ser definido como um valor “seguro” baixo que indica que não existe uma correlação substancial.

[114] A abordagem geralmente pode ser usada com indicações de proximidade binária que indicam se os pares de clientes remotos são considerados colocalizados/proximais ou não (por exemplo, na mesma sala). Nesse caso, o componente de áudio do outro cliente remoto não é incluído ao gerar sinais de áudio para o cliente remoto individual.

[115] Em algumas modalidades, o aparelho de áudio da Figura 4 pode ser implementado como parte do servidor de áudio 101. Em algumas modalidades, a mixagem de redução dos componentes/objetos de áudio de uma pluralidade de clientes remotos 103 em uma combinação de áudio composta por componentes de áudio de uma pluralidade de clientes remotos 103 pode ser feito no servidor de áudio 101. Em tais modalidades, os clientes remotos 103 transmitem dados de proximidade para o servidor de áudio 101, o qual podem usar isso na geração de mixes de áudio individuais para os clientes remotos 103. O servidor de áudio 101 pode gerar especificamente uma mixagem de áudio para cada um dos clientes remotos 103, mediante a combinação/mixagem de redução dos componentes de áudio recebidos dos clientes remotos 103 considerando os dados de proximidade. Como exemplo específico, o servidor de áudio 101 pode gerar mixagens de redução incluindo todos os componentes de áudio, exceto aqueles para os quais os dados de proximidade indicam que o cliente remoto correspondente está colocalizado no cliente remoto para o qual a mixagem de áudio é gerada.

[116] Em algumas modalidades, o aparelho de áudio da Figura 4 pode ser implementado como parte de um dos clientes remotos 103 e, na verdade, todos os clientes remotos podem incluir um aparelho de áudio desse tipo. Em algumas modalidades, a mixagem de redução dos componentes/objetos de áudio de uma pluralidade de clientes remotos 103 em uma mixagem de áudio combinada que compreende componentes de áudio de uma pluralidade de clientes remotos 103 pode ser realizada nos clientes remotos 103. Em tais modalidades, o servidor de áudio 101 pode transmitir tanto o componente de áudio quanto os dados de proximidade para os clientes remotos individuais 103, que podem então gerar localmente uma mixagem de áudio e renderizá- la para o usuário. Em algumas dessas modalidades, o servidor de áudio 101 pode receber os componentes de áudio dos diferentes clientes remotos 103 e encaminhar todos esses para os clientes remotos individuais 103. Além disso, o servidor de áudio 101 pode, em algumas modalidades, receber dados de proximidade dos clientes remotos 103 e distribuir esses dados de proximidade aos outros clientes remotos 103. Em outras modalidades, o servidor de áudio 101 pode receber os componentes de áudio dos diferentes clientes remotos 103 e, em seguida, gerar os dados de proximidade com base nos componentes de áudio. O cliente remoto individual pode, por exemplo, gerar uma mixagem de redução local, por exemplo incluindo todos os componentes de áudio, exceto aqueles para os quais os dados de proximidade indicam que o cliente remoto correspondente está colocalizado com o cliente remoto que está gerando a mixagem.

[117] Deve-se considerar que diferentes abordagens para se determinar os dados de proximidade poderão ser usadas em diferentes modalidades. Em muitas modalidades,

os dados de proximidade podem ser determinados especificamente ao se comparar os diferentes componentes de áudio entre si. O sistema pode incluir um detector de proximidade que determina uma indicação de proximidade para dois clientes remotos, mediante a comparação dos dois componentes de áudio dos dois clientes remotos um com o outro. Os dados de proximidade podem, por exemplo, ser gerados para refletir a semelhança entre esses sinais e, especificamente, uma medida de correlação cruzada pode ser gerada com a indicação de proximidade sendo gerada a partir dessa medida de correlação cruzada. Por exemplo, o valor de correlação cruzada pode ser usado diretamente ou, por exemplo, a indicação de proximidade pode ser definida para indicar que os dois clientes remotos são colocados no mesmo local se a medida de correlação cruzada máxima dentro de uma determinada faixa de atraso exceder um determinado limite. Um transmissor pode, então, gerar os dados de proximidade para incluir a indicação de proximidade e transmitir isso (tipicamente junto com o componente de áudio).

[118] Em modalidades em que o aparelho de áudio é implementado nos clientes remotos 103, um detector de proximidade pode ser implementado no servidor de áudio 101 que determina os valores de correlação cruzada para todos os pares de componentes de áudio e determina uma indicação de proximidade para cada par. Os dados de proximidade podem ser gerados para incluir todas as indicações de proximidade, e isso pode ser transmitido a todos os clientes remotos 103, ou, por exemplo, apenas os dados de proximidade para um determinado cliente remoto podem ser transmitidos para esse cliente remoto. Além disso, o servidor de áudio 101 pode transmitir os componentes de áudio e o cliente pode continuar a gerar localmente uma mixagem de áudio.

[119] Em modalidades onde o aparelho de áudio é implementado no servidor de áudio 101, um detector de proximidade pode ser implementado nos clientes remotos 103. Cada cliente remoto pode incluir um detector de proximidade que correlaciona, por exemplo, o componente de áudio local com componentes de áudio recebidos de outros clientes remotos 103. Uma indicação de proximidade pode ser gerada para cada um dos componentes de áudio recebidos e transmitida de volta para o servidor de áudio 101 juntamente com o componente de áudio local. O servidor de áudio 101 pode então usar esses dados de proximidade recebidos de todos os clientes remotos na geração de mixagens de áudio para os clientes remotos individuais 103.

[120] Assim, conforme ilustrado na Figura 5, uma primeira entidade 501 pode incluir um detector de proximidade 503 que determina valores de correlação cruzada para um ou mais pares de componentes de áudio e determina uma indicação de proximidade para cada par. Por exemplo, uma primeira entidade 501 pode compreender um detector de proximidade 503 que determina uma indicação de proximidade para um primeiro cliente remoto e um segundo cliente remoto em resposta a uma comparação de um primeiro componente de áudio para o primeiro cliente remoto e um segundo componente de áudio para um segundo cliente remoto. Ela compreende adicionalmente um transmissor de dados 505 que é disposto de modo a transmitir dados de proximidade que compreende a indicação de proximidade a uma segunda entidade 507 que compreende o aparelho de áudio da Figura 4. Além dos dados de proximidade, o transmissor 505 pode transmitir um ou mais componentes de áudio. O transmissor 505 pode, assim, transmitir especificamente dados de proximidade e dados de componente áudio para o receptor 401 do aparelho de áudio. Em algumas modalidades, a primeira entidade 501 pode ser um cliente remoto e a segunda entidade 507 pode ser o servidor de áudio. Em outras modalidades, a primeira entidade 501 pode ser o servidor de áudio e a segunda entidade 507 pode ser um cliente remoto.

[121] Assim, em muitas modalidades, o processamento de sinal dos componentes de áudio (por exemplo, correspondente aos sinais de microfone dos clientes remotos) no servidor de áudio 101 pode detectar quais usuários/clientes remotos são proximais (por exemplo, compartilhar uma sala), e os metadados correspondentes serão enviados aos clientes remotos 103.

[122] Se, por exemplo, uma matriz de correlação for gerada com valores máximos de correlação cruzada para todos os pares de componentes de áudio na matriz, os componentes de áudio para os clientes remotos 103 que estão na mesma sala (proximal) terão um valor máximo de correlação cruzada alto.

[123] Por exemplo, o servidor de áudio 101 pode calcular para cada combinação exclusiva e j, com ≠ : ∑ ∗ − ∙ , = , !∑ − ∙ − ∙∑ ∙ hist max max ∗ ∗ hist max hist max ∑ ∗ ∙ + % !∑ ∙∑ " ∙ + ∙ + hist max ∗ ∗ $ max hist max hist max

[124] onde indica o sinal do componente de áudio que o servidor recebeu do cliente remoto com o índice i, ‖ ‖=√ ∗ ∙ a norma, o índice de amostra para o componente de áudio (histórico do) com = 0 denotando a última amostra disponível, )hist o número de amostras anteriores usadas na análise e max o atraso máximo suportado entre os componentes de áudio.

[125] Por exemplo, *+, = -0,3 ∙ /0 1)2 03 = -20 ∙ /0 1 com /0 a taxa de amostragem dos sinais do microfone e -∙1 a operação de arredondamento para baixo. Um típico valor para a taxa de amostragem para fala é de 16 kHz. No caso de áudio, uma taxa de amostragem mais alta, por exemplo, 48 kHz, é frequentemente usada. Particularmente, para essa abordagem, o valor *+, de ser escolhido grande o suficiente para levar em conta atrasos entre os componentes de áudio devido a diferentes comprimentos de caminho acústico entre os usuários e os microfones (na mesma sala) e atrasam as diferenças na transmissão dos clientes remotos para o servidor de áudio 101.

[126] Se, para uma certa combinação e j, a correlação cruzada acima for alta, por exemplo , ≥ 0,3, os clientes remotos i e j podem ser considerados proximais, e especificamente na mesma sala. As correlações cruzadas podem ser baixas quando nenhum dos participantes estiver falando. Portanto, é vantajoso calcular a correlação cruzada somente quando um dos participantes i ou j estiver ativo.

[127] Como exemplo, determinar se o usuário k está ativo pode ser feito de acordo com: : ∗ ∙ 81 if 10 ∙ <=>? @ > H32IJ0 6 6

AB = 9 6 CDEF 8 70 caso contrário

[128] com, por exemplo, H32IJ0 = −30 dB, para sinais x com amplitude de escala completa F.

[129] Como alternativa, um detector de fala pode ser aplicado nos sinais.

[130] A determinação de se dois clientes remotos 103 estão proximais é tipicamente avaliada somente quando um dos usuários está ativo, e a última decisão determinada é mantida quando eles não estão ativos. Isso impede a alternância dos metadados dependendo se os alto-falantes estão ativos.

[131] Podem ser tomadas formas adicionais para garantir a robustez da decisão. Por exemplo, uma decisão sobre se os clientes remotos i e j estão na mesma sala só pode ser alterada quando pelo menos 15 segundos de sinal ativo K == 1 ou == 1L resultar em um sinal diferente.

[132] Em algumas modalidades, o servidor de áudio 101 determina quais clientes remotos estão na mesma sala e envia as informações como metadados aos clientes remotos 103. Em particular, essa modalidade é vantajosa quando os sinais de áudio dos usuários não são misturados no servidor de áudio 101 para cada cliente, mas enviados separadamente. Por exemplo, aplicativos de VR em que o sinal de cada usuário é renderizado para uma localização específica na realidade virtual (ou aumentada). Nesse caso, os clientes remotos podem usar os metadados dos quais outros usuários estão, por exemplo, na mesma sala para decidir não renderizar ou reproduzir os sinais correspondentes recebidos do servidor de conferência.

[133] Em algumas modalidades, o detector de proximidade pode, conforme mencionado, estar localizado no cliente remoto. Um exemplo de elementos de tal cliente remoto é ilustrado na Figura 6.

[134] O cliente remoto é composto por uma entrada 601 acoplada a um microfone e disposta de modo a gerar um sinal de microfone correspondente ao áudio capturado pelo microfone. O sinal do microfone é enviado para um codificador 603 que codifica o sinal para gerar o componente de áudio (em algumas apresentações, o sinal do microfone pode ser usado diretamente como componente de áudio).

[135] O codificador é acoplado a uma interface 605 que é disposta de modo a se comunicar com o servidor de áudio 101. A interface compreende, assim, um transmissor para transmitir dados para o servidor de áudio 101 e um receptor para receber dados do servidor de áudio 101. A interface 605 recebe os dados do componente de áudio e os transmite para o servidor de áudio 101.

[136] Além disso, a interface 605 recebe componentes de áudio e dados de proximidade de outros clientes remotos, e especificamente a interface 605 pode incluir o receptor 401 da Figura 4.

[137] O cliente remoto compreende ainda um renderizador de áudio 607 que pode corresponder diretamente ao gerador 403 da Figura 4. O gerador 403 pode, conforme descrito anteriormente, continuar a gerar uma mixagem local para apresentação ao usuário local.

[138] Em outras apresentações, o áudio recebido do servidor de áudio 101 pode ser um sinal com mixagem de redução, ou seja, o gerador 409 pode ser composto no servidor de áudio 101 e o áudio transmitido pode ser, por exemplo, um sinal estéreo binaural ou um sinal de som surround. O renderizador 607 pode, em tais modalidades, renderizar diretamente o sinal recebido.

[139] O cliente remoto da Figura 6 compreende adicionalmente um detector de proximidade 607 que é disposto de modo a determinar uma indicação de proximidade para o primeiro cliente remoto em resposta a uma comparação do sinal de microfone (possivelmente representado pelo componente de áudio) e áudio de entrada do servidor de áudio.

[140] Por exemplo, se o áudio recebido corresponder aos componentes de áudio de outros clientes remotos, eles podem ser diretamente alimentados ao detector de proximidade 609, que pode então prosseguir para correlacionar o sinal do microfone (possivelmente conforme representado pelo componente de áudio) com os componentes de áudio recebidos e gerar uma indicação de proximidade para cada um dos componentes de áudio recebidos. As indicações de proximidade podem ser alimentadas na interface 605, que pode transmitir dados de proximidade compreendendo as indicações de proximidade ao servidor de áudio 101.

[141] No caso de o áudio recebido corresponder a uma mixagem de áudio que compreende uma pluralidade de componentes de áudio de outros clientes remotos combinados/mixados no(s) mesmo(s) sinal(s) de áudio/canal(is), o detector de proximidade 609 pode correlacionar o sinal do microfone com a mixagem de áudio.

[142] Por exemplo, se a mixagem de áudio compreende apenas um único sinal, o detector de proximidade 609 pode correlacionar o sinal recebido com o sinal do microfone e, se uma correlação acima de um determinado nível for detectada, uma indicação de proximidade pode ser gerada para indicar que o cliente remoto atualmente ativo (para o alto-falante atualmente ativo) é proximal ao cliente remoto atual.

[143] Se a mixagem de áudio compreender mais de um canal/sinal, esses podem, por exemplo, ser combinados antes da correlação, ou correlações podem ser feitas para cada sinal de canal e, por exemplo, somente a maior correlação pode ser considerada.

[144] Se os casos em que a identidade do cliente/alto-falante remoto atualmente ativo for conhecida pelo cliente remoto (por exemplo, essa atividade pode ser detectada pelo servidor de áudio 101 e as informações correspondentes podem ser encaminhadas ao cliente remoto), o cliente remoto pode gerar uma indicação de proximidade que inclui essa identificação do outro cliente remoto como sendo proximal.

[145] Nos casos em que essas informações podem não estar disponíveis, o cliente remoto pode simplesmente transmitir uma indicação de proximidade indicando que o alto- falante/cliente remoto atualmente ativo é proximal. Nesse caso, o servidor de áudio 101 pode, por exemplo, ser disposto de modo a detectar o alto-falante atualmente ativo (por exemplo, com o uso de detecção de fala) e pode determinar a identidade apropriada do cliente remoto que é proximal ao cliente remoto transmitindo a indicação de proximidade como o alto-falante/cliente remoto ativo identificado atualmente.

[146] Assim, em algumas modalidades, os clientes remotos podem detectar clientes remotos proximais comparando os sinais recebidos do servidor de áudio 101 com o sinal do microfone local (por exemplo, após cancelamento de eco acústico (AEC)).

[147] Por exemplo, o cliente pode determinar a correlação cruzada entre os sinais recebidos do servidor e o sinal de microfone do cliente remoto: P∑ Q∗ − ∙ P = ,

CDEF MNO !∑ Q ∗ − ∙Q − ∙∑ ∗ ∙

MNO

CDEF MNO CDEF MNO ∑ Q∗ ∙ + CDEF MNO %Q !∑ ∙∑ " Q∗ ∙Q ∗ + ∙ +

MNO CDEF MNO CDEF MNO $

[148] denota um sinal recebido a partir do servidor de áudio, x o sinal do microfone local, ‖ ‖ = √ ∗ ∙ a norma, n o índice de amostra para os (históricos dos) sinais de microfone com = 0 denotando a última amostra disponível )2 03 o número de amostras anteriores usadas na análise e *+, atraso máximo suportado entre os sinais do microfone.

[149] Por exemplo, *+, = -2 ∙ /0 1)2 03 = -20 ∙ /0 1 com /0 a taxa de amostragem dos sinais do microfone e -∙1 a operação de arredondamento para baixo. Particularmente, para essa abordagem, o valor *+, ve ser grande o suficiente para levar em conta atrasos entre o sinal do microfone e os sinais recebidos do servidor de áudio devido a atrasos no sistema (distribuído) devido, por exemplo, à codificação, transmissão (do cliente para o servidor), processamento no servidor, transmissão (do servidor ao cliente), e decodificação e devido a diferentes comprimentos de caminho acústico entre os usuários e os microfones (na mesma sala).

[150] Se, para um determinado i, a correlação cruzada acima for alta, por exemplo, ≥ 0,2, o usuário RS S posso considerar estar na mesma sala (proximal).

[151] Como alternativa, o cliente pode usar o sinal do microfone antes que o AEC seja aplicado a ele. Ele pode se concentrar em atrasos maiores que, por exemplo, 15 ms para separar o retroinformação acústica entre o alto-falante e o microfone no cliente do atraso maior do sistema de conferência. O cliente também pode procurar os dois picos de correlação e fornecer o menor atraso para o AEC.

[152] Se um ou mais clientes enviarem mais de um componente de áudio, o algoritmo pode, por exemplo, selecionar o sinal de microfone mais alto para análise, calcular uma mixagem de redução de todos os sinais de microfone ou escolher um sinal de microfone específico.

[153] De modo similar, como na abordagem do lado do servidor, a correlação tipicamente só será calculada quando um usuário estiver falando e, mais especificamente, quando um alto-falante ativo estiver presente em um dos sinais recebidos do servidor.

[154] Os componentes/sinais de áudio Q recebidos do servidor de áudio 101 tipicamente representam (pelo menos parcialmente) outros usuários na chamada de conferência. Isso possibilita que o cliente remoto determine quais usuários estão na mesma sala com base em quais sinais têm altas correlações. Os sinais de alguns usuários podem não ser transmitidos porque estão sendo silenciados ou determinados como inativos pelo servidor de áudio.

[155] Como mencionado, em alguns sinais, os componentes de áudio podem ser combinados em uma mixagem de áudio no servidor de áudio 101. Quando os sinais Q representam uma mixagem de áudio, eles podem representar canais de áudio e alguns sinais dos usuários podem estar presentes em vários canais de áudio. A análise individual dos canais de áudio pode, portanto, nem sempre resultar em informações extras particularmente úteis. Portanto, pode ser vantajoso fazer uma mixagem de redução dos sinais e determinar a correlação do resultado com o sinal do microfone local. A mixagem de redução pode ser calculada por: 1 Q= @ QV #U* V∈XM

[156] em que U* é o conjunto de índices de sinais de entrada relacionados a um conjunto de sinais de áudio e U* é a cardinalidade do conjunto U* .

[157] O resultado dessa abordagem é uma menor complexidade computacional, que é vantajosa para reduzir o uso da CPU em geral e/ou melhorar a vida útil da bateria em dispositivos portáteis.

[158] Tal abordagem é particularmente vantajosa quando os sinais de todos os clientes são (pelo menos parcialmente) pré-mixados ou pré-renderizados no servidor, mas também pode ser aplicada para sinais que não são pré-mixados ou pré-renderizados.

[159] Em alguns casos, quando uma mixagem de áudio é recebida, pode não ser possível determinar diretamente quais usuários estão na mesma sala, pois pode não ser possível diferenciar diretamente entre os componentes de áudio de diferentes clientes remotos quando incorporados na mesma mixagem de áudio. No entanto, o cliente pode enviar metadados indicando que o usuário atualmente ativo está (provavelmente)

na mesma sala. O servidor de áudio 101 pode levar isso em consideração, por exemplo, não mixando ou pré-renderizando o sinal do usuário ativo no sinal que ele envia ao cliente que enviou os metadados, e vice-versa.

[160] Alguns aplicativos de conferência enviam informações dos participantes da chamada. Nesses casos, isso pode ser usado para determinar qual usuário está ativo no lado do cliente quando uma alta correlação cruzada é detectada, e o cliente remoto pode enviar essas informações para o servidor.

[161] O servidor pode pós-processar os metadados que recebe para melhorar a robustez. Por exemplo, vários usuários podem ser indicados como ativos simultaneamente, enquanto um terceiro cliente envia metadados indicando que o usuário atualmente ativo está na mesma sala. O servidor de áudio pode então combinar isso com informações desses outros dois usuários, em que um pode também indicar que o usuário atualmente ativo está na mesma sala. Então isso pode significar que todos os três estão na mesma sala. Como alternativa, ele pode sinalizar o mais alto dos usuários ativos da mesma sala ou aumentar um valor de probabilidade para ambos os usuários ativos. Quando o valor de probabilidade for maior que um determinado valor limite, o usuário correspondente poderá ser considerado na mesma sala. Alternativamente, pode reduzir o nível dos usuários na pré- mixagem em relação ao valor de probabilidade crescente.

[162] Métodos diferentes descritos acima podem ser combinados para clientes onde sinais pré-mixados e sinais individuais são recebidos e/ou quando as propriedades do sinal mudam com o tempo (por exemplo, devido à alteração da disponibilidade da largura de banda).

[163] De modo similar, quanto à abordagem do lado do servidor, a robustez pode ser melhorada dentro dos clientes que usam os mesmos métodos ou métodos similares.

[164] Em modalidades em que a correlação cruzada entre sinais é realizada, ela pode ser realizada nos sinais de domínio de tempo total, conforme descrito acima. Alternativamente, em algumas modalidades, a correlação pode ser realizada em uma representação de tempo-frequência (por exemplo, após o Filterbank de QMF (Filtro de espelho de Quadratura), STFT (transformação de Fourier de curto prazo) ou análise de MDCT ou FFT com janela). Nesses casos, cada soma nas equações de correlação acima se torna uma soma bidimensional ao longo de intervalos de tempo ou quadros na dimensão temporal (n) e faixas de frequência ou agrupamentos na dimensão espectral (b).

[165] em que / ,Y representa a função correspondente e/ou y na equação de correlação, com x e y tomando n como índice de domínio de tempo e b como índice de domínio de frequência. e o )2 03 respectivamente *+, termos de intervalos de tempo ou quadros. Por exemplo para um banco de arquivos QMF com um fator de redução de amostragem de 64, ou FFT com janela com tamanho de salto de 256 amostras Z= [∙\ a operação de arredondamento.

[166] Como outro exemplo, em algumas modalidades, a correlação cruzada pode ser aplicada no envelope, perfil de energia ou perfil de energia dependente da frequência dos sinais. Isso é vantajoso para obter uma menor complexidade computacional e pode ser vantajoso nos casos em que os sinais Q são reconstruídos parametricamente a partir de um número menor de sinais de mixagem de redução e, portanto, mais provavelmente têm alta correlação na estrutura fina local dos sinais reconstruídos. Alternativamente, no último caso, a correlação também poderia ser aplicada aos parâmetros de reconstrução.

[167] No caso de cálculos de correlação dependentes da frequência, algumas modalidades podem aplicar uma pesagem a certos compartimentos/bandas de frequência para enfatizar frequências típicas de fala.

[168] Um perfil de energia (dependente da frequência) pode ser calculado a partir dos sinais da seguinte forma:

[169] em que cada nova representação de frequência temporal do perfil de energia é a energia total de todos os tiles de frequência temporal na representação de sinal ,Y . As bandejas de início e de parada para o compartimento são indicadas por e respectivamente, e as faixas horárias de início e de parada são indicadas por e respectivamente. No caso de sinais puramente de domínio de tempo (por exemplo Sinal PCM) o índice b e a soma podem ser omitidos.

[170] Em algumas modalidades, outras abordagens para determinar a proximidade entre clientes remotos 103 podem ser usadas alternativa ou adicionalmente.

[171] Por exemplo, em algumas modalidades, as indicações de proximidade podem ser determinadas pela configuração manual direta, por exemplo, com o uso de uma interface de usuário dos clientes remotos individuais. Outras modalidades podem usar tecnologia de localização, como GPS, tecnologias de localização interna, endereços IP ou por meio de IDs de rede etc. em algumas modalidades, os clientes remotos 103 podem enviar esses dados para o servidor e este pode avaliar os dados recebidos para determinar quais clientes remotos 103 estão próximos um do outro.

[172] Por exemplo, endereços IP/MAC e/ou tempos de atraso da rede podem ser usados como indicação de clientes remotos estarem proximais. Por exemplo, o fato de os clientes remotos 103 compartilharem equipamentos de rede é indicativo de co-localização.

[173] Em algumas modalidades, a proximidade de dois clientes remotos pode ser detectada por meio da detecção de uma retroinformação acústica, caso em que o sistema pode prosseguir para evitar essa retroinformação acústica (por exemplo, alterando-se as características do laço para evitar retroinformação positiva).

[174] Um exemplo de um processo de teste que pode ser usado para detectar a proximidade mediante a detecção de retroinformação acústica pode começar com todos os microfones silenciados (ou com componentes de áudio não sendo realimentados aos clientes) para garantir que não haja atualmente nenhuma retroinformação acústica. Microfones de diferentes pares de clientes remotos podem então ser ligados e se isso resultar em uma retroinformação acústica, então o par correspondente de clientes remotos é considerado proximal. Essa abordagem pode interromper a chamada de conferência por algum tempo para permitir a detecção de retroinformação acústica em cada par de clientes.

[175] A detecção de retroinformação acústica pode ser feita de várias maneiras. Uma abordagem de baixa complexidade seria determinar se os níveis de vários clientes estão aumentando, ou se um ou mais microfones clientes fornecem um nível de aumento exponencial. Tendo em conta o atraso médio de ida e volta no sistema, isso pode mostrar que o aumento exponencial do nível de RMS é gradual com uma periodicidade semelhante ao atraso de ida e volta. Uma medida de nivelamento espectral (SFM) que também pode ser usada para detecção de retroinformação acústica é descrita em Devis Thomas, A. R. Jayan, Automated Suppression of Howling Noise Using Sinusoidal Model based Analysis/Synthesis, IEEE International Advance Computing Conference (IACC), ITM University, Gurgaon, India, páginas 761-765, 2014. Outras abordagens podem determinar semelhanças em vários sinais de microfone de diferentes clientes, como altas correlações entre espectros ou espectrogramas. Outro exemplo seria determinar a presença de recorte nos sinais do microfone.

[176] Outro exemplo de uma abordagem para detectar quais clientes estão, por exemplo, no mesmo local é adicionar um sinal de marcador ou marca d'água em cada componente de áudio do cliente. Esse marcador pode ser escolhido de modo que geralmente não seja perceptível por humanos e pode ser projetado de modo que possa ser detectado em um sinal de microfone apesar das distorções impostas pelo codec e caminho acústico usados.

[177] Por exemplo, o servidor pode inserir esses marcadores no áudio transmitido aos clientes. Frequentemente,

é benéfico se cada cliente receber um marcador exclusivo. Posteriormente, em algumas modalidades, o servidor pode analisar os sinais de microfone dos clientes recebidos para marcadores de outros clientes. Em outras modalidades, os clientes podem analisar seus próprios sinais de microfone e transmitir informações do marcador para o servidor. Essas informações do marcador podem ser um ID do marcador detectado ou elas podem ter mapeado o ID do marcador detectado para um cliente correspondente em resposta ao mapeamento de metadados recebidos do servidor.

[178] Nos exemplos descritos acima, a geração de uma mistura de áudio depende dos dados de proximidade. Entretanto, deve-se considerar que tais dados também podem ser usados para outros propósitos.

[179] Por exemplo, em algumas modalidades, os dados de proximidade podem ser usados para (por exemplo, espacialmente) agrupar os usuários de acordo com a forma como eles são agrupados fisicamente. Em algumas modalidades, por exemplo, AR, os dados de proximidade podem ser usados para determinar quais usuários não estão fisicamente presentes na sala e se um avatar virtual para o usuário pode ser apresentado. Em algumas modalidades, os dados de proximidade podem (além disso) ser usados para renderizar os sinais de usuários que não estão na sala física em locais que não estão sobrepostos aos usuários que estão.

[180] Em algumas modalidades, os metadados e/ou a análise do lado do cliente podem ser usados para sincronizar a reprodução nos diferentes dispositivos, de modo que a reprodução seja feita com pequenos atrasos mútuos.

[181] Em algumas modalidades, os dados de proximidade podem ser usados para não renderizar os sinais recebidos do servidor relacionados aos usuários na mesma sala, mas para usar alternativamente a captura local do microfone desses usuários para renderização. Isso pode ser vantajoso quando os usuários estão usando fones de ouvido que podem bloquear ou atenuar os caminhos acústicos. Mantendo-se o processamento local, o atraso do sistema de conferência pode ser eliminado, resultando em melhor sincronização labial.

[182] Em algumas apresentações, um primeiro cliente remoto pode transmitir um sinal de microfone ou componente de áudio gerado para um segundo cliente remoto detectado como colocado. A transmissão pode ser através de um enlace de dados direto (LAN/óptico/RF) e pode excluir especificamente o servidor de áudio 101. Isso pode fornecer um enlace/comunicação com atraso de transmissão reduzido. O segundo cliente remoto pode então usar esse sinal recebido diretamente para atenuar ou suprimir o sinal da fonte de áudio do primeiro cliente remoto. Essa abordagem pode ser uma alternativa ao uso do caminho acústico e se beneficia de uma transmissão mais rápida (devido à diferença na velocidade da luz e do som). Isso pode evitar um processamento de áudio desnecessariamente complexo ou propenso a erros, pois há uma “referência” de áudio limpa disponível no momento no segundo cliente remoto.

[183] Em algumas modalidades, esse enlace pode ser usado para sincronizar a reprodução da mistura de áudio entre os clientes remotos que estão na mesma sala. Como alternativa, esses metadados de sincronização são executados pelo servidor de áudio. Na maioria das modalidades, a sincronização levará em consideração o cliente colocalizado com a maior latência em relação aos dados recebidos do servidor e atrasará a reprodução da mixagem de áudio nos outros clientes colocalizados para sincronização. Esse processo de sincronização contínua é conhecido na técnica e pode ser obtido com o uso de protocolos de sincronização de tempo, como NTP (Network Time Protocol) ou PTP (Precision Time Protocol).

[184] Como mencionado anteriormente, a proximidade acústica pode ser diferente em uma direção de um primeiro cliente remoto para um segundo cliente remoto do que do segundo cliente remoto para o primeiro cliente remoto, refletindo que a função de transferência acústica pode ser diferente nas duas direções. Consequentemente, em muitas modalidades, os dados de proximidade podem incluir diferentes indicações de proximidade para um par de clientes remotos 103 dependendo da direção.

[185] Por exemplo, os dados de proximidade fornecidos pelo servidor de áudio 101 a um cliente remoto podem incluir dois valores para um determinado outro cliente remoto, e a mixagem de áudio local pode ser em resposta à indicação de proximidade do outro cliente remoto a este.

[186] O uso de indicações de proximidade assimétricas/direcionais pode fornecer um melhor desempenho em muitas modalidades, incluindo em situações específicas em que, por exemplo, um usuário usa fones de ouvido, enquanto o outro usa uma renderização de alto-falante.

[187] Em algumas modalidades, os dados de proximidade podem ser comunicados/distribuídos na inicialização de um serviço/aplicativo e esses dados de proximidade podem ser usados até o final. Por exemplo, quando uma nova sessão de conferência é inicializada, os dados de proximidade podem ser trocados e usados até o final da sessão.

[188] Entretanto, na maioria das modalidades práticas, o sistema pode ser organizado para determinar/adaptar/atualizar/distribuir dinamicamente pelo menos alguns dados de proximidade. Dessa forma, o receptor 401 é tipicamente disposto de modo a receber dados de proximidade ao adaptar dinamicamente a alterações nas posições dos clientes remotos.

[189] Especificamente, o(s) detector(es) de proximidade do servidor de áudio 101 e/ou os clientes remotos 103 podem correlacionar continuamente os sinais apropriados e determinar as indicações de proximidade com base nos resultados da correlação. O sistema pode então distribuir continuamente indicações de proximidade, por exemplo, transmitindo continuamente metadados que compreendem indicações de proximidade com a distribuição dos componentes de áudio.

[190] Em muitas modalidades, o sistema pode ser organizado para transmitir indicações de proximidade para (pelo menos) um primeiro par de clientes remotos com uma taxa de atualização de não mais que um minuto e, muitas vezes, não mais que 30 segundos.

[191] Essas atualizações dinâmicas podem fornecer um sistema eficiente e adaptável que pode se adaptar às mudanças nas posições do usuário. Por exemplo, em muitas modalidades, ele pode se adaptar rapidamente a um participante da conferência com uma conexão pelo telefone, entrando em uma sala de reunião onde outro cliente está. Por exemplo, muitas vezes, ele pode impedir que a retroinformação acústica ocorra quando o participante entra na sala de reuniões.

[192] Deve-se considerar que os dados de proximidade podem ser transmitidos como metadados de várias maneiras diferentes e que a abordagem específica usada pode depender das preferências e dos requisitos da modalidade individual.

[193] A estrutura, a sintaxe e o conteúdo exatos dos metadados dependerão da modalidade específica. Assim, os metadados podem ser configurados e transmitidos de várias formas e a abordagem preferida também pode depender do uso da detecção no lado do cliente ou da detecção no lado do servidor (ou de uma combinação).

[194] No caso de detecção do lado do servidor, os metadados são tipicamente enviados do servidor para um ou mais clientes. Os metadados podem conter informações de quais usuários/clientes estão no mesmo local. Por exemplo, uma indicação de índices ou nomes de clientes ou um mapa de bits pode ser usado. Parte da sintaxe dos fluxos de bits enviados pelo servidor aos clientes pode, por exemplo, ser a seguinte: Sintaxe N° de bits locSharing(usersSharingLoc[][], nrLocs, nrUsers, userNames[], preferredMethod) { preferredMethod; 2 nrLocs; 7 if (preferredMethod == LS_METH_INDICES || preferredMethod == LS_METH_NAMES) { for (loc = 0:nrLocs - 1) { for (uIdx = 0:nrUsers - 1) { if (usersSharingLoc[loc][uIdx] == 1) { if (preferredMethod == LS_METH_NAMES) { userNames[uIdx]; variável (0); 1 }

else { uIdx; 7 } } } (128); 8 } } else if (preferredMethod == LS_METH_BITMAP)) { nrUsers; 7 for (loc = 0:nrLocs - 1) { for (uIdx = 0:nrUsers - 1) { usersSharingLoc[loc][uIdx]; 1 } } } }

[195] Este exemplo mostra uma sintaxe que suporta três métodos diferentes para enviar os metadados aos clientes e escolhe um, dependendo de uma configuração preferida. Ele fornece a todos os clientes informações sobre quantos locais exclusivos (como alternativa, quantos locais com mais de 1 usuário) existem e quais usuários estão presentes em qual local.

[196] Como outro exemplo, os metadados relevantes só podem ser enviados aos usuários que compartilham um local. Isso é mostrado na sintaxe exemplificadora abaixo: Sintaxe N° de bits locSharingLimited(usersSharingLoc[][], nrLocs, nrUsers, userNames[], curUserLocIdx, preferredMethod) { preferredMethod; 2 if (preferredMethod == LS_METH_INDICES || preferredMethod == LS_METH_NAMES) { for (uIdx = 0:nrUsers - 1) { if (usersSharingLoc[curUserLocIdx][uIdx] == 1) { if (preferredMethod == LS_METH_NAMES)

{ userNames[uIdx]; variável (0); 1 } else { uIdx; 7 } } } (128); 8 } else if (preferredMethod == LS_METH_BITMAP)) { nrUsers; 7 for (loc = 0:nrLocs - 1) { for (uIdx = 0:nrUsers - 1) { usersSharingLoc[curUserLocIdx][uIdx]; 1 } } } }

[197] No caso de detecção no lado do cliente, os metadados são tipicamente enviados para o servidor e o servidor pode tipicamente enviar metadados com informações semelhantes ou derivadas para um ou mais clientes.

[198] O cliente, por exemplo, pode enviar um sinalizador que indica se, nesse momento, uma alta correlação é detectada entre o sinal de saída e o sinal do microfone (depois do AEC). Adicional ou alternativamente, ele pode enviar uma indicação do valor máximo de correlação.

[199] Em outras modalidades, o cliente também pode usar metadados indicando quais usuários estão ativos e pode transmitir dados indicando um ou mais usuários específicos que estão determinados no mesmo local. Isso pode ser feito com o uso de uma sintaxe semelhante à descrita acima.

[200] Adicionalmente, o cliente pode enviar metadados descrevendo com qual método foi detectado e/ou qual é o atraso entre a captura acústica direta e a alta correlação no sinal de áudio recebido do servidor de conferência.

[201] Uma sintaxe exemplificadora de dados enviados do cliente para o servidor é a seguinte: Sintaxe N° de bits locSharingClientAssessment() { currentActiveSpeakerInSameLoc; 1 if (furtherLocSharingData) 1 { detectionMethod; 3 maxCrossCorr; 6 } }

[202] Uma definição exemplificadora de metadados do método de detecção pode ser da seguinte forma: detectionMethod Descrição 0 Correlação de sinal PCM 1 Correlação do perfil de energia temporal 2 Correlação do perfil de energia dependente da frequência 3 Correlação de perfil de energia dependente da frequência ponderada 4 Localização interna 5 Configuração manual 6 <Reservado> 7 <Reservado>

[203] Em resposta a metadados semelhantes de um ou mais clientes, o servidor pode enviar metadados semelhantes aos descritos acima. O servidor pode agrupar as informações recebidas de vários clientes. Para isso, ele pode combinar todas as indicações de compartilhamento de localização. Se, por exemplo, os clientes A e B indicarem que estão no mesmo local que o usuário D e o cliente D indicar um local compartilhado com os usuários A e C, o servidor poderá indicar que os usuários A, B, C e D estão no mesmo local.

[204] Alternativamente, isso pode indicar que os usuários A e D estão no mesmo local, pois eles indicaram mutuamente um local compartilhado.

[205] Deve-se considerar que, para maior clareza, a descrição acima descreveu as modalidades da invenção com referência a diferentes circuitos, unidades e processadores funcionais. Entretanto, ficará evidente que qualquer distribuição adequada de funcionalidade entre os diferentes circuitos, unidades ou processadores funcionais pode ser usada sem se desviar da invenção. Por exemplo, a funcionalidade ilustrada a ser executada por processadores ou controladores separados pode ser executada pelo mesmo processador ou pelos mesmos controladores. Por isso, as referências a unidades ou circuitos funcionais específicos devem ser consideradas apenas como referências a meios adequados para fornecer a funcionalidade descrita e não como indicativas de uma estrutura ou organização lógica ou física estrita.

[206] A invenção pode ser implementada em qualquer forma adequada, incluindo hardware, software, firmware ou qualquer combinação dos mesmos. A invenção pode, opcionalmente, ser implementada ao menos parcialmente como software de computador que é executado em um ou mais processadores de dados e/ou processadores de sinal digital. Os elementos e componentes de uma modalidade da invenção podem ser física, funcional e logicamente implementados de qualquer forma adequada. De fato, a funcionalidade pode ser implementada em uma única unidade, em uma pluralidade de unidades ou como parte de outras unidades funcionais. Assim, a invenção pode ser implementada em uma unidade única ou pode ser distribuída física e funcionalmente entre diferentes unidades, circuitos e processadores.

[207] Embora a presente invenção tenha sido descrita em conexão com algumas modalidades, não se pretende limitá-la à forma específica aqui apresentada. Ao invés disso, o escopo da presente invenção é limitado apenas pelas reivindicações em anexo. Adicionalmente, embora possa parecer que um recurso é descrito em conexão com modalidades específicas, o versado na técnica reconhecerá que vários recursos das modalidades descritas podem ser combinados de acordo com a invenção. Nas reivindicações, o termo “que compreende” não exclui a presença de outros elementos ou outras etapas.

[208] Além disso, embora individualmente mencionados, uma pluralidade de meios, elementos, circuitos ou etapas de métodos podem ser implementados, por exemplo, por meio de um único circuito, uma única unidade ou um único processador. Adicionalmente, embora recursos individuais possam estar incluídos em reivindicações diferentes, eles podem ser vantajosamente combinados, e sua inclusão em reivindicações diferentes não implica que uma combinação de recursos não seja viável e/ou vantajosa. Além disso, a inclusão de um recurso em uma categoria de reivindicações não implica na limitação a tal categoria, mas, ao invés disso, indica que o recurso é igualmente aplicável a outras categorias das reivindicações, conforme for adequado. Além disso, a ordem dos recursos nas reivindicações não implica em nenhuma ordem específica na qual os recursos precisam ser trabalhados e, em particular, a ordem das etapas individuais em uma reivindicação de método não implica que as etapas precisam ser executadas nessa ordem. As etapas podem, na verdade, ser executadas em qualquer ordem adequada. Além disso,

referências no singular não excluem uma pluralidade.

Dessa forma, as referências a “um(a)”, “uns/umas”, “primeiro(a)”, “segundo(a)” etc., não excluem uma pluralidade.

Os sinais de referência nas reivindicações são fornecidos meramente como exemplos esclarecedores e não devem ser interpretados como limitadores do escopo das reivindicações de forma alguma.

Claims (14)

REIVINDICAÇÕES

1. APARELHO DE ÁUDIO PARA UM SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO QUE COMPREENDE UM SERVIDOR DE ÁUDIO (101) PARA RECEBER ÁUDIO DE ENTRADA DE UMA PLURALIDADE DE CLIENTES REMOTOS (103)

E PARA TRANSMITIR ÁUDIO DERIVADO DO ÁUDIO DE ENTRADA PARA PELO ALGUNS DENTRE A PLURALIDADE DE CLIENTES REMOTOS (103); sendo o aparelho caracterizado por compreender: um receptor (401) para receber dados que compreendem: dados de áudio para uma pluralidade de componentes de áudio, sendo que cada componente de áudio representa o áudio de um cliente remoto dentre a pluralidade de clientes remotos; dados de proximidade para pelo menos um dos componentes de áudio, sendo que os dados de proximidade são indicativos da proximidade física entre clientes remotos em um ambiente acústico do mundo real; e um gerador (403) para gerar uma mixagem de áudio dentre a pluralidade de componentes de áudio em resposta aos dados de proximidade; sendo que o gerador (403) é disposto para gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

2. APARELHO DE ÁUDIO, de acordo com a reivindicação 1, caracterizado por o gerador (403) ser disposto de modo a atenuar o segundo componente de áudio na primeira mixagem de áudio para os dados de proximidade que atendem a um critério de proximidade para o primeiro cliente remoto e o segundo cliente remoto.

3. APARELHO DE ÁUDIO, de acordo com qualquer uma das reivindicações anteriores, sendo o aparelho de áudio caracterizado por fazer parte do servidor de áudio (101).

4. APARELHO DE ÁUDIO, de acordo com qualquer uma das reivindicações anteriores 1 ou 2, sendo o aparelho de áudio caracterizado por fazer parte de um cliente remoto dentre a pluralidade de clientes remotos (103).

5. APARELHO DE ÁUDIO, de acordo com qualquer uma das reivindicações anteriores, caracterizado por os dados de proximidade compreenderem uma indicação de proximidade escalar para pelo menos um primeiro cliente remoto e um segundo cliente remoto, sendo que a indicação de proximidade escalar é indicativa de uma atenuação acústica de uma fonte de áudio do segundo cliente remoto para um elemento de captura do primeiro cliente remoto.

6. APARELHO DE ÁUDIO, de acordo com qualquer uma das reivindicações anteriores, caracterizado por os dados de proximidade compreenderem uma indicação de proximidade de um primeiro cliente remoto para um segundo cliente remoto diferente da proximidade do segundo cliente remoto para o primeiro cliente remoto.

7. APARELHO DE ÁUDIO, de acordo a reivindicação 1, caracterizado por o receptor (401) ser disposto de modo a receber dados de proximidade que se adaptam dinamicamente às alterações nas posições de pelo menos um dentre a pluralidade de clientes remotos (103).

8. SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, caracterizado por compreender:

uma pluralidade de clientes remotos (103); um servidor de áudio (101) para receber áudio de entrada da pluralidade de clientes remotos (103) e para transmitir áudio derivado do áudio de entrada para pelo menos um dentre a pluralidade de clientes remotos (103); sendo que pelo menos um dentre o servidor de áudio e um dentre a pluralidade de clientes remotos (103) compreende: um receptor (401) para receber dados que compreendem: dados de áudio para uma pluralidade de componentes de áudio, sendo que cada componente de áudio representa o áudio de um cliente remoto dentre a pluralidade de clientes remotos; dados de proximidade para pelo menos um dos componentes de áudio, sendo que os dados de proximidade são indicativos da proximidade física entre clientes remotos em um ambiente acústico do mundo real; e um gerador (403) para gerar uma mixagem de áudio dentre a pluralidade de componentes de áudio em resposta aos dados de proximidade; sendo que o gerador (403) é disposto para gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

9. SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, de acordo com a reivindicação 8, sendo o sistema de distribuição de áudio caracterizado por compreender um detector de proximidade (503, 609) disposto de modo a determinar uma indicação de proximidade para um primeiro cliente remoto e um segundo cliente remoto em resposta a uma comparação de um primeiro componente de áudio para o primeiro cliente remoto e um segundo componente de áudio para um segundo cliente remoto; e um transmissor (505) para transmitir dados de proximidade compreendendo a indicação de proximidade ao receptor (401).

10. SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, de acordo com a reivindicação 9, caracterizado por o detector de proximidade (503) fazer parte do servidor de áudio (101).

11. SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, de acordo com a reivindicação 8, caracterizado por um primeiro cliente remoto dentre a pluralidade de clientes remotos compreender: uma entrada (601) para gerar um sinal de microfone correspondente ao áudio capturado por um conjunto de microfones; um detector de proximidade (609) disposto de modo a determinar uma indicação de proximidade para o primeiro cliente remoto em resposta a uma comparação do sinal do microfone e do áudio recebido do servidor de áudio (101); e um transmissor (605) para transmitir dados de áudio acústicos que compreendem a indicação de proximidade ao servidor de áudio (101).

12. SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO, de acordo com a reivindicação 11, caracterizado por o transmissor (605) ser disposto de modo a transmitir dados de proximidade que são indicativos de um cliente remoto atualmente ativo que é determinado como proximal em resposta ao primeiro detector de proximidade que detecta uma alta correlação entre o sinal do microfone e o áudio recebido do servidor de áudio.

13. MÉTODO DE OPERAÇÃO DE UM APARELHO DE ÁUDIO PARA

UM SISTEMA DE DISTRIBUIÇÃO DE ÁUDIO QUE COMPREENDE UM SERVIDOR DE ÁUDIO (101) PARA RECEBER ÁUDIO DE ENTRADA A PARTIR DE UMA

PLURALIDADE DE CLIENTES REMOTOS (103) E PARA TRANSMITIR ÁUDIO

DERIVADO DO ÁUDIO DE ENTRADA PARA PELO MENOS ALGUNS DENTRE A PLURALIDADE DE CLIENTES REMOTOS (103); sendo o método caracterizado por compreender: receber dados que compreendem: dados de áudio para uma pluralidade de componentes de áudio, sendo que cada componente de áudio representa o áudio de um cliente remoto dentre a pluralidade de clientes remotos; dados de proximidade para pelo menos um dos componentes de áudio, sendo que os dados de proximidade são indicativos da proximidade física entre clientes remotos em um ambiente acústico do mundo real; e um gerador (403) para gerar uma mixagem de áudio dentre a pluralidade de componentes de áudio em resposta aos dados de proximidade; sendo que a geração compreende gerar uma primeira mixagem de áudio para um primeiro cliente remoto dentre a pluralidade de clientes remotos, sendo que a geração da primeira mixagem de áudio inclui a determinação de uma atenuação na primeira mixagem de áudio de um segundo componente de áudio para um segundo cliente remoto em resposta aos dados de proximidade.

14. PRODUTO DE PROGRAMA DE COMPUTADOR, caracterizado por compreender meios de código de programa de computador adaptados para executar todas as etapas conforme definido na reivindicação 13, quando o dito programa é executado em um computador.