Micrófono de arreglo en fase (2023)
(benwang.dev)- El micrófono de arreglo en fase de 192 canales permite cambiar la direccionalidad incluso después de grabar, o enfocar simultáneamente cientos de miles de puntos, lo que posibilita estimar y visualizar la ubicación de fuentes sonoras, algo difícil con micrófonos direccionales comunes
- El hardware está compuesto por brazos radiales de micrófonos y un hub central; con un costo de unos $700, usa 192 micrófonos MEMS, una tarjeta FPGA Colorlight i5 y una estructura de transmisión por Gigabit Ethernet
- La FPGA se enfoca en transmitir datos PDM crudos en vez de hacer preprocesamiento complejo: procesa una entrada de 3.125MHz y usa unos 715Mbps, cerca del 70% del ancho de banda de Gigabit Ethernet
- El software combina un filtro CIC, calibración basada en FFT, optimización en GPU y beamforming con Triton para visualizar en tiempo real la ubicación de fuentes sonoras 3D de campo cercano y 2D de campo lejano
- Los paquetes UDP pueden capturarse con
tcpdumpy reproducirse, pero almacenar datos crudos llega a 87.5MB/s, por lo que una grabación de 1 hora requiere 315GB
Configuración de un micrófono de arreglo en fase de 192 canales
- Combina un micrófono de arreglo en fase de 192 canales con adquisición de datos por FPGA y beamforming/visualización basada en GPU
- A diferencia de un micrófono direccional común, un arreglo en fase puede cambiar su direccionalidad incluso después de grabar y enfocar simultáneamente cientos de miles de puntos en tiempo real
- Todo el diseño se publica como open source
Diseño de hardware
-
Estructura del arreglo y costo
- El arreglo en fase se construye colocando muchos micrófonos con una distribución de separaciones amplia
- En arreglos lineales, se sabe que para señales de banda ancha la separación exponencial entre micrófonos es óptima
- El arreglo 2D coloca brazos de arreglos lineales simétricos en disposición radial para mantener pequeña la placa hub central
- El costo total del arreglo es de unos $700
-
Placas de brazo
- La longitud de cada brazo se ajustó a los límites de fabricación y ensamble de PCB; la longitud máxima de fabricación/ensamble de PCB de 4 capas de JLCPCB era de 570mm
- Los micrófonos son MEMS baratos con salida digital, de unos $0.5 cada uno
- En este rango de precio no hay grandes diferencias de rendimiento entre micrófonos
- La mayoría tiene un rendimiento aceptable hasta 10kHz, pero no se especifican el retardo de fase ni la coincidencia de volumen
- Los micrófonos entregan datos mediante PDM (pulse density modulation)
- Producen una salida de 1 bit a frecuencias de hasta 4MHz, muy por encima del rango audible
- Compensan el ruido de cuantización con una alta tasa de muestreo
- Soportan DDR, que captura datos en los flancos de subida y bajada del reloj, lo que permite multiplexar dos micrófonos en una sola línea
- Cada brazo tiene 8 micrófonos y 4 líneas de salida, con un búfer de salida en la línea de entrada de reloj
- El diseño mantiene un tiempo de subida razonable aunque cientos de micrófonos compartan la misma señal de reloj
- El rendimiento de fabricación de las PCB de los brazos no fue bueno: alrededor de 50% de las placas funcionaban en su estado inicial
- La falla más común era un corto de la línea de reloj a 3V3 o GND
- Para resolver el corto hacía falta retirar micrófonos uno por uno mediante prueba y error
- Algunos micrófonos seguían entregando datos incorrectos incluso después del retrabajo, y el código los excluye enmascarándolos
- En un próximo diseño, resistencias en serie en la línea de reloj, mejoras de panelización y mejoras en el esténcil de pasta de soldadura podrían reducir el retrabajo
-
Placa hub
- Para la adquisición de datos se usa una FPGA, necesaria por la gran cantidad de E/S de baja latencia y las interfaces de alta velocidad como Gigabit Ethernet
- En concreto se eligió la tarjeta Colorlight i5
- Los motivos fueron suficiente E/S, bajo precio, facilidad de compra y dos PHY Ethernet integrados
- En este proyecto solo se usa un PHY Ethernet
- Esta tarjeta originalmente es una interfaz Ethernet para paneles LED, pero fue completamente sometida a ingeniería inversa
- Unos 100 GPIO están expuestos mediante conectores DDR2, lo que facilita el fan-out en comparación con el BGA original de la FPGA
- Además de la FPGA, el hub incluye un circuito sencillo de administración de energía, conectores para las placas de brazo y un conector Ethernet con magnetics integrados
-
Diseño mecánico
- Los brazos se fijan al hub con separadores y tuercas para montaje de PCB y tornillos M3
- La conexión entre los brazos y el hub se realiza con conectores de 8 pines y paso de 2mm
- El diseño inicial hacía encajar ranuras de la PCB del brazo con una PCB estructural circunferencial, pero la baja rigidez torsional de los brazos hacía que toda la estructura se deformara fácilmente
- El diseño final usa piezas de MDF de 1/4 de pulgada cortadas con láser en el borde externo del arreglo, y cada brazo se fija al MDF con precintos
- Como el arreglo de micrófonos va montado en una pared y es vulnerable a reflexiones, se reducen las reflexiones con espuma acústica para facilitar la calibración
Gateware de la FPGA
-
Objetivos de diseño
- El objetivo principal del gateware es transferir de forma estable y sin pérdidas los datos crudos adquiridos a la computadora
- Hacer decimación y filtrado en la FPGA podría reducir la tasa de datos, pero los datos PDM crudos también pueden transmitirse por Gigabit Ethernet
- Enviar datos crudos reduce la complejidad del código de la FPGA y acelera el desarrollo iterativo
- La compilación de código es más rápida que el placement y routing, y usar un depurador en código común es más fácil que depurar gateware
-
Interfaz PDM
- El módulo de entrada PDM divide el reloj de sistema de 50MHz por 16 y emite un reloj PDM de 3.125MHz
- Después de cada flanco de reloj captura 96 pines de entrada, y en cada ciclo de reloj desplaza datos de 32 bits
- A cada bloque de datos de 192 bits le agrega un encabezado de entero incremental de 32 bits
- La tasa de datos de entrada de la interfaz PDM es 3.125MHz × 96 pines de entrada × DDR 2 = 600Mbps
- La tasa de datos de salida, incluyendo encabezados, es de 700Mbps, y el uso de la ruta de datos de salida de 32 bits es de alrededor de 40%
-
Paquetización y transmisión UDP
- El módulo de paquetización es parecido a un búfer FIFO con una interfaz de entrada especial
- Como la interfaz Ethernet es más rápida que la salida PDM, si se emitiera con apenas un elemento como en una FIFO estándar, podrían generarse paquetes más pequeños de lo solicitado
- El módulo de paquetización espera hasta acumular en la cola datos suficientes para un paquete y luego empieza a transmitir, garantizando paquetes de tamaño fijo
- Cada paquete contiene 48 bloques de salida PDM de 224 bits
- Cada bloque consta de 192 bits de datos y un encabezado de 32 bits
- Los datos por paquete son 1344 bytes
- Se agregan un encabezado IPv4 de 20 bytes y un encabezado UDP de 8 bytes
- La tasa de paquetes es de unos 65kpps y, como resultado, la velocidad de línea es de 715Mbps, cerca del 70% de uso de Gigabit Ethernet
- Para el streaming UDP se usa LiteEth
- Abstrae complejidades de bajo nivel como la encapsulación UDP/IP y la tabla ARP
- Proporciona una interfaz que facilita conectar una FIFO a un stream UDP
- Las latencias intermitentes se absorben con el margen del búfer de la FIFO de paquetización
-
Uso de recursos de la FPGA
- La FPGA de la Colorlight i5 es
LFE5U-25F-6BG381Cy tiene 25k LUT - El diseño se coloca y enruta con la toolchain open source Project Trellis
- Al mantener simple el gateware, el uso de recursos es bajo y queda mucho margen para agregar funciones
- DP16KD: 16/56, 28%
- TRELLIS_FF: 1950/24288, 8%
- TRELLIS_COMB: 3701/24288, 15%
- El reloj máximo pasa con 73.17MHz frente al objetivo de 50MHz
- La advertencia de timing del reloj RX de Ethernet es un falso positivo relacionado con el gray counter de LiteEth
- La FPGA de la Colorlight i5 es
Pipeline de procesamiento de software
-
Filtro CIC
- Cada micrófono entrega una señal de 1 bit a 3.125MHz, que debe reducirse a una tasa de muestreo y profundidad de bits menores para el procesamiento posterior
- Para esta tarea se usa un filtro CIC, que requiere pocas operaciones aritméticas
- Se tomó como referencia la serie Moving Average and CIC Filters de Tom Verbeure
- La elección final es un filtro CIC de 4 etapas con decimación 16×
- Reduce la tasa de muestreo a 195kHz
- La salida es de 32 bits
- Para aceptar datos a 3.125MHz, cada lote de muestras debe procesarse en 320ns
- Una implementación simple en Rust no fue lo suficientemente rápida en un solo núcleo; la versión final reduce abstracciones para inducir mejor la vectorización automática
- La implementación con intrinsics SIMD era mucho más rápida, pero encontró problemas de alineación al usarse junto con otro código
- Resultados de benchmark:
bench_cic: 574ns/iter, 41MB/sbench_fast_cic: 181ns/iter, 132MB/sbench_simd_cic: 36ns/iter, 666MB/s
-
Calibración
- La calibración del arreglo se realiza moviendo dentro de la habitación, frente al arreglo, una bocina que reproduce ruido blanco
- Se calcula una correlación cruzada basada en FFT entre todos los pares de micrófonos para obtener retardos relativos
- Como hay más de 18,000 pares de micrófonos, la carga de cómputo es alta
- Con tamaños de ventana de 16k a 64k, la FFT está limitada por memoria; por eso se combinaron la IFFT y la búsqueda de picos para no escribir el resultado en memoria, obteniendo una mejora de velocidad de 15×
- En un Ryzen 7950X, este proceso se ejecuta en tiempo real
- Luego se optimizan mediante descenso de gradiente la ubicación de la fuente sonora en cada instante y la posición de cada micrófono
- La función de pérdida reduce la diferencia entre la correlación medida y la correlación ideal
- Evita que las posiciones de los micrófonos se alejen demasiado de sus posiciones iniciales
- También reduce el jerk de la trayectoria de la fuente sonora
- Durante la calibración, la velocidad del sonido también se incluye como parámetro de optimización, por lo que todo el procedimiento funciona como un termómetro excesivamente complejo
- Tras cientos de iteraciones, constantes como la ubicación de la fuente sonora, las posiciones de los micrófonos y la velocidad del sonido convergen a una solución razonable
- Este problema se vectoriza bien en GPU y converge en pocos segundos
- El error medio final de posición es de aproximadamente 1mm
- También corrige distorsiones sistemáticas de gran escala, como la concavidad causada por la falta de rigidez estructural
- El error máximo entre las posiciones de diseño y las posiciones calibradas es de unos 5mm
- La longitud de onda de un sonido de 10kHz es de unos 3.4cm, así que sin calibración pueden aparecer errores de fase significativos en altas frecuencias
Beamforming y visualización
-
Método de beamforming
- El beamforming es el proceso de convertir las entradas crudas de micrófono en una respuesta direccional
- La implementación usa el método más simple: delay-and-sum, o DAS
- Cada señal se retrasa según la diferencia de distancia hasta la fuente sonora y luego se suma
- En este proyecto, el beamforming se realiza en el dominio de la frecuencia
- En el dominio de la frecuencia, un retardo se implementa mediante un término de fase lineal proporcional al retardo requerido y una multiplicación compleja de la señal
- También maneja naturalmente retardos que no son múltiplos enteros del período de muestreo
- Se usan varios subarreglos superpuestos del arreglo original según el rango de frecuencia
- No es necesario hacer beamforming con todos los micrófonos en todas las frecuencias, lo que reduce el procesamiento y también ayuda a igualar la ganancia de beamforming en todas las frecuencias
-
Implementación en GPU basada en Triton
- El beamformer se implementa como kernels de Triton
- Triton es un DSL de Python que se compila para ejecutarse en GPU Nvidia
- Al hacer beamforming sobre cientos de miles de puntos, el paralelismo masivo de la GPU permite obtener resultados en tiempo real
- Debido a una restricción actual relacionada con el soporte de indexación de arreglos de memoria compartida en el lenguaje Triton, el rendimiento no es del todo óptimo, pero se decidió no escribir CUDA C++
-
Beamforming 3D de campo cercano
- El beamforming 3D de campo cercano se realiza en una grilla de vóxeles de 5cm
- El tamaño de la grilla es 64×64×64
- En una RTX 4090 se logra una tasa de actualización de 12Hz
- Velocidades más altas quedan limitadas por el overhead no óptimo de sincronización CPU-GPU en unidades de trabajo pequeñas
- La grilla de vóxeles se visualiza con VisPy, una biblioteca de visualización de alto rendimiento basada en OpenGL
- Renderizar 250,000 vóxeles semitransparentes no presenta problemas a framerates interactivos si se compara con el conteo de polígonos de los juegos modernos
-
Beamforming 2D de campo lejano
- En fuentes sonoras lejanas, el frente de onda es casi plano, por lo que la distancia a la que esté la fuente no cambia de forma significativa la señal del arreglo
- Las fuentes sonoras cercanas tienen mayor curvatura del frente de onda, lo que permite determinar la posición 3D
- El beamforming de campo lejano no tiene dimensión de profundidad, por lo que puede realizarse con mayor resolución
- Usa una grilla de 512×512 píxeles y también alcanza una tasa de actualización de 12Hz
- El beamforming de campo lejano usa una aproximación que coloca los puntos lejos, en vez de asumir una onda plana real
- Debido a la cantidad de reflexiones y multipath dentro de la habitación, la demo de visualización 2D se ve afectada por el entorno acústico
-
Audio direccional
- Las dos implementaciones anteriores de beamforming calculan la energía sonora en cada posición, pero no crean el audio beamformeado en memoria
- Para grabar audio direccional se implementó un beamformer delay-and-sum en el dominio del tiempo
- Recibe coordenadas 3D relativas al centro del arreglo
- Entrega muestras de audio
- En este beamformer, la salida es diferenciable respecto de la posición
- La ubicación de una fuente de audio puede optimizarse con una función de pérdida diferenciable
- Una aplicación posible sería usar un modelo de alineación forzada en transcripciones con múltiples participantes para encontrar la posición física de cada hablante
- Se comparó el efecto reproduciendo audio con una bocina frente al arreglo y ruido blanco con otra bocina a la misma distancia, a unos 45 grados del centro del arreglo
- Se muestra el efecto del beamforming comparando el audio crudo de un solo micrófono con el audio beamformeado
Forma de grabación y límites
- Como los datos del arreglo de micrófonos son paquetes UDP, pueden grabarse con herramientas como
tcpdump - Se puede leer el archivo de captura de paquetes y volver a inyectar los paquetes a un listener
- Los programas anteriores fueron diseñados para funcionar en tiempo real, pero también funcionan con datos grabados mediante este método
- La desventaja es que se almacenan los datos crudos tal cual, por lo que la tasa de datos de salida es muy alta
- También se conserva fielmente el ruido de cuantización
- La tasa de datos es de 87.5MB/s
- Una grabación de 1 hora requiere 315GB
- Una implementación más optimizada podría aplicar compresión o grabar a una tasa de muestreo menor después del filtro CIC
Posibles extensiones
- El proyecto está prácticamente terminado y no hay planes de trabajar más en él en el futuro cercano
- Aun así, quedan posibilidades de extensión para quienes quieran construirlo por su cuenta
- Usar algoritmos de beamforming más avanzados como DAMAS
- Una GUI mejor que combine funciones existentes, como ver de dónde viene el sonido y grabar audio desde esa ubicación
- Combinar beamforming diferenciable con modelos de redes neuronales; por ejemplo, también son posibles aplicaciones como el ejemplo de alineación forzada
1 comentarios
Comentarios de Hacker News
Me parece interesante que, durante el proceso de calibración, la velocidad del sonido también sea un parámetro que se optimiza para obtener el modelo óptimo del sistema, así que todo el procedimiento termina funcionando como un termómetro absurdamente sobrediseñado.
Me recuerda al dicho de la electrónica: “Todos los sensores son sensores de temperatura, y algunos también miden otras cosas”.
Resultó que con ese método también se podía medir la temperatura y extrapolar la gráfica para encontrar el cero absoluto.
Si mal no recuerdo, el resultado se desvió unos 20 K, lo cual me parece bastante excelente para un proyecto de garaje de un estudiante de secundaria.
Me gusta especialmente el ejemplo de que una unidad de medición inercial (IMU) lo suficientemente precisa puede incluso medir la longitud con relativa exactitud usando el efecto Coriolis.
https://youtu.be/zsA3X40nz9w?si=oGg2wdUlLXSDxpsN
Hace tiempo hice un proyecto de multilateración de murciélagos con un arreglo de 4 micrófonos colocado en el suelo con forma de Y grande.
Usando las diferencias en los tiempos de llegada a los cuatro micrófonos, podíamos localizar a cada murciélago que volaba sobre el arreglo e incluso identificar la especie.
Se usó en una investigación para determinar el impacto ambiental de instalar turbinas eólicas, y fue bastante divertido.
Era un dispositivo desarrollado para rastrear y matar mosquitos con pulsos láser cortos.
Como necesitaba determinar con precisión la posición espacial del mosquito, de paso podía detectar diferencias en la frecuencia del aleteo y distinguir objetivos por sexo y especie.
Como era de esperarse, me faltaban habilidades de hardware y software, así que implementé el algoritmo TDOA en su forma más ingenua, y el método para estimar las diferencias de tiempo mediante correlación cruzada era muy ineficiente.
Aun así aprendí mucho y al final eso me llevó a un doctorado en sistemas SAR.
Creo que SAR, en la práctica, es más bien un beamformer que usa el movimiento de la plataforma en lugar de un arreglo.
Alguna vez escuché que los pulmones de los murciélagos son tan sensibles que, si vuelan atravesando el diferencial de presión de una turbina grande, sus capilares básicamente revientan.
Me gustaría tener materiales de referencia sobre por dónde empezar.
Colocaron un arreglo de micrófonos debajo de un escorpión y mostraron cómo los murciélagos movían su haz ultrasónico para escanearlo.
Fue un resultado realmente sorprendente [0].
[0]: https://www.youtube.com/watch?v=57ScSPWhGqU
Me pregunto por qué usaron PDM en vez de micrófonos I2S TDM para el arreglo.
El ICS-52000 es relativamente barato, cuesta del orden de 2 dólares en cantidades de 100, hay placas breakout con 4 micrófonos, y entiendo que se pueden encadenar hasta 8 o 16.
https://www.cdiweb.com/datasheets/notwired/ds-nw-aud-ics5200...
Si se usa hardware con Jetson o con DSP/GPU compatible con I2S, se pueden encadenar 16 micrófonos por puerto I2S, así que parece mucho más fácil de ensamblar y programar que una configuración con FPGA.
Con 192 micrófonos, la diferencia entre 2 dólares por unidad y 0.5 dólares por unidad se vuelve bastante grande.
Incluso con daisy chains de 16, es difícil encontrar un dispositivo con suficientes interfaces I2S, y la mayoría de los dispositivos no tiene la cantidad necesaria.
La FPGA y el hardware personalizado también eran parte de la diversión.
Para escuchar el siseo de una fuga de gas o la descarga corona de un arco eléctrico, las frecuencias más altas son útiles.
Orin tiene internamente 6 puertos I2S, así que 16*6 = 96 micrófonos parece posible, y es una cifra bastante buena.
Sin embargo, en la práctica parece que solo 3 salen de la placa y están en conectores distintos de la placa de desarrollo [1].
En diseño, el problema siempre está en los detalles, así que si necesitas más de 96, una FPGA podría ser más fácil de configurar.
Las piezas que tenía anotadas eran ICS-52000 $3.50 20 kHz, ICS-41350 $1.05 40 kHz y SPH0641LU4H-1 $1.45 80 kHz+.
[1] https://docs.nvidia.com/jetson/archives/r34.1/DeveloperGuide...
Hay más o menos dos razones por las que I2S no es la mejor opción.
I2S necesita 3 pines en vez de los 2 de PDM.
Aunque si se pueden encadenar micrófonos como en la hoja de datos que compartiste, está bastante bien, y aunque no sea I2S estándar, ese punto desaparece.
PDM permite acceder a tasas de muestreo mucho más altas, lo que da más flexibilidad para elegir el retardo en operaciones de delay-and-sum.
Por ejemplo, si el reloj PDM es de 2 MHz, en teoría se podría retardar con una precisión de 0.5 µs.
En la práctica se haría con menor precisión, pero el reloj I2S normalmente llega como máximo a unos 192 kHz.
Los micrófonos PDM también son más baratos.
Si buscas cámaras acústicas en YouTube, hay demostraciones bastante impresionantes que muestran su rendimiento.
Una de las empresas que estuve siguiendo durante un tiempo es esta, y parece que también están entrando jugadores grandes como FLIR: https://www.youtube.com/@gfaitechgmbh
Un caso de uso interesante pero inquietante es grabar un lugar público y luego hacer “zoom” sobre una conversación entre personas específicas.
Hablando con un amigo que usa un implante coclear, me pareció que, con el procesamiento de señales adecuado, podría ser de gran ayuda para escuchar.
Me gustaría volver a ser estudiante de posgrado y combinar esto con un arreglo de altavoces ultrasónicos para intentar aplicaciones médicas.
En esencia, sería algo como HIFU (ultrasonido focalizado de alta intensidad) superpotente con retroalimentación en tiempo real.
https://en.wikipedia.org/wiki/Focused_ultrasound
Las frecuencias son mucho más altas, hay que pensar en algo del orden de 1 a 10 MHz, no 40 kHz, y la electrónica común prácticamente no sirve.
Si quieres conversar, puedes escribirme al correo de mi perfil.
Me gustaría que esta tecnología llegara a varios dispositivos móviles en una forma bien empaquetada.
Creo que una de las razones por las que cosas como asistentes y traductores universales se traban es la mala calidad del audio.
Reducir el ruido y detectar la dirección tiene el potencial de ayudar mucho.
Por ejemplo, me gustaría traducir en tiempo real una conversación grupal alrededor de una mesa.
Para empezar, sería bueno que el teléfono y los audífonos pudieran combinar sus micrófonos para algo así.
Más adelante, me pregunto qué pasaría si todos los teléfonos cercanos pudieran colaborar para ofrecer audio direccional de alta calidad.
Claro, suponiendo que se puedan resolver los problemas de privacidad.
Podría cambiar vidas.
Live Transcribe de Android ya es muy bueno, pero ni siquiera intenta separar qué palabras vienen de qué hablante.
Muestra el enorme procesamiento que hace el cerebro para que podamos entender lo que alguien nos dice en una habitación ruidosa.
https://en.wikipedia.org/wiki/Cocktail_party_effect?wprov=sf...
Aproximadamente al nivel de 10 veces la frecuencia acústica más alta que se quiera captar, es decir, dentro de unas decenas de microsegundos.
Además, si las posiciones del arreglo de micrófonos no forman una línea, un círculo u otra geometría simple, el código —es decir, la matemática— para extraer una señal mejorada se vuelve muy difícil.
Boeing fabricó una versión esférica de un dispositivo así y la usó en prototipos del 787 para encontrar candidatos de material aislante acústico.
Dicen que, en entornos ruidosos como un avión, las ilusiones auditivas pueden hacer que parezca que un sonido viene de un lugar distinto al real.
Cuando hay un presupuesto de peso definido para el aislamiento acústico, importa acertar bien al punto 80/20.
Si quieres jugar con un Zynq 7010, vale la pena mirar la placa EBAZ4205.
Se consigue en AliExpress por 20 a 30 euros, y era un antiguo controlador de minería de Bitcoin.
Algunas personas la hicieron ingeniería inversa completa y la subieron a GitHub, y también hay placas adaptadoras para acceder a los GPIO.
Para empezar con algo menos complejo, también hay FPGA chinas como las placas “Sipeed” que usan FPGA GoWin.
Son bastante útiles y el IDE también es gratis.
Anoche estuve investigando y terminé justo en esta página.
Me pregunto si alguien sabe cómo instalar micrófonos en una habitación para grabar solo el audio de una zona específica.
Mi caso de uso es grabar la zona del sofá para ver TV con amigos en línea, eliminando del audio las voces de mis amigos y el ruido de la transmisión.
Creo que sería posible hacer un arreglo de micrófonos y usar direccionamiento de haz, pero no encontré muchos ejemplos de código en GitHub que funcionen en tiempo real.
https://obsproject.com/
https://voicemeeter.com/
Lo que necesitas no es tecnología de micrófonos ni beamforming, sino cancelación de eco, como la que usa todo software de videoconferencia.
Puedes usar como entrada el audio de la transmisión y el audio de tus amigos, y aplicar cancelación de eco a cada uno.
Mides la distancia desde un punto —el sofá— hasta cada micrófono, retrasas las señales en el dominio del tiempo por el tiempo que tarda el sonido en viajar del sofá al micrófono, y luego las sumas.
Básicamente, buscas alinear los micrófonos como si hubieran recibido la señal del sofá al mismo tiempo, aunque estén a distintas distancias.
Para que este método sea efectivo, debe haber suficiente diferencia de distancia entre micrófonos.