Enviando audio a través de Ethernet

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

Empecemos con los problemas:

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

Reloj de audio: la transmisión de datos de audio desde el 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 no profesionales resuelven esto haciendo 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. 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 pasar del micrófono, a través de la red a la PC, y luego a la PC la llama latencia. Cuanto más corta es la latencia, más difíciles son las cosas. El solo 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 eso también es lo más fácil de hacer. Una latencia de < 2.5 mS es muy difícil de hacer correctamente y de forma robusta. Cuanto más corta sea la latencia, menos problemas habrá con cosas como el eco de audio y esas cosas.

Ancho de banda: lo más fácil es enviar audio de calidad telefónica con alta latencia. La calidad de audio profesional con baja latencia es súper difícil. El uso de la interfaz de micrófono, MCU y Ethernet que propuso lo pondrá en el lado de la calidad del teléfono. Hay muchos casos en los que los bits en bruto por segundo de la interfaz Ethernet no son el único problema. Otros temas como la velocidad 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 al número de conmutadores Ethernet, el tipo de conmutadores, cómo están conectados y el número / 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 alta latencia. Es probable que tenga que hacer muestreos / repeticiones para tratar con los relojes de audio no sincronizados. Y no será tan genial. Puede que estés muy decepcionado por el audio. También creo que tendrás mucho software para escribir en el lado de la PC. Dicho esto, no haría el proyecto con eso.

Si estuviera haciendo el proyecto, vería uno de los nuevos dispositivos ARM Cortex-M3 o M4 de TI o Freescale que incluyen un controlador de Ethernet de 100 Mbps o gigabit. Muchas de estas cosas cuestan menos de US $ 10 cada una y pueden funcionar hasta 100 MHz. La cantidad de RAM y Flash hace que la tarea de escribir software sea mucho más fácil.

Para diversión, mi proyecto actual de Audio Over Ethernet utiliza un ARM Cortex-A8 de 800 MHz con puertos Ethernet de dos gigabits 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 (incluido ADC, DAC, dos veces a través de la red y muchos tratamiento). 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 interruptores en el medio.

Si le preocupa el ancho de banda, debe usar un micro con MAC / PHY integrado en lugar de externo conectado a través de SPI como lo está 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 los datos deben ser manejados por el micro.

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 será 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 funciona a una velocidad de instrucción de 10 MHz. Eso es bastante.

Usted dijo "ethernet", pero no qué tipo de protocolo desea utilizar. Si planea enviar paquetes de Ethernet sin procesar con un ID de protocolo privado o algo así, entonces no hay mucha sobrecarga, 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, será donde irán 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.

Estoy trabajando en un proyecto en el que el pequeño sistema integrado necesita recibir audio con calidad de voz, entre otras cosas. Planeo usar UDP para la transmisión de audio. Tengo un 18F67J60 ejecutando una pila de red completa ya que esta unidad se comunicará a través de TCP también para otros propósitos. La recepción de paquetes UDP es bastante simple, por lo que creo que puede manejar el ancho de banda. Cualquier micro manejo de una pila de red generalmente no es bueno para el procesamiento de baja latencia en tiempo real, por lo que dediqué un micro separado a recibir los datos de audio de transmisión desde el procesador de red a través de SPI en la misma placa. Este procesador utilizará la mayor parte de su RAM como un buffer de muestras. Los datos del procesador de red entrarán en ráfagas, pero se deben escribir a una velocidad constante. Probablemente no pueda implementar la parte de audio de este proyecto durante un mes o dos, así que no puedo decirle qué tan bien funcionó.

He usado Arduino's en 115200 Bd en el pasado en el puerto serie, pero dejé de hacerlo porque de vez en cuando recibía errores de bits. Tal vez un Arduino original tenga un mejor desempeño que mis réplicas chinas de el cheapo, pero no puedo darle ninguna garantía allí. Creo que aquí es de donde viene la regla de oro de 5kByte / s.

No tengo idea del rendimiento de los escudos de Ethernet, probablemente depende de la protección y del poder 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 problema para el procesador.