Porque há uma negligência no compartilhamento de tela com áudio no Linux?

Observação: TÃO; NL; é abreviação para “textão, não vou ler”, ou tradução de TL; DR;

Introduzindo…

TÃO; NL;

A problemática aqui é: porquê o Linux não compartilha áudio com a tela, enquanto MacOS e Windows permitem isso?

É consenso que compartilhar janela com áudio no Linux não deveria rolar do jeito que rola. Ou você cria um loopback maneiro que nem isso aqui, ou você não transmite áudio.

Transmitir abas de navegadores Chromium com som já é possível (não uso Firefox então me digam se também funciona por lá), mas só dentro do próprio navegador. As vezes acho isso insuficiente, visto que jogos “top das galáxias” não rodam em navegador, mas no próprio sistema operacional, em uma janela que não é a do navegador.

O ponto agora é: porque o que eu falei no primeiro parágrafo, infelizmente é verdade? Mastigando um pouquinho minha pergunta: porque compartilhar janela no Linux não compartilha áudio também?

Contexto

TÃO; NL;
  1. Dá pra compartilhar tela no macOS e no Windows
  2. No Linux, infelizmente tudo foi tardio, porém, isso vem melhorando com o tempo.
  3. Tem menos de 10 pessoas trabalhando no pulseaudio e no ALSA, somando.

Desde quase sempre se compartilha tela com áudio no Windows. No macOS uma atualização do Discord no ano passado permite fazer isso até então. Agora, e o Linux?

Nosso personagem favorito, carismático e por vezes engraçado e ator de filmes Xenia, a raposinha camarada Tux, por mais que seja um pinguim cantor de Toy Story, áudio no Linux é algo que muitos reclamam, e dizem que pouco é feito. Não vou discutir isso porque eu não sei os perrengues que os desenvolvedores do ALSA e do pulseaudio passam, fora que as coisas são tardias no Linux por padrão (ALSA é de 1998 e pulseaudio é de 2004, sendo em mais ou menos 1991 que o Windows ganhou áudio) e só estão ganhando reconhecimento agora com empresas que se importam em ajudar a gente (exemplo: Valve :heart: )

Algo que me intriga é que os desenvolvedores principais do pulseaudio são 3, e do ALSA são 6. Menos de 10 pessoas desenvolvendo o sistema de áudio de mais larga escala em sistemas Linux. Nem a Microsoft deve ter essa quantidade minúscula de gente trabalhando no WASAPI. E não estou reclamando, porque o pulseaudio e o ALSA funcionam bem.

Mas não é esse o detalhe. O detalhe é algo bem acima, bora polemizar o assunto?

Rádio Diolinux Plus, quadro Polêmica com Inky1003

Desenvolvedores do Chromium já disseram que não planejam criar suporte para compartilhamento de tela com áudio desde 2015 no Linux, proposto inicialmente em 2013. Como Electron é Chromium, fora as outras 500 aplicações que usamos e são Chromium, Discord, Teams, todos os navegadores (quase) e muitos outros não vão ter isso por um bom tempo. Ao que parece a tecnologia do pulseaudio não era tão maturada, e/ou o pulseaudio era tão pesado que acabou causando um problema de delay e qualidade na transmissão e desistiram de fazer.

Como mencionei aqui, o pulseaudio tem sim capacidade de ajudar no compartilhamento de tela, redirecionando o áudio. Ainda mencionei também o Soundux, “soundpad” pra Linux que não desconfigura o sistema de som com novos módulos só para tocar seu som de “pare” do “programa do ratinhonho”. Ele consegue enviar o som diretamente para o input de áudio do aplicativo, pegando os programas que estão gravando sources do pulseaudio e só criando uma null-sink que não desconfigura absolutamente nada, e só serve para pegar os dois áudios e redirecionar para o input. Isso já dá uma brecha pra dizer que dá pra fazer o contrário e obter o áudio do programa pelo output do app no pulseaudio.

Tá, beleza, mas eu não falei um programa que consegue fazer isso. Mas aí é que tá, existe: o Zoom faz isso. Eu não queria usá-lo de exemplo porque ele faz gambiarra e não é baseado em Chromium, mas se ele consegue, porque o Chromium não poderia fazer melhor?

Conclusão

Terei de terminar o artigo por aqui, tanto pra não ficar longo, quanto porque eu tenho outras coisas pra fazer, mas deixo uma pergunta aqui…

É negligência ou falta de ajuda na implementação?

O Zoom conseguiu, o Soundux dá um incentivo. O Chromium daqui a pouco já vai ter a faca e o queijo na mão, o que falta agora?

4 curtidas

Não sei se vc apontou o problema de compartilhamento de tela com áudio no geral ou especificamente no Chromium, li o texto mas ficou bem confuso pra ser sincero. No Chrome acho q da pra fazer isso, mas salvo engano precisa estar usando pipeware como servidor de áudio.

Basicamente porque foge de escopo, o Chromium não deveria fazer isso em sistema nenhum, isso é tecnicamente, explorar uma vulnerabilidade grave de segurança. Então fazer isso de forma segura pelo Chromium exigiria uma tecnologia inexistente até então, agora com Pipewire talvez isso mude

Não dá, é propaganda enganosa do pipewire.

Qual? Estou desatualizado, é uma brecha de segurança mesmo? Ou você acha que é uma?

Aí eu n sei confirmar. Vi a galera do pipeware falando. Como ainda n uso distro com ese servidor de audio n posso confirmar. Mas a galera do fedora pode dizer se dá ou não.

eu quero entender uma coisa
vc se refere a audio interno? ou áudio em geral?

Não entendi sua pergunta… eu tou falando, no geral, do pulseaudio.

vou exemplificar:
vc esta em uma vídeo chamada com seus amigos e vc quer mostra um vídeo que vc tem guardado em seus arquivos pessoais, vc compartilha a tela o vídeo vai mais o áudio do vídeo não, ou seja o áudio interno do reprodutor de vídeo não é compartilhado.

É disso que eu falo, o detalhe é: isso só funciona (manda áudio) quando você compartilha a aba com o vídeo em si, ou quando vc faz loopback do áudio da janela. Eu costumo fazer loopback.

Foi com o soundux que eu descobri que isso na verdade pode ser resolvido com uma API que funciona, e claramente pode ter sido uma negligência.

E é por isso que eu acho que nosso amigo Natanael se enganou um pouco. Eu vi o código-fonte do negócio e vi funções que são chamadas direto da API C do Pulseaudio. Não tem nada de gambiarra no Soundux, ele apenas pega os módulos de cliente de som e redireciona o áudio pra eles. Não tem nada de falha de segurança. Ou talvez tenha algo que eu não percebi?

O linux desde 2009 vem “sandboxando” as coisas mas não chegou no áudio ainda mas chegou na tela, basicamente qualquer projeto capaz de gravar áudio grava o áudio do sistema todo (no modelo proposto) e isso é problemático, isso significa capturar por exemplo os áudios que vc escuta no Telegram e Whatsapp por exemplo e ao contrário da tela, não existe um mecanismo de sandbox ou permissões como no Windows ou mesmo na captura de tela, o app que escolhe se quer pedir permissão ou não, agora imagina qualquer app Electron podendo escutar todo o seu sistema e mais em qualquer sistema, o spyware semiperfeito? Note que o Chromium suporta gravar áudio no microfone daí as chamadas, com microfone tem permissões nativas

2 curtidas

O Android mesmo ganhou esse recurso a pouco tempo

No caso do Discord, o client foi feito em Electron, que tem origem no Chromium. Isso permite que a interface possa ser escrita em HTML e CSS ao invéz de precisar aprender um toolkit super complicado para ter o mesmo resultado, sendo que é só usar o mesmo do web app com alterações mínimas. É uma bênção para quem está cuidando do frontend do Discord.

Mas o Discord não é só frontend. Eles também possuem uma API própria que é realmente o que cuida de tudo no Discord e nem é necessário o client oficial em Electron como frontend para usar o Discord, da mesma forma como o Telegram possue clients alternativos. A diferença é que a equipe do Discord proíbe o uso de clients alternativos ou modificados nos Termos de Serviço deles, então não é necessáriamente uma limitação do Chromium o motivo do Discord não partilhar áudio de aplicações. É falta de interesse na plataforma para implementar algo do tipo por aqui, ainda mais com soluções existentes para quem pesquisar no Google sobre como partilhar o áudio no Discord.

Talvez a parte de portals e sandboxing para partilhamento de áudio de aplicações não esteja perfeita mas isso nunca impediu que tela, aplicações e áudio fossem compartilhados pelo Discord no Windows sem aparecer uma janela pedindo permissão. No X11, o mesmo acontece. Se direcionar o áudio pelo JACK ou PulseAudio é tão fácil assim, preciando apenas interagir com esses servidores de áudio, o quê impede a API do Discord de fazer o mesmo? A questão de sandboxing são outros 500s.

O problema é de tudo um pouco, a infra de áudio do Linux é uma área que se tornou confusa ao longo dos anos, OSS, ALSA, Pulse, Jack, e agora PipeWire para unir tudo isso.

Nenhuma das grandes como SUSE, RH ou Canonical deu muita atenção para essa área ao longo dos anos, mas antes tarde do que nunca, a RH decidiu tomar alguma atitude e iniciou um projeto para unificar tudo em uma única coisa.

Eu acho que as coisas estão começando a entrar nos eixos lentamente com PipeWire, mas vamos ter de ter paciência, a ideia do projeto é evoluir de forma responsável, sem sair quebrando tudo, pensando sériamente nos casos de uso e tal.

Passando pra lembrar

Isso não é compartilhamento de janela com áudio! Isso é compartilhamento de vídeo com áudio redirecionado para microfone.

Como falei no artigo, ainda não existe portal para isso, mas a boa notícia é que já estão trabalhando nisso…