Transmisión de audio y duda udp

3

Estoy haciendo un proyecto, donde tengo que decodificar una secuencia de audio mp3 que recibo de un servidor web, con un pic32 sobre Ethernet. Mi duda es:

¿Qué pasa si el servidor envía más datos de los que la imagen puede manejar? Quiero decir, ¿puedo controlar la cantidad de paquetes que me envía el servidor? Porque si solo hay un dispositivo conectado a la web, el servidor enviará todas las canciones mp3 sin esperar, y la memoria de imágenes no será suficiente.

¿Cómo puedo resolver este problema?

    
pregunta Bruno

3 respuestas

2

Si utiliza un protocolo de transmisión adecuado como RTSP, el servidor enviará los paquetes a la velocidad correcta.

    
respondido por el pjc50
0

UDP no proporciona control de flujo. Si necesita que use tráfico TCP O , los protocolos superiores tendrían que implementar el control de flujo, pero el http básico tampoco proporciona control de flujo. Como la mayoría de estos flujos de datos son en tiempo real o basados en TCP, dudo que alguno de los protocolos de higer tenga implementado el control de flujo. Mi corazonada es que tienes que cambiar a TCP.

    
respondido por el jippie
0

Si puede controlar el servidor, pídale que envíe los datos a la tasa promedio correcta a largo plazo. Entonces, el PIC solo necesita lidiar con la explosión. Con un búfer lo suficientemente grande, todo debería funcionar.

Inevitablemente, los dos relojes estarán un poco apagados. El promedio a largo plazo de cada uno debe ser tan bueno como su cristal. Para ser pesimista, figura 50 ppm de cristales en ambos extremos, así que diseña hasta 100 ppm de desajuste a largo plazo. Esto puede ser tratado de varias maneras. Simplemente podría replicar la última muestra en el buffer underrun y omitir una muestra en la saturación, ya que en teoría cada evento será relativamente raro. O bien, puede cambiar ligeramente la velocidad de reproducción según la cantidad de datos en el búfer. A los usuarios de audio no les va a gustar eso, pero no es diferente a las oscilaciones de las grabadoras desde hace mucho tiempo. Por debajo de algún nivel es todo lo suficientemente bueno. Si este sonido es de voz, puedes salirte con mucho más que si un músico profesional está escuchando música.

En cualquier caso, no, no quieres usar TCP. Eso agregará tanta sobrecarga en el extremo PIC que es posible que no pueda manejar la transmisión de audio. No hay necesidad de entrega confiable aquí. Si hay un error, el error de salida, pero luego desea continuar y continuar normalmente lo más rápido posible. TCP no es adecuado para eso.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas