Bem, na verdade, muitos usuários do fórum em que estou costumam se comunicar em ambientes externos, e entrar com o microfone ligado diretamente pode fazer com que o ruído ambiente interfira na comunicação. E há outro bug: mesmo que você clique para silenciar o microfone na página de voz, o microfone continua aberto na prática, e é preciso desligá-lo e ligá-lo novamente para fechá-lo de verdade.
Em comparação com o Jitsi, há algumas diferenças, pois o Jitsi possui uma interface que permite escolher silenciar ou ativar o microfone antes de entrar oficialmente no chat de voz, mas o Discourse Voice não tem isso. Acho que essa interface evita em grande parte o problema.
Ah, entendi. Esses usuários se beneficiariam do PTT (push-to-talk)? Temos suporte básico para isso, mas uma experiência de PTT melhor, tanto no mobile quanto no desktop, requer um aplicativo nativo, e essa é uma área em que estamos ativamente explorando soluções.
Você por acaso teve alguma outra sugestão? Tentei convidar meu outro usuário de demonstração e, infelizmente, ainda não está funcionando. Vocês conseguiram convidar usuários com sucesso por meio de um link?
Atualização: Acabei de enviar um convite para um novo quarto a um administrador, e ele ainda recebeu uma página 404.
@putty é possível que este seja um problema com seu nome de usuário no site. A rota na sua gravação de tela termina com /invited-by/derek.putnam, e a rota para isso atualmente rejeita pontos em nomes de usuário. Isso deve corrigir o problema:
Você também pode testar no seu site compartilhando o link sem a parte /invited-by/....
Estivamos usando isso durante o fim de semana com bons resultados Um bug / recurso inesperado que encontramos é que o sistema suporta microfones estéreo. Normalmente, em softwares de conferência pela web, os canais esquerdo e direito são convertidos para mono, já que o hardware de microfone mono é tipicamente usado para capturar esse tipo de áudio. (Isso também reduz teoricamente o uso de largura de banda). A solução do Discourse atualmente transmite microfones estéreo completos.
No entanto, alguns microfones só enviam áudio para um canal e deixam o outro vazio. (Talvez isso seja mais comum em interfaces de áudio prosumer com múltiplas entradas, mas imagino que alguns microfones baratos também possam acabar fazendo isso). Isso resulta em os ouvintes ouvirem aquele participante apenas no ouvido esquerdo ou direito. Na verdade, eu não percebi isso, mas aparentemente o Mumble, Discord, Nextcloud, Jitsi, jogos, etc., todos convertem para mono.
Portanto, recomendo que o padrão seja converter o fluxo de áudio do microfone (não o fluxo de áudio da compartilhamento de tela, que deve ser um conjunto de canais separado) para mono. De modo geral, provavelmente há poucas situações em que o usuário realmente gostaria de um campo de visão amplo para capturar áudio durante uma chamada — talvez se uma banda de música estivesse usando para transmitir para seus fãs, por exemplo. Nesse caso, se o usuário possui especificamente e deseja usar um microfone estéreo de campo amplo, deixe-o ativá-lo nas configurações, o que desativaria a conversão para mono.
Obrigado pelas informações, vou tentar da próxima vez, mas seria mais ideal se pudéssemos alternar isso separadamente, sem precisar reduzir a taxa de bits.
Estamos usando as salas de voz há algumas semanas, com tamanhos de grupo limitados (máx. 5 pessoas). Até agora, tudo está funcionando bem — parabéns! Gostaria que o backend técnico fosse separado do aplicativo web e do banco de dados do Discourse. Existe alguma boa documentação sobre como configurar um servidor Livekit com Docker Compose (antes de perguntar ao Claude )?
Na configuração padrão e na configuração do LiveKit, o Discourse ainda lida com a mesma quantidade de responsabilidades. O Mesh é uma boa opção padrão, e se ele funciona para você, recomendo mantê-lo até que você precise de algo mais avançado.
Obrigado, @Falco - ainda melhor se não precisarmos mudar nada. Nesse caso, vou abrir o recurso para todas as comunidades na nossa instância, mas limitado a 5 pessoas por sala. Para a maioria das reuniões improvisadas, isso é mais do que suficiente.
Uma observação sobre privacidade: No futuro (talvez em uma etapa posterior do projeto “Sala de voz”), precisaremos de uma solução documentada para total conformidade com o GDPR: Atualmente, stun.l.google.com e global.stun.twilio.com são os padrões. Ambos são baseados nos EUA e, portanto, devem seguir o US Cloud Act, o que conflita com a jurisdição europeia.
O anúncio do OP lista “salas públicas, restritas a grupos e privadas” nas permissões de sala, mas não consigo encontrar onde configurar a restrição por grupo em uma sala.
Meu caso de uso: uma sala visível e acessível apenas para membros de um grupo específico, basicamente como uma Categoria. As configurações voice_allowed_groups e voice_create_room_allowed_groups são globais para o site, então não atendem ao que preciso aqui.
No editor de sala, só vejo a alternância de Público e o Gerenciar membros por usuário.
A restrição por grupo em cada sala está implementada? Se sim, onde fica a configuração? Se não, há planos para isso? Ficarei feliz em testar.
Para muitas das minhas comunidades, Categoria, Chat e Voice seriam recursos que um Grupo gostaria de ter para uso exclusivo, portanto, poder controlar o acesso a eles por Grupo está no topo da minha lista.
Como você mencionou, o @mcwumbly tem um plano no roadmap para uma nova interface e um padrão para controlar o acesso a recursos como salas de chat e salas de voz. Isso vai acontecer, mas ainda não está pronto.