Hardware AoE multicanal

En primer lugar, ya he encontrado una gran cantidad de información aquí, ¡así que gracias! Espero recibir comentarios generales sobre un proyecto en el que me gustaría trabajar. Aquí hay un esquema.

Me gustaría poder transmitir 8 canales de audio de 24 bits y 48 KHz a través de Ethernet a una colección de 6 a 8 receptores, todos conectados a través de un interruptor. Aquí está mi proceso de pensamiento.

  1. Velocidad de red : 8 canales * 24 bits = 24 bytes. Eso está por debajo del mínimo de 46 bytes (no 802.1Q), así que solo trabajaremos con ese mínimo. Nuestro tamaño mínimo de trama es de 84 bytes. A 48 KHz, esto implicaría un rendimiento promedio de ~32,3 mbit/s en la red. Dado este resultado, una red ethernet rápida con conmutadores apropiados parecería estar bien. ¿Este análisis parece exacto?

    Tenga en cuenta que no estoy demasiado preocupado por la reproducción perfecta, por lo que un paquete perdido ocasionalmente no es un gran problema. Dado esto, no creo que quiera entrar en la conversión de frecuencia de muestreo para la transmisión de red.

    Nota al margen: originalmente quería trabajar en una red 10Base-T porque muchas MCU habían integrado 10Base-T MAC/PHY. Sin embargo, dado el tamaño mínimo de cuadro de 84 bytes... ¡esto restringiría las frecuencias de muestreo a un poco menos de 15 KHz!

    Solo para asegurarme de que estoy pensando en esto correctamente, no puedo violar el marco mínimo de 84 bytes si quiero poder usar interruptores comerciales, ¿correcto?

  2. Hardware del receptor

    a. Controlador Ethernet : me gustaría un controlador Ethernet 100Base-T con MAC/PHY integrado. Sin embargo, el problema es que debe poder comunicarse con la MCU lo suficientemente rápido como para enviar todos los datos de audio. 8 canales * 24 bits * 48KHz = 9,22 mbit/s. Estoy pensando que esto va a ser demasiado rápido para SPI. El ENC424J600, además de SPI, tiene una interfaz paralela que parece ser útil para velocidades más rápidas. En la página 53, se dan algunas cifras teóricas de rendimiento.

    http://ww1.microchip.com/downloads/en/DeviceDoc/39935c.pdf

    b. MCU : cualquiera que elija, deberá ser lo suficientemente robusto como para leer los 8 canales de datos de audio del controlador Ethernet, hacer un DSP muy básico en ese momento (mezcla de canales) y enviar los datos a un DAC estéreo de 24 bits. a 48 KHz. Además de esto, también necesita hacer algunas interfaces básicas con las E/S del panel. ¿Alguna sugerencia sobre un MCU adecuado?

    Tenga en cuenta que estoy buscando usar este DAC.

    http://www.cirrus.com/en/products/cs4341.html

¡Cualquier comentario o pensamiento que tengan que pueda ser útil para este proyecto sería muy apreciado!

gracias jordan

Como ya tiene una MCU, ¿qué pasa con la compresión de datos? Un códec con pérdida reducirá en gran medida su ancho de banda. incluso un códec sin pérdidas le dará una reducción neta en el ancho de banda.
¿Tiene un requisito de latencia? Si no, no veo por qué el tamaño mínimo del paquete es relevante, puede y debe tener más de un conjunto de muestras por cuadro. Los datos de 33 Mbit sobre 100 Mbit son casi alcanzables, siempre que sean estrictamente en una dirección. Probablemente querrás un ARM o similar como procesador.
mencionaste que 33 Mbit sobre 100 Mbit es "casi alcanzable". ¿Se refiere esto a un rendimiento sostenido alcanzable? En caso afirmativo, ¿podría proporcionar más información sobre este cálculo?

Respuestas (2)

  1. No desea enviar un solo paquete para cada muestra. Eso es porque el paquete también tiene encabezados, y eso significa ineficiencia en la transferencia. Poner varias muestras en un solo paquete aumentará la eficiencia y superará el tamaño mínimo de paquete. El límite superior en el número de muestras es la latencia máxima que puede tolerar. A 48kHz, agregar una muestra más a sus paquetes aumentaría la latencia en ~21 m s. También debe calcular la latencia introducida por todo el sistema de extremo a extremo. Tener 8-16 muestras por paquete aumentaría su eficiencia por encima del 70-80%.

  2. Yo optaría por un microcontrolador con Ethernet MAC integrado. Tener un PHY incorporado también sería una buena ventaja, sin embargo, esa restricción adicional disminuiría en gran medida su elección. Hay muchos, muchos microcontroladores con un MAC de 100Mbps incorporado, pero solo unos pocos con un PHY incorporado también.

Nunca pensé en poner varias muestras en un solo marco, eso tiene mucho sentido. Investigaré un poco y definiré mejor mis restricciones de latencia. ¡Gracias por la respuesta!

El elefante en la habitación con audio sobre IP en un contexto profesional es la distribución del reloj y la recuperación del reloj...

Puede colocar fácilmente 64 canales de audio de 24 bits y 48K en un enlace de 100 Mb/s, con sus múltiples receptores podría estar pensando en multidifusión o similar.

AES67 puede ser interesante, y eche un vistazo a Ravenna y Dante también para obtener ideas (también AVB, pero es excesivo solo para audio).

Hay muchos pequeños micros con MAC incorporado que solo necesitan un PHY para hacer este tipo de cosas, pero probablemente querrá bloquear el reloj de audio a la velocidad de cuadro entrante que generalmente necesitará un PLL de hardware de algún tipo (El alternativa es un SRC y un bucle de bloqueo de retardo).

8 canales = ~1,2 MB/s = por lo que no encajará en un enlace de 10 Mb, pero es trivial en un enlace de 100 Mb/s.

Use un DAC de 8 canales que admita el modo DSP y, a menudo, puede perfeccionar la salida utilizando uno de los puertos SPI.

Saludos, Dan.