- Triforce é um beamformer adaptativo baseado em Rust para aproveitar o conjunto de microfones de notebooks Apple Silicon também fora do macOS
- O suporte é limitado ao MacBook Air/Pro 13" M1/M2, MacBook Air 15" M2 e MacBook Pro 14"/16" M1/M2 Pro/Max
- Os arranjos de microfones triangulares ou lineares desses dispositivos são sensíveis demais e omnidirecionais sem beamforming, dificultando a separação do sinal desejado
- A estrutura busca minimizar as dependências, exigindo apenas LV2 além dos crates especificados no Cargo.lock
- A implementação atual dificilmente deve superar a da Apple e, por não haver SIMD/NEON, não oferece suporte a decomposição de banda larga nem saída estéreo
Beamformer para conjuntos de microfones Apple Silicon
- Triforce implementa um beamformer adaptativo Minimum Variance Distortionless Response para os conjuntos de microfones de notebooks Apple Silicon
- Os dispositivos compatíveis são os seguintes
- MacBook Pro 13" (M1/M2)
- MacBook Air 13" (M1/M2)
- MacBook Pro 14" (M1 Pro/Max, M2 Pro/Max)
- MacBook Pro 16" (M1 Pro/Max, M2 Pro/Max)
- MacBook Air 15" (M2)
- Os conjuntos de microfones dos notebooks-alvo são dispostos em formato triangular ou linear
- Quando usados sem beamforming, esses arranjos são sensíveis demais e funcionam de forma omnidirecional, o que reduz sua utilidade; para aproveitá-los fora do macOS, é necessário um beamformer
- Além dos crates especificados no Cargo.lock, a dependência adicional necessária é LV2
Estado da implementação e limitações conhecidas
- Como é difícil encontrar literatura acessível sobre DSP e beamforming adaptativo de banda larga, a implementação atual é uma tentativa baseada em matemática de engenharia de nível de primeiro ano de graduação e em princípios obtidos de várias páginas da web e PDFs
- É difícil esperar que ela tenha desempenho melhor que a implementação da Apple, e patches de melhoria são bem-vindos
- As limitações conhecidas são as seguintes
- nalgebra não faz otimizações SIMD explícitas e depende da vetorização automática do LLVM, o que prejudica o desempenho e a eficiência das rotinas de matemática matricial
- Sem suporte a SIMD/NEON, ele é lento demais para um plugin de áudio em tempo real, portanto não realiza decomposição de banda larga
- A saída oferece suporte apenas a mono, e o processamento matricial adicional para uma saída estéreo falsa tem custo computacional alto demais
- Segundo as estatísticas do crates.io, o total de downloads é de 4.247, e há 7 versões publicadas
1 comentários
Opiniões do Hacker News
O post do blog com o contexto está aqui: https://asahilinux.org/2025/03/progress-report-6-14/#is-this...
Um Toshiba Tablet PC conversível que eu usava há mais de 20 anos tinha um arranjo de microfones para beamforming e vinha com software para especificar de onde gravar o som
O principal uso era gravar aulas, e dava para apontar o feixe para a direção do professor, atrás do notebook, e configurar para gravar só o som daquele lado
Era uma ideia incrível, mas nunca mais vi isso depois
Também era uma ótima ideia, e ainda existem produtos parecidos: https://electronics.sony.com/imaging/imaging-accessories/all...
O arranjo de microfones da sala de reunião identifica quem está falando e isola o áudio dessa pessoa
Videoconferência em salas grandes há muito tempo escolhe dinamicamente o microfone mais alto para não misturar ruído de vários microfones; com beamforming, isso fica muito melhor
Se os microfones ficavam no plano da tela, e não no corpo do aparelho, acho que não conseguiriam distinguir “na frente” de “logo atrás”
Poderia haver vários bons usos, como um carro autônomo “ver” um pedestre atrás de arbustos, detectar mais cedo um veículo de emergência se aproximando e ouvir uma bicicleta antes de ela aparecer
Sempre fiquei curioso sobre como implementaram
Minha dissertação de mestrado, que nunca consegui concluir, era sobre um tema parecido
Eu tentava usar o fato de que quase todos os smartphones têm pelo menos 2 microfones para fazer estimativa de posição em 3D e separação de falantes
As lições aprendidas foram estas: as taxas de amostragem entre dispositivos divergem um pouco, em torno de ±1 amostra por segundo, o que não é muito, mas precisa ser levado em conta
As características espectrais de microfones de consumo variam bastante; mesmo dois celulares do mesmo modelo recém-tirados da caixa apresentam diferenças mensuráveis e até audíveis
O som reflete em todo tipo de lugar, especialmente em paredes de concreto
Entre os lugares de fácil acesso, o interior de um carro é o que mais se aproxima de uma câmara anecoica
A transformada de Fourier de uma gaussiana é uma gaussiana, então isso é muito útil ao estimar frequências de sinais harmônicos como voz, quando o comprimento de onda é um pouco menor que metade do tamanho da janela
Não havia nada para refletir além do chão, e ele talvez tenha colocado espuma embaixo do experimento
Claro que isso não elimina o ruído ambiente, mas dizem que funcionou muito bem para reduzir reflexões vindas do próprio equipamento
Dá para sentir quanto trabalho é necessário até nas partes que parecem triviais para fazer o Linux rodar em um Mac com Apple Silicon
Aqui, “trivial” é dito com o máximo respeito. Quase não uso o microfone embutido, a menos que esqueça o headset
Citando o relatório de progresso (https://asahilinux.org/2025/03/progress-report-6-14/#is-this...): “Ainda assim, é Apple. Nada é simples”
Um headset com microfone wraparound em uma haste separada talvez seja melhor, mas fones comuns têm limitações por causa da posição do microfone
O microfone do MBP tinha até uma boa redução de ruído, então era preferível à maioria dos microfones boom de headsets
Também tem a vantagem de captar menos sons indesejados perto da boca, como mastigar chiclete ou tomar café
Tenho a impressão de que 99% das pessoas em reuniões usam a combinação de fones comuns com o microfone do MBP
O principal problema dessa configuração é que você não consegue ouvir a própria voz nos fones, o que às vezes pode incomodar bastante ao usar fones com cancelamento de ruído
Mas a Apple há algum tempo também vem se afastando dos caminhos que ela mesma abriu
O ponto central é que tudo que a Apple faz é verticalmente integrado
Para oferecer recursos como AirDrop ou Continuity, ela implementa atravessando toda a pilha
Se você escolhe o caminho DIY — que é basicamente o que o Asahi busca — também precisa criar as peças de software que faltam
A vantagem é que o ecossistema inteiro pode se beneficiar desse trabalho. Um exemplo é o novo DSP do PipeWire
O hardware de PC em geral é meio ruim, e o hardware da Apple também é assim se você remover esses componentes extras
Mas o “pacote completo” elevou bastante o padrão, e eu gostaria de ver o ecossistema livre e open source alcançar esse nível
Alguns dos primeiros MacBook Pro Retina tinham apenas um arranjo de 2 microfones, mas a maioria tem o arranjo completo de 3 microfones
Caso contrário, ele cai para um modo de codec de bitrate muito baixo e muito antigo, o que deixa até a entrada de áudio que você ouve horrível
Por isso, sempre que possível, uso o microfone do Mac
Mesmo em hardware de notebook barato — e, claro, também em hardware de ponta como um MBP — é possível obter resultados surpreendentemente bons com técnicas de DSP em software.
Gosto do fato de que boa parte do trabalho de áudio do Asahi se aplica diretamente não só aos Macs, mas também a notebooks comuns.
Já estou usando em um notebook HP barato o plugin de síntese de harmônicos de graves Bankstown e o equalizador de convolução desenvolvidos para o Asahi, e o resultado é impressionante.
Isso também usa o recurso de carregamento automático de cadeias de plugins do PipeWire, desenvolvido para o Asahi.
Acho que este beamformer também terá bastante uso fora do ecossistema Asahi.
Sobre otimização SIMD, seria bom os autores darem uma olhada no faer.
A biblioteca de base, pulp, pessoalmente não me deu uma experiência muito boa ao tentar fazer coisas além do escopo de álgebra linear, mas, se o objetivo for principalmente acelerar operações de álgebra linear, parece se encaixar bem.
Estou preparando um post de blog e um podcast relacionado sobre Rust SIMD, e pretendo abordar isso lá.
[1]: https://docs.rs/faer/latest/faer/
Repositório no GitHub: https://github.com/chadmed/triforce
Ao dizer “os arranjos de microfones nos seguintes notebooks Apple Silicon” e listar MacBook Pro 13" M1/M2, MacBook Air 13" M1/M2, MacBook Pro 14" M1 Pro/Max·M2 Pro/Max, MacBook Pro 16" M1 Pro/Max·M2 Pro/Max e MacBook Air 15" M2, fico curioso se isso quer dizer que o M2/M3 não têm arranjos de microfones parecidos ou se apenas não foram testados.
Também fico curioso se isso é suportado só no Linux.
Não sei bem se seria possível no macOS, nem se a Apple fornece streams dedicados para cada microfone.
O macOS faz internamente cálculos de beamforming muito semelhantes e expõe ao usuário apenas um microfone unificado.
Como o M3 ainda não é suportado pelo Asahi Linux, o fato de ele não estar na lista é uma questão separada de saber se o M3 tem esses microfones.
O macOS tem seu próprio software para lidar com isso em camadas profundas do sistema e o expõe aos aplicativos apenas como um microfone comum.
Há uma discussão mais geral no relatório de progresso mais recente do Asahi Linux.
“Infelizmente, microfones PDM são muito omnidirecionais e muito sensíveis. Não dá para conviver com eles sem algum tipo de beamforming.”
https://asahilinux.org/2025/03/progress-report-6-14/
Também ficou claro que parte do trabalho feito anteriormente para a saída dos alto-falantes foi reutilizada na entrada do microfone.
“Graças à base que já tínhamos montado no PipeWire e no WirePlumber para o suporte aos alto-falantes, conectar cadeias de DSP, incluindo o Triforce, ao microfone foi realmente simples. Bastou atualizar os arquivos de configuração e deixar o WirePlumber cuidar do resto!”
Sobre a frase “assim como nos alto-falantes, a Apple também tenta ser sofisticada demais aqui”, seria muito interessante se o autor deste pacote desse sua opinião.
Tenho curiosidade especialmente sobre o que ele pensa da implementação dos alto-falantes.
O que é excessivamente complexo? O hardware ou o software?
Como usuário de MBP e alguém que lida com áudio por hobby, achei a implementação dos alto-falantes, especialmente nos modelos maiores de MBP, realmente impressionante.
Mas sou apenas um amador e não sei muito além da configuração com tweeters e woofers duplos opostos.
Parece que a Apple também usa truques como equalização adaptativa, do tipo que projetistas de “bons” alto-falantes Bluetooth usam para extrair desempenho decente e extensão de graves de alto-falantes pequenos.
Um dos problemas é que, para limitar o uso de energia e evitar superaquecimento, é necessário DSP sofisticado.
Sem isso, o volume que se consegue atingir dentro dos limites de segurança fica muito restrito.
Se quiser saber mais, este provavelmente é o melhor panorama: https://github.com/AsahiLinux/asahi-audio
Isso tem sido verdade há várias gerações.
Quando eu usava um MBP de 2014, vários amigos ficavam surpresos com o som ao assistir filmes em viagem.
O M4 MBP é igual: a qualidade dos alto-falantes é, na prática, quase mais do que o necessário.
Hoje em dia, pelo menos em hardware premium, “áudio espacial” nos alto-falantes e microfones com beamforming começam a parecer padrão.
Áudio abafado, ruidoso, apertado e desequilibrado já não convence.