Búsqueda de especificaciones para procesadores de señales digitales (DSP) para aplicaciones de audio dadas [cerrado]

Tengo dificultades para elegir una solución de procesador adecuada para mi aplicación debido a mi nula experiencia con DSP:

  • Entrada TDM I2S de 8 canales de 24 bits a 11025 Hz
  • Formación de haces + ASNR
  • Selección de múltiples fuentes MSS
  • Compresión de rango dinámico DRC
  • Análisis de dominio de frecuencia ( Real FFT )
  • 5 segundos STFT
  • Búsqueda de picos
  • Algoritmos de comparación
  • Conectividad ( Bluetooth a baja tasa de transferencia, solo notificaciones)

Parámetros de la aplicación

Estoy considerando un diseño que incluya un MCU host o solo el DSP.

Hasta ahora estoy mirando los procesadores SigmaDSP :

  • Pros: interfaz I2S TDM proporcionada, blog aritmético para formación de haces, costo
  • Desventajas: Interfaz de programación gráfica con errores y limitada (sin programación c), solo están disponibles la FFT compleja Radix-2 y la ventana de análisis de superposición del 50 %, falta documentación para enviar una señal a través de SPI al controlador de host

También estoy considerando los procesadores SHARC , que encuentro excesivos para mi aplicación (sin códecs, sin salida, puerto de entrada único, etc.):

  • Pros: flexibilidad de programación C, sin necesidad de controlador de host, interfaz I2S TDM provista
  • Contras: falta de experiencia con la programación de DSP, costo del procesador, kits de desarrollo, emuladores y software

Mis preguntas son:

  1. ¿ Cómo determinar las fuentes del sistema requeridas (memoria, frecuencia de reloj , etc.)?
  2. ¿Alguna guía/recomendación/otras familias/marcas que debería buscar?

Hardware que estoy usando...
Conjunto de 2 micrófonos: https://www.notwired.co/ProductDetail/NWAUDICS52000-NotWired-CO/605574/?ProdId=605574&
I2S TDM a USB: https://www.minidsp.com /productos/interfaz-de-audio-usb/usbstreamer

Muchas gracias Pedro

Hola Pedro, tu título original era "qué comprar", y eso está fuera de tema. Sin embargo, su pregunta es totalmente diferente: "¿Qué especificaciones son relevantes", y esa es una pregunta muy buena y relacionada con el tema, ¡así que cambié el título de su pregunta!
Sin embargo, no está realmente claro cuáles son sus tasas de muestreo, complejidades algorítmicas, etc. Por lo que dice, parece que está tratando con frecuencias de muestreo de audio (entrada I2S) y una cantidad bastante benigna de datos generales (bluetooth), y no tiene ninguna restricción de latencia significativa (bluetooth). Entonces, ni siquiera estoy seguro de recomendar un DSP en absoluto: solo use una PC bog-normale o raspberry pi o cualquier cosa, de alguna manera conecte sus sensores I2S y escriba tanto C en un sistema operativo adecuado como desee.
Hola Marcus, gracias por el cambio en el título. He agregado especificaciones más detalladas en mi solicitud. La placa de matriz de micrófonos utiliza el formato I2S TDM, que no se proporciona en la mayoría de las MCU o computadoras de placa única como raspberry pi. Se pueden desarrollar controladores personalizados, pero obviamente esto no es una opción (alto costo de desarrollo). Necesito un DSP.
hm, no sé, I2S es bastante común. Pero es posible que tenga razón, es posible que el carril adicional con información del canal no esté disponible en cualquier computadora de placa única. Probablemente iría a buscar un FPGA barato (Ice40) y diseñaría un convertidor rápido de TDM a SPI. ¡Tenga en cuenta que TDM no es realmente un estándar! Por lo tanto, asegúrese de que su fuente pueda hablar con su procesador, de verdad.
(aparte de eso, si el estándar TDM utilizado es realmente solo I2S, donde los cuadros consecutivos solo significan diferentes canales, bueno, use hardware I2S normal, y muchas computadoras de placa única tienen I2S, y separe estos canales en el software)
I2S es una interfaz bastante común, el formato TDM no lo es. ICS-52000 fue el primer micrófono TDM del mundo con una matriz de 16 dispositivos en un solo bus. Se anunció en 2016. Por lo tanto, ninguna MCU de placa única o de propósito general implementa una biblioteca totalmente funcional para él todavía. Estoy convencido de usar un DSP, el único problema es mi nula experiencia práctica con ellos. Gracias por los comentarios de cualquier manera!
"ICS-52000 fue el primer micrófono TDM del mundo con una matriz de 16 dispositivos en un solo bus". errrrr, estoy bastante seguro de que es un discurso de marketing para "nosotros en TDK inventamos nuestra propia versión de I2S que lleva más de 2 canales, y ahora le pusimos 16 micrófonos, y porque nadie más llegó a la conclusión de que 16 canales sobre I2S era una buena idea, podemos afirmar que somos los primeros". Francamente, en algún punto en el que su máquina de estado de bus se vuelva tan complicada como esta, puede dejar de dar nombres a las cosas que "suenen" como si fueran un estándar ("TDM") y también pensar en encabezados y buses de paquetes.
de todos modos, para mí, esta hoja de datos de ICS-52000 parece que simplemente necesita conectar en cadena los buses WS y ( estremecerse ) controlar una sola línea SPI con todas las salidas del micrófono. En otras palabras: probablemente pueda generar una señal WS válida para el primer micrófono con el pin SPI MOSI de su MCU/raspberry pi promedio, use el reloj SPI para controlar el SCK y "O" juntos todos los pines SD de los micrófonos, y alimenta eso al pin SPI MISO de tu MCU. La parte difícil , en cualquier caso, sin importar lo que hagas, será conseguir el momento adecuado.
Cuando se trata de reducir la BOM, tener todos los micrófonos en un solo bus sin necesidad de códecs y con la ventaja de lo digital frente a lo analógico tiene mucho sentido. Las nuevas aplicaciones de reconocimiento de voz están requiriendo este estándar, donde antes no se necesitaban más de 2 micrófonos (estéreo). Necesita una señal WS igual a la FS (¿196 KHz?), y una SCK igual a ncanales*32 bits*la frecuencia de muestreo. No creo que pueda lograr la sincronización y el manejo de datos (¿DMA?) correctos con SPI.
DMA es una característica de su controlador. Y la mayoría de los microcontroladores con SPI tienen un motor DMA. Haga su propia impresión, pero hasta donde leí los diagramas de tiempo de la hoja de datos, no hay problema con abusar de un SPI MOSI para generar WS.
Los problemas de velocidad son reales, pero si genera el reloj en serie usando un divisor de su microcontrolador, esto debería funcionar. No estoy seguro de que ningún DSP tenga características fundamentalmente diferentes que lo hagan más fácil, pero sí, al final, no es tan improbable que termine con una lógica de pegamento personalizada en un CPLD o FPGA en alguna parte.
Estoy de acuerdo, y desde mi conocimiento/experiencia pude entender tu punto de vista. Sin embargo, hay mucho interés en esta aplicación y muchas personas tienen dificultades para que el formato TDM funcione en Raspberry Pi, Teensy y otras plataformas. No veo una implementación fácil y, especialmente, todavía no veo ninguna razón para no usar un DSP de audio para una aplicación de audio. Hay gente que no ve más allá de Arduino/Raspberry Pi. Espero poder obtener ayuda para encontrar las especificaciones de mi procesador.
Si consigue que el formato TDM funcione con SPI, la comunidad le estará muy agradecida.
¿Por qué terminaría con una tarea de desarrollo que requiere mucho tiempo en plataformas CPLD o FPGA cuando hay DSP diseñados específicamente para esta aplicación?
sí, sigo manteniendo que "TDM" no es realmente un estándar, y que me siento muy incómodo manejando la misma línea desde múltiples dispositivos. Por lo tanto, dudo que alguien, usando un DSP de audio o no, tenga, en este punto, un momento fácil para conectarse a conjuntos de micrófonos como el que usted describe. No estoy realmente convencido de que se ahorre tanto en bienes inmuebles de PCB y costos de piezas al conectar en cadena dispositivos como este si, al final, solo un diseño lógico personalizado puede hacer que las cosas funcionen con hardware estándar...
y, si usted lo dice, creeré que esos DSP se comunicarán perfectamente con dichos sistemas. Solo tengo mis dudas hasta que lo veo. y puede implementar su propia lógica porque eso podría resolver muchos problemas en el camino, podría ser más barato que usar un DSP especializado o simplemente es inevitable.
La mayoría de los DSP de audio ADI admiten el formato TDM dentro de la interfaz I2S. Puede configurar la polaridad, los relojes, las justificaciones, etc. El ICS-52000 se ocupa de la conexión en cadena, de modo que no se necesitan circuitos adicionales. Aquí tiene una nota de aplicación de 2006 de otro fabricante: d3uzseaevmutz1.cloudfront.net/pubs/appNote/AN301REV1.pdf
Lo sentimos, este es en realidad un estándar ampliamente utilizado/conocido que se utilizará en dispositivos futuros, ya que tanto los fabricantes de procesadores como los diseñadores de micrófonos lo están incluyendo.
¡Eso es realmente genial! Mis propios experimentos con audio de >2 canales basados ​​en I2S datan de hace algunos años, y realmente fue un desastre en ese entonces; su mejor apuesta fueron básicamente registros de desplazamiento profundo arbitrarios y lógica para llenarlos con un marco multicanal completo, antes de entregarlo a la lógica del controlador, de ahí mi despotricar.

