Microfone de arranjo em fases (2023)
(benwang.dev)- O microfone de arranjo em fases de 192 canais permite mudar a direcionalidade mesmo após a gravação ou focalizar simultaneamente centenas de milhares de pontos, possibilitando estimativa e visualização da posição da fonte sonora que seriam difíceis com microfones direcionais comuns
- O hardware é composto por braços radiais de microfone e um hub central, usando 192 microfones MEMS, uma placa FPGA Colorlight i5 e uma estrutura de transmissão por Gigabit Ethernet por cerca de US$ 700
- A FPGA se concentra em transmitir dados PDM brutos em vez de pré-processamento complexo, lidando com entrada de 3.125MHz e usando cerca de 70% da banda de Gigabit Ethernet, em aproximadamente 715Mbps
- O software combina filtro CIC, calibração baseada em FFT, otimização em GPU e beamforming com Triton para visualizar em tempo real a posição de fontes sonoras 3D em campo próximo e 2D em campo distante
- Pacotes UDP podem ser capturados com
tcpdumpe reproduzidos, mas o armazenamento bruto chega a 87.5MB/s, exigindo 315GB para 1 hora de gravação
Configuração do microfone de arranjo em fases de 192 canais
- Combina um microfone de arranjo em fases de 192 canais com aquisição de dados por FPGA e beamforming/visualização baseados em GPU
- Ao contrário de um microfone direcional comum, o arranjo em fases permite mudar a direcionalidade mesmo depois da gravação e focalizar simultaneamente dezenas de milhares de pontos em tempo real
- Todo o projeto foi publicado como código aberto
Projeto de hardware
-
Estrutura do arranjo e custo
- O arranjo em fases é formado pela distribuição de vários microfones com espaçamento amplo
- Em arranjos lineares, sabe-se que o espaçamento exponencial entre microfones é ideal para sinais de banda larga
- No arranjo 2D, braços de arranjo linear simétrico são dispostos radialmente para manter pequena a placa hub central
- O custo total do arranjo é de cerca de US$ 700
-
Placas dos braços
- O comprimento de cada braço foi ajustado aos limites de fabricação e montagem de PCB, e o comprimento máximo de fabricação/montagem de PCB de 4 camadas da JLCPCB era de 570mm
- Os microfones usados são MEMS com saída digital de baixo custo, a cerca de US$ 0,5 por unidade
- Nessa faixa de preço, a diferença de desempenho entre microfones não é grande
- A maioria apresenta desempenho aceitável até 10kHz, mas atraso de fase e correspondência de volume não são especificados
- Os microfones enviam dados no formato PDM (pulse density modulation)
- Produzem saída de 1 bit em frequências de até 4MHz, muito acima da faixa audível
- O alto índice de amostragem compensa o ruído de quantização
- Suportam DDR, que faz latch dos dados nas bordas de subida e descida do clock, permitindo multiplexar dois microfones em uma mesma linha
- Cada braço tem 8 microfones e 4 linhas de saída, com buffers de saída na linha de entrada de clock
- O projeto garante tempos de subida razoáveis mesmo com centenas de microfones compartilhando o mesmo sinal de clock
- O rendimento das PCBs dos braços não foi bom, e apenas cerca de 50% das placas funcionaram logo de início
- A falha mais comum era curto da linha de clock com 3V3 ou GND
- Corrigir o curto exigia tentativa e erro, removendo os microfones um por um
- Alguns microfones continuaram gerando dados incorretos mesmo após retrabalho, e o código faz masking deles para excluí-los
- No próximo projeto, resistores seriais na linha de clock, melhor panelização e um stencil de pasta de solda melhor podem reduzir o retrabalho
-
Placa hub
- Para aquisição de dados foi usada uma FPGA, por exigir muitas I/Os de baixa latência e uma interface rápida como Gigabit Ethernet
- Foi escolhida especificamente a placa Colorlight i5
- Pelas I/Os suficientes, baixo custo, facilidade de encontrar e dois PHYs Ethernet integrados
- Neste projeto, apenas um PHY Ethernet é usado
- Essa placa era originalmente uma interface Ethernet para painéis de LED, mas foi completamente revertida por engenharia reversa
- Cerca de 100 GPIOs são expostos por um conector DDR2, o que facilita mais o fanout do que no BGA original da FPGA
- Além da FPGA, o hub inclui um circuito simples de gerenciamento de energia, conectores para as placas dos braços e um conector Ethernet com magnetics integrados
-
Projeto mecânico
- Os braços são presos ao hub com espaçadores/porcas de montagem em PCB e parafusos M3
- A conexão entre braços e hub é feita por um conector de 8 pinos com passo de 2mm
- O projeto inicial encaixava ranhuras na PCB dos braços com uma PCB estrutural circular, mas a baixa rigidez torsional dos braços fazia toda a estrutura deformar facilmente
- No projeto final, uma peça de MDF de 1/4 de polegada cortada a laser foi colocada na periferia do arranjo, e cada braço foi preso ao MDF com abraçadeiras plásticas
- Como o arranjo de microfones é montado na parede e vulnerável a reflexões, foram usadas espumas de absorção acústica para reduzi-las e facilitar a calibração
Gateware da FPGA
-
Objetivos do projeto
- O principal objetivo do gateware é transmitir com confiabilidade para o computador os dados brutos coletados, sem perdas
- Decimação e filtragem na FPGA poderiam reduzir a taxa de dados, mas os dados PDM brutos também podem ser transmitidos por Gigabit Ethernet
- Enviar dados brutos reduz a complexidade do código da FPGA e acelera o desenvolvimento iterativo
- Compilar código é mais rápido do que placement-and-routing, e usar um depurador em código comum é mais fácil do que depurar gateware
-
Interface PDM
- O módulo de entrada PDM divide o clock de sistema de 50MHz por 16 para gerar um clock PDM de 3.125MHz
- Após cada borda de clock, faz latch de 96 pinos de entrada e desloca 32 bits de dados a cada ciclo de clock
- Um cabeçalho inteiro incremental de 32 bits é anexado a cada bloco de 192 bits de dados
- A taxa de dados de entrada da interface PDM é 3.125MHz × 96 pinos de entrada × DDR 2 = 600Mbps
- A taxa de saída com cabeçalho é de 700Mbps, e a utilização do caminho de dados de saída de 32 bits é de cerca de 40%
-
Empacotamento e transmissão UDP
- O módulo de empacotamento é próximo de um buffer FIFO com interface de entrada especial
- Como a interface Ethernet é mais rápida que a saída PDM, emitir assim que houver um item, como em um FIFO padrão, pode gerar pacotes menores do que o solicitado
- O módulo de empacotamento espera até que haja dados suficientes para um pacote inteiro na fila antes de iniciar a transmissão, garantindo pacotes de tamanho fixo
- Cada pacote contém 48 blocos de saída PDM de 224 bits
- Cada bloco é composto por 192 bits de dados e um cabeçalho de 32 bits
- Os dados por pacote somam 1344 bytes
- São adicionados 20 bytes de cabeçalho IPv4 e 8 bytes de cabeçalho UDP
- A taxa de pacotes é de cerca de 65kpps, resultando em taxa de linha de 715Mbps e uso de aproximadamente 70% da Gigabit Ethernet
- O streaming UDP usa LiteEth
- Ele abstrai complexidades de baixo nível, como encapsulamento UDP/IP e tabela ARP
- Fornece uma interface fácil para conectar um FIFO a um fluxo UDP
- Latências ocasionais são absorvidas pela folga de buffer do FIFO de empacotamento
-
Uso de recursos da FPGA
- A FPGA da Colorlight i5 é a
LFE5U-25F-6BG381Ce tem 25k LUT - O projeto foi colocado e roteado com o toolchain open source Project Trellis
- Como o gateware foi mantido simples, o uso de recursos é baixo e ainda há bastante espaço para recursos adicionais
- DP16KD: 16/56, 28%
- TRELLIS_FF: 1950/24288, 8%
- TRELLIS_COMB: 3701/24288, 15%
- O clock máximo passou em 73.17MHz para uma meta de 50MHz
- O aviso de temporização do clock Ethernet RX é um falso positivo relacionado ao gray counter do LiteEth
- A FPGA da Colorlight i5 é a
Pipeline de processamento de software
-
Filtro CIC
- Cada microfone gera um sinal de 1 bit a 3.125MHz, que precisa ser reduzido para menor taxa de amostragem e profundidade de bits para o processamento seguinte
- Para isso foi usado um filtro CIC, que exige poucas operações aritméticas
- Foi usada como referência a série Moving Average and CIC Filters, de Tom Verbeure
- A escolha final foi um filtro CIC de 4 estágios com decimação de 16x
- Reduz a taxa de amostragem para 195kHz
- A saída é de 32 bits
- Para aceitar dados a 3.125MHz, cada lote de amostras precisa ser processado em 320ns
- Uma implementação simples em Rust não era rápida o bastante em um único núcleo, e a versão final reduziu abstrações para favorecer melhor auto-vetorização
- Uma implementação com intrinsics SIMD era muito mais rápida, mas apresentou problemas de alinhamento quando usada junto com outros códigos
- Resultados de benchmark:
bench_cic: 574ns/iter, 41MB/sbench_fast_cic: 181ns/iter, 132MB/sbench_simd_cic: 36ns/iter, 666MB/s
-
Calibração
- A calibração do arranjo foi feita movendo um alto-falante reproduzindo ruído branco em uma sala à frente do arranjo
- Foi calculada a correlação cruzada baseada em FFT entre todos os pares de microfones para obter atrasos relativos
- Como há mais de 18.000 pares de microfones, o custo computacional é alto
- Com janelas de 16k a 64k, a FFT fica limitada por memória, então IFFT e busca de pico foram combinadas para evitar escrever resultados na memória, obtendo ganho de velocidade de 15x
- Em um Ryzen 7950X, esse processo roda em tempo real
- Depois, a posição da fonte sonora em cada instante e a posição de cada microfone são otimizadas por descida de gradiente
- A função de perda reduz a diferença entre a correlação medida e a correlação ideal
- Garante que as posições dos microfones não se afastem demais da posição inicial
- Também reduz o jerk da trajetória da fonte sonora
- A velocidade do som também entra como parâmetro de otimização na calibração, fazendo o procedimento inteiro funcionar como um termômetro excessivamente complicado
- Após centenas de iterações, constantes como posição da fonte sonora, posição dos microfones e velocidade do som convergem para soluções razoáveis
- Esse problema se adapta bem à vetorização em GPU e converge em poucos segundos
- O erro médio final de posição fica em torno de 1mm
- Distorções sistemáticas de grande escala, como concavidade causada por falta de rigidez estrutural, também são corrigidas
- O erro máximo entre a posição de projeto e a posição calibrada é de cerca de 5mm
- O comprimento de onda de um som de 10kHz é de cerca de 3,4cm, então, sem calibração, podem surgir erros de fase significativos em altas frequências
Beamforming e visualização
-
Método de beamforming
- Beamforming é o processo de tratar as entradas brutas dos microfones para criar uma resposta direcional
- O método implementado é o mais simples: delay-and-sum, ou DAS
- Cada sinal é atrasado de acordo com a diferença de distância até a fonte sonora e então somado
- Neste projeto, o beamforming é feito no domínio da frequência
- Nesse domínio, o atraso é implementado por um termo de fase linear proporcional ao atraso necessário e pela multiplicação complexa do sinal
- Atrasos que não sejam múltiplos inteiros do período de amostragem também são tratados naturalmente
- Vários subarranjos sobrepostos do arranjo original são usados conforme a faixa de frequência
- Não é necessário fazer beamforming com todos os microfones em todas as frequências, o que reduz a carga de processamento e também ajuda a igualar o ganho de beamforming em todas as frequências
-
Implementação em GPU com Triton
- O beamformer foi implementado como kernel em Triton
- Triton é uma DSL em Python compilada para rodar em GPUs Nvidia
- Ao fazer beamforming para centenas de milhares de pontos, o paralelismo massivo da GPU torna possíveis resultados em tempo real
- O desempenho fica um pouco abaixo do ideal por uma limitação atual no suporte da linguagem Triton à indexação de arrays em memória compartilhada, mas escrever em CUDA C++ não foi escolhido
-
Beamforming 3D em campo próximo
- O beamforming 3D em campo próximo é feito em uma grade de voxels de 5cm
- O tamanho da grade é 64×64×64
- Em uma RTX 4090, a taxa de atualização alcançada é de 12Hz
- Velocidades maiores são limitadas pelo overhead não ideal de sincronização CPU-GPU em unidades de trabalho pequenas
- A grade de voxels é visualizada com a biblioteca de visualização de alto desempenho baseada em OpenGL VisPy
- Renderizar 250 mil voxels semitransparentes não é problema para taxas de quadros interativas, em comparação com a quantidade de polígonos em jogos modernos
-
Beamforming 2D em campo distante
- Para fontes sonoras distantes, a frente de onda é quase plana, então o quão longe a fonte está não altera de forma significativa os sinais recebidos pelo arranjo
- Fontes próximas têm maior curvatura da frente de onda, o que permite determinar a posição 3D
- Como o beamforming em campo distante não tem dimensão de profundidade, ele pode ser feito com resolução mais alta
- É usada uma grade de 512×512 pixels, atingindo igualmente 12Hz de atualização
- O beamforming em campo distante usa uma aproximação em que os pontos são colocados longe, em vez de uma hipótese estrita de onda plana
- Como há muitas reflexões e multicaminho em ambientes internos, a demonstração de visualização 2D é afetada pelo ambiente acústico
-
Áudio direcional
- As duas implementações anteriores de beamforming calculam a energia sonora em cada posição, mas não produzem em memória o áudio beamformado em si
- Para gravação de áudio direcional, foi implementado um beamformer delay-and-sum no domínio do tempo
- Ele recebe coordenadas 3D em relação ao centro do arranjo
- Ele produz amostras de áudio
- Esse beamformer é diferenciável em relação à posição na saída
- Assim, a posição de uma fonte de áudio pode ser otimizada com uma função de perda diferenciável
- Isso pode permitir aplicações como encontrar a posição física de cada locutor em uma transcrição multiorador usando um modelo de alinhamento forçado
- Para comparar o efeito, um alto-falante reproduz áudio à frente do arranjo, enquanto outro reproduz ruído branco à mesma distância, a cerca de 45 graus do centro do arranjo
- A comparação entre o áudio bruto de um único microfone e o áudio beamformado mostra o efeito do beamforming
Forma de gravação e limitações
- Como os dados do arranjo de microfones são pacotes UDP, eles podem ser gravados com ferramentas como
tcpdump - Arquivos de captura de pacotes podem ser lidos e seus pacotes reinjetados no listener
- Os programas anteriores foram projetados para operar em tempo real, mas também funcionam com dados gravados dessa forma
- A desvantagem é armazenar os dados brutos sem alteração, o que resulta em taxa de saída muito alta
- Inclui fielmente até o ruído de quantização
- A taxa de dados é de 87.5MB/s
- Uma hora de gravação exige 315GB
- Uma implementação mais otimizada poderia aplicar compressão ou gravar em menor taxa de amostragem após o filtro CIC
Possíveis extensões
- O projeto está, na prática, concluído, e não há planos de continuar trabalhando nele no futuro próximo
- Ainda assim, há espaço para expansão para quem quiser construir algo parecido
- Uso de algoritmos de beamforming mais avançados, como DAMAS
- Uma GUI melhor que combine os recursos existentes, como ver de onde vem o som e gravar áudio naquela posição
- Também é possível combinar beamforming diferenciável com modelos de rede neural, por exemplo em aplicações como o caso de alinhamento forçado
1 comentários
Opiniões no Hacker News
É interessante que, durante o processo de calibração, a velocidade do som também seja um parâmetro otimizado para obter o melhor modelo do sistema, de modo que o procedimento inteiro funciona como um termômetro absurdamente superprojetado
Isso me lembra o ditado da eletrônica: “todo sensor é um sensor de temperatura, e alguns também medem outras coisas”
Descobri que, com esse método, também dava para medir temperatura e extrapolar o gráfico para encontrar o zero absoluto
Pelo que lembro, o resultado ficou cerca de 20 K distante, mas, para um projeto de garagem de um estudante do ensino médio, acho que foi bem excelente
Gosto especialmente do exemplo de que uma unidade de medição inercial (IMU) suficientemente precisa consegue até medir longitude com relativa precisão usando o efeito Coriolis
https://youtu.be/zsA3X40nz9w?si=oGg2wdUlLXSDxpsN
Antigamente fiz um projeto de multilateração de morcegos usando uma matriz de 4 microfones disposta no chão em um grande formato de Y
Usando as diferenças de tempo de chegada aos quatro microfones, era possível localizar cada morcego que voava sobre a matriz e também identificar a espécie
Foi usado em um estudo para determinar o impacto ambiental da instalação de turbinas eólicas, e foi bem divertido
Era um dispositivo desenvolvido para rastrear e matar mosquitos com pulsos curtos de laser
Como era preciso determinar com precisão a posição espacial do mosquito, ele acabou também conseguindo detectar diferenças na frequência do bater de asas e distinguir alvos por sexo e espécie
Naturalmente, minha habilidade com hardware e software era limitada, então implementei o algoritmo de TDOA na forma mais ingênua e o método de estimar a diferença de tempo por correlação cruzada também era muito ineficiente
Ainda assim aprendi muito e, no fim, isso levou a um doutorado em sistemas SAR
Vejo SAR, na prática, mais como um beamformer que usa o movimento da plataforma em vez de uma matriz
Já ouvi dizer que os pulmões dos morcegos são tão sensíveis que, quando eles voam atravessando a diferença de pressão de grandes turbinas, os capilares basicamente se rompem
Seria bom ter algum material de referência sobre por onde começar
Eles colocaram uma matriz de microfones sob um escorpião e mostraram como um morcego movia seu feixe ultrassônico para escanear o escorpião
O resultado foi realmente impressionante [0]
[0]: https://www.youtube.com/watch?v=57ScSPWhGqU
Fico me perguntando por que usaram PDM na matriz em vez de microfones I2S com TDM
O ICS-52000 é relativamente barato, na faixa de 2 dólares em lotes de 100 unidades, há breakout boards com 4 microfones e, pelo que entendo, é possível encadear até 8 ou 16 deles
https://www.cdiweb.com/datasheets/notwired/ds-nw-aud-ics5200...
Usando um Jetson ou um hardware com DSP/GPU que suporte I2S, dá para encadear 16 microfones por porta I2S, então parece muito mais fácil de montar e programar do que uma configuração com FPGA
Com 192 microfones, a diferença entre US$ 2 por unidade e US$ 0,50 por unidade fica bem grande
Mesmo com uma daisy chain de 16, é difícil encontrar um dispositivo com interfaces I2S suficientes, e a maioria dos dispositivos não tem a quantidade necessária
O FPGA e o hardware customizado também faziam parte da diversão
Para ouvir o chiado de gás vazando ou a descarga corona de um arco elétrico, frequências mais altas são úteis
O Orin tem internamente 6 portas I2S, então 16*6 = 96 microfones parece possível, e é um número bastante bom
Mas, na prática, parece que só 3 delas saem para fora da placa e ficam em conectores diferentes da placa de desenvolvimento [1]
Em projetos, o problema está sempre nos detalhes; se você precisar de mais de 96, talvez um FPGA seja mais fácil de configurar
As peças que eu tinha anotado eram ICS-52000 US$ 3,50 20 kHz, ICS-41350 US$ 1,05 40 kHz, SPH0641LU4H-1 US$ 1,45 80 kHz+
[1] https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide...
Há cerca de dois motivos pelos quais I2S não é a melhor opção
I2S precisa de 3 pinos em vez dos 2 pinos do PDM
Porém, se for possível fazer daisy chain dos microfones como no datasheet que você forneceu, isso é bem interessante e, mesmo não sendo I2S padrão, esse argumento deixa de existir
PDM permite acessar taxas de amostragem muito mais altas, o que dá mais flexibilidade para escolher atrasos na operação de delay-and-sum
Por exemplo, se o clock PDM for de 2 MHz, em teoria dá para aplicar atrasos com precisão de 0,5 µs
Na prática, você provavelmente usaria uma precisão menor, mas o clock I2S normalmente fica no máximo por volta de 192 kHz
Microfones PDM também são mais baratos
Ao procurar por câmeras acústicas no YouTube, há algumas demonstrações bem impressionantes mostrando o desempenho.
Uma das empresas que acompanhei por um tempo é esta, e parece que empresas grandes como a FLIR também estão entrando nisso: https://www.youtube.com/@gfaitechgmbh
Um caso de uso interessante, mas assustador, é gravar um espaço público e depois dar “zoom” em uma conversa entre pessoas específicas.
Conversando com um amigo que usa implante coclear, parece que, com o processamento de sinais adequado, isso poderia ajudar bastante na audição.
Queria voltar a ser pós-graduando e tentar aplicações médicas combinando isso com um arranjo de alto-falantes ultrassônicos.
Essencialmente, seria como HIFU (ultrassom focalizado de alta intensidade) superpotente com feedback em tempo real.
https://en.wikipedia.org/wiki/Focused_ultrasound
As frequências são muito mais altas, então é preciso pensar em algo na faixa de 1–10 MHz, não 40 kHz, e circuitos eletrônicos comuns praticamente não servem.
Se quiser conversar, pode entrar em contato pelo e-mail no perfil.
Seria ótimo ver essa tecnologia chegar a vários dispositivos móveis em uma forma bem empacotada.
Acho que um dos motivos pelos quais assistentes e tradutores universais ainda esbarram em limitações é a má qualidade do áudio.
Reduzir ruído e detectar direção tem potencial para ajudar muito.
Por exemplo, eu gostaria de traduzir em tempo real uma conversa em grupo ao redor de uma mesa de jantar.
Para começar, seria bom se celulares e fones de ouvido pudessem combinar seus microfones para esse tipo de uso.
Indo além, imagine se todos os celulares próximos pudessem cooperar para fornecer áudio direcional de alta qualidade.
Claro, partindo do pressuposto de que os problemas de privacidade possam ser resolvidos.
Poderia mudar vidas.
O Live Transcribe do Android é muito bom hoje, mas nem tenta separar quais palavras vieram de qual pessoa.
Ele mostra o enorme processamento que o cérebro faz para conseguirmos entender o que alguém está nos dizendo em uma sala barulhenta.
https://en.wikipedia.org/wiki/Cocktail_party_effect?wprov=sf...
Algo em torno de 10 vezes a maior frequência acústica que se deseja captar, ou seja, dentro de alguns dezenas de microssegundos.
Além disso, se as posições dos microfones no arranjo não forem uma linha, um círculo ou outra geometria simples, o código — isto é, a matemática — para extrair um sinal melhor fica muito difícil.
A Boeing criou uma versão esférica desse tipo de dispositivo e a usou no protótipo do 787 para encontrar candidatos a material de isolamento acústico.
Em um ambiente barulhento como um avião, ilusões auditivas podem fazer o som parecer vir de um lugar diferente do real.
Quando há um orçamento de peso definido para material acústico, acertar bem o ponto 80/20 se torna importante.
Se quiser brincar com um Zynq 7010, vale dar uma olhada na placa EBAZ4205.
Ela pode ser comprada no AliExpress por 20–30 euros e era uma antiga controladora de mineração de Bitcoin.
Algumas pessoas fizeram engenharia reversa de tudo e colocaram no GitHub, e também há placas adaptadoras para acessar os GPIOs.
Se quiser começar com algo menos complexo, também há FPGAs chineses, como placas “Sipeed” que usam GoWin FPGA.
São bem utilizáveis, e a IDE também é gratuita.
Pesquisando ontem à noite, acabei chegando exatamente a esta página.
Fico curioso se alguém sabe como instalar microfones em uma sala para gravar apenas o áudio de uma área específica.
No meu caso, seria gravar a área do sofá para assistir TV com amigos online, removendo do áudio as vozes dos amigos e o ruído da transmissão.
Parece que seria possível montar um arranjo de microfones e usar direcionamento de feixe, mas não encontrei muitos exemplos de código no GitHub que funcionem em tempo real.
https://obsproject.com/
https://voicemeeter.com/
O que você quer não é uma técnica de microfone ou beamforming, mas cancelamento de eco, como o usado por todos os softwares de videoconferência.
Basta fornecer o áudio da transmissão e o áudio dos amigos como entradas e aplicar cancelamento de eco a cada um.
Meça a distância de um ponto — o sofá — até cada microfone, atrase os sinais no domínio do tempo pelo tempo que o som leva para ir do sofá até cada microfone e então some tudo.
Basicamente, a ideia é alinhar os microfones para que recebam o sinal do sofá como se fosse no mesmo instante, mesmo estando a distâncias diferentes.
Para esse método funcionar bem, é preciso que haja diferenças suficientes nas distâncias entre os microfones.