Envío de audio por ethernet

Antes de entrar en detalles, permítanme decir que probablemente he diseñado hardware de audio a través de Ethernet más profesional que nadie, tanto en términos de cantidad de diseños de PCB diferentes como en la cantidad de PCB fabricadas y enviadas a los clientes finales. Las probabilidades son muy altas de que haya escuchado productos en los que he diseñado el circuito de audio a través de Ethernet en ellos. (Esto es solo audio profesional y no incluye VOIP u otros productos no profesionales).

Comencemos con los problemas:

Software: El hardware es honestamente la parte fácil. El software es difícil. Cuanto más se acerque al rendimiento de audio profesional, más difícil será. Su aplicación no suena como audio profesional, pero la tarea del software aún no es trivial.

Reloj de audio: la transmisión de datos de audio del punto A al punto B es relativamente fácil. Hacerlo de manera que los dos dispositivos tengan un reloj de audio sincronizado es difícil. Las aplicaciones que no son profesionales resuelven esto al hacer una conversión de frecuencia de muestreo o simplemente soltar/duplicar muestras a medida que los relojes de audio se desvían. Hay dificultades y efectos secundarios de ambos, lo que aumenta enormemente la dificultad del software. Simplemente guardar los datos en un archivo en el lado de la PC es fácil; usarlos en tiempo real es difícil.

Baja latencia: el tiempo que tarda el audio en ir desde el micrófono, a través de la red hasta la PC y luego utilizado por la PC se denomina latencia. Cuanto más corta es la latencia, más difíciles son las cosas. El simple hecho de guardar datos de audio en un archivo es un buen ejemplo de latencia súper larga y es una de las razones por las que también es lo más fácil de hacer. Una latencia de <2.5 mS es muy difícil de hacer de manera correcta y robusta. Cuanto más corta es la latencia, menos problemas hay con cosas como eco de audio y demás.

Ancho de banda: Enviar audio de calidad telefónica con alta latencia es lo más fácil. La calidad de audio profesional con baja latencia es muy difícil. El uso de la interfaz de micrófono, MCU y Ethernet que usted propuso lo pondrá en el lado de la calidad del teléfono. Hay muchos casos en los que los bits por segundo sin procesar de la interfaz Ethernet no son el único problema. Otros problemas como la tasa de IRQ, el tiempo de transmisión/recepción de paquetes (no solo el ancho de banda general) y, a veces, la sincronización de paquetes son muy importantes.

Topología de red: a medida que aumenta la calidad del audio (y disminuye la latencia), la topología de su red se vuelve realmente importante. Me refiero a la cantidad de conmutadores Ethernet, el tipo de conmutadores, cómo están conectados y la cantidad/tipo de dispositivos Ethernet que no son de audio también en la red. Para ti esto probablemente no sería un problema, pero nunca se sabe.

Creo que su solución propuesta funcionaría para la calidad de audio del teléfono con una latencia alta. Probablemente tendrá que soltar/repetir muestras para lidiar con relojes de audio no sincronizados. Y no será tan bueno. Es posible que te sientas bastante decepcionado por el audio. También creo que tendrá mucho software para escribir en el lado de la PC. Dicho esto, no haría el proyecto con eso.

Si estuviera haciendo el proyecto, buscaría uno de los dispositivos ARM Cortex-M3 o M4 más nuevos de TI o Freescale que incluye controladores Ethernet de 100 mbps o gigabit. Muchas de estas cosas cuestan menos de US$10 cada una y pueden funcionar hasta a 100 MHz. La cantidad de RAM y Flash facilita mucho la tarea de escribir software.

Para entretenerme, mi proyecto actual de Audio Over Ethernet utiliza un ARM Cortex-A8 de 800 MHz con dos puertos Gigabit Ethernet y ejecuta una versión personalizada de Linux. El sistema en su conjunto (no solo este dispositivo Cortex-A8) puede manejar más de 2048 canales de audio a 48 KHz, 32 bits, con una latencia general del sistema de solo 2,5 mS (incluidos ADC, DAC, dos veces a través de la red y muchos otros). Procesando). Los dispositivos de audio en la red tienen sus relojes de muestra sincronizados a menos de 1 uS, incluso si hay más de 8 saltos de conmutación en el medio.

Si le preocupa el ancho de banda, debe usar un micro con MAC/PHY incorporado en lugar de una conexión externa a través de SPI como lo es el ENC28J60. Mi pila de red admite tanto el ENC28J60 como el MAC/PHY interno de algunos PIC 18 como el 18F67J60, y existe una clara diferencia en la velocidad cuando el micro debe manejar los datos.

Ethernet a 10 Mbit/s es mucho más de lo necesario incluso para audio de buena calidad. Las muestras de 16 bits a 44 kHz son 704 kbit/s, por ejemplo. Si solo quieres calidad de voz, puede ser mucho menor. Las muestras de 12 bits a 10 kHz son solo 120 kbit/s, por ejemplo, y eso es muy buena calidad de voz.

El cuello de botella estará en el manejo de los datos en el micro. La frecuencia de muestreo de 10 kHz es una muestra cada 100 µs, que es cada 1000 instrucciones para un procesador que se ejecuta a una frecuencia de instrucción de 10 MHz. Eso es mucho.

Dijiste "ethernet", pero no qué tipo de protocolo quieres usar. Si planea enviar paquetes de Ethernet sin procesar con una identificación de protocolo privado o algo así, entonces no hay muchos gastos generales, especialmente porque solo está enviando y si el MAC/PHY está integrado en el procesador. En ese caso, esto es fácilmente factible a partir de los números anteriores.

Se vuelve más complicado si desea utilizar un protocolo de red estándar. Si lo hace, aquí será donde van la mayoría de los ciclos y, por lo tanto, será el límite en la velocidad de datos. Para la transmisión de audio, usaría UDP ya que es mucho más simple que TCP y no requiere recepción, ACK y similares.

Tengo un proyecto en proceso en el que el pequeño sistema integrado necesita recibir transmisión de audio con calidad de voz, entre otras cosas. Planeo usar UDP para la transmisión de audio. Tengo un 18F67J60 que ejecuta una pila de red completa ya que esta unidad se comunicará a través de TCP también para otros fines. La recepción de paquetes UDP es bastante simple, por lo que creo que puede manejar el ancho de banda. Cualquier micro que maneje una pila de red generalmente no es bueno para el procesamiento en tiempo real de baja latencia, por lo que dediqué un micro separado para recibir la transmisión de datos de audio del procesador de red a través de SPI en la misma placa. Este procesador utilizará la mayor parte de su RAM como un búfer de muestras. Los datos del procesador de red llegarán en ráfagas, pero deben escribirse a un ritmo constante. Probablemente no llegue a implementar la parte de transmisión de audio de este proyecto durante uno o dos meses.

He usado Arduino en 115200 Bd en el pasado en el puerto serie, pero dejé de hacerlo porque de vez en cuando recibía errores de bit. Tal vez un Arduino original funcione mejor que mis réplicas chinas baratas, pero no puedo darte ninguna garantía. Creo que de ahí viene la regla general de 5kByte/s.

No tengo idea sobre el rendimiento de los escudos de Ethernet, probablemente depende del escudo y la potencia de procesamiento de Arduino. Si todo lo que desea es transcodificar una señal de audio a una señal digital en serie, eso no debería ser un gran problema para el procesador.