Respuestas (1)

No hay fórmulas mágicas. Sin embargo, para un comienzo muy difícil, encuentre la cantidad de acumulaciones múltiples (MAC) que necesita hacer por segundo. Eso le da un límite inferior en la velocidad de instrucción.

Para hacer eso, primero debe decidir algunos parámetros:

  1. La frecuencia de muestreo de cada señal.

  2. El número de señales a las que aplicará convoluciones.

  3. El ancho de cada convolución en muestras.

El total de MAC por segundo es el producto de todos estos. Imagínese que cualquier DSP competente puede hacer un MAC en cada ciclo una vez que se pone en marcha en una convolución. Por supuesto, habrá ciclos adicionales para iniciar y finalizar cada convolución, controlar la sobrecarga, comunicarse con otros lugares, etc. Puede, por ejemplo, comenzar reservando el 25% de los ciclos del procesador para otros que no sean MAC.

A menudo, estos procesadores vienen en una familia de dispositivos relacionados. Una estrategia es crear prototipos con los mejores y luego reducirlos a lo que realmente necesita en la versión de producción. El margen adicional también le permite hacer pruebas hipotéticas en el prototipo, agregar código que podría ayudar en la depuración o verificación, etc. Puede ser muy útil tener un margen adicional significativo en el primer prototipo.

Gracias por tu respuesta @Olin Lathrop, especialmente por la recomendación de estrategia, que demuestra experiencia en el tema. Probablemente usaré ADZS-SC584-EZLITE, que es aplicable a múltiples partes como usted describió. Todavía estoy preocupado por el apoyo de la comunidad en una quinta generación relativamente nueva de procesadores SHARC. Además, CCES Embedded Studio no es gratuito, lo que será una restricción después de la licencia de 1 año. Finalmente, necesito verificar si hay un puerto serie compatible con TDM disponible en la placa, ya que muchas veces los puertos ya se usan para otros códecs ADC/DAC.
Búsqueda de especificaciones para procesadores de señales digitales (DSP) para aplicaciones de audio dadas [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v