Pregunta

quiero escribir algo como Skype, es decir, tengo una corriente constante de audio en una computadora y luego Recomprimir en un formato que es adecuado para una conexión a Internet latente, lo reciben en el otro extremo y reproducirlo.

Supongamos también que la conexión a Internet es bastante moderno y rápido, es decir, DSL o iguales, no hay conexiones lentas a través del teléfono y tal. Los equipos implicados también estarán (CPU Intel de doble núcleo a 2GHz o más) en lugar modernas.

Yo sé cómo manejar el audio en las máquinas. Lo que no sé es cómo transmitir el audio de una manera eficiente.

Los desafíos son:

  1. Me gustaría conseguir una buena calidad de audio a través de la línea.

  2. La corriente debe ser recibida sin gotas. La corriente puede, sin embargo, ser recibido con un poco de retardo (un segundo retardo es aceptable). Me imagino que el primer software de transporte podría determinar la latencia media (y máximo), a continuación, iniciar la corriente y decirle al receptor que esperar a que la latencia máximo antes de comenzar a reproducir el audio. Con eso, si la latencia no hay nada más alto, toda la corriente se podrá jugar en el otro lado sin tartamudeo o gotas.

  3. Si, debido a las latencias IP inesperadas o bloqueos, la corriente hace conseguir cortado, yo quiero ser capaz de darse cuenta de esto para que pueda tomar las acciones (por ejemplo, interrumpir la corriente) y, finalmente, iniciar una nueva transmisión.

¿Cuáles son mis opciones si no quiero utilizar el software ya preparado para la compresión y tranmission? No tengo intención de escribir mi propio motor de compresión de audio, de verdad. Otoh, pienso vender la solución en un mercado vertical, lo que significa que puedo pagar unos pocos dólares de derechos de licencia por copia, pero no $ 100s.

Creo que la solución más sencilla sería la de simplemente abrir un flujo TCP, enviar algunos paquetes de ida y vuelta para determinar su tiempo de funcionamiento (o incluso utilizar UDP para eso), a continuación, utilizar los resultados como la guía para mi valor de latencia máximo , entonces simplemente despedir a los datos de audio en su forma cruda (sin comprimir estéreo de 16 bits), junto con un código de tiempo en la conexión TCP. El receptor lee los datos y la juega con el retardo de pre-determinado. Eso podría trabajar con el tipo de conexión rápida que espero.

Me pregunto si hay mejores soluciones para alcanzar este objetivo, con un mejor rendimiento (menor latencia) y menos datos (comprimido).

Por cierto, lo primero que trato de poner en práctica esta en OS X, pero puede ser que desee hacerlo en Windows, también, si tiene éxito.

¿Fue útil?

Solución

Para la transmisión de audio a través de Internet, probablemente debería buscar en el uso de RTP. Se utiliza para SIP, H.323, y muchos otros utilizan esto para la transmisión de contenido de audio. Incluso puede ser que desee mirar simplemente utilizando un lirbary SIP. Ya cuenta con gran parte de lo que suena desea. SIP puede tener muy buena calidad si tiene un buen códec, y ancho de banda suficiente.

Otros consejos

VLC soporta varios tipos de audio y la codificación de vídeo. Podría ser algo que desea echa un vistazo a .

Sé que es una especie de hilo, un viejo, sin embargo, una visión que yo quiero compartir con ustedes es la siguiente: no se puede utilizar TCP para esto que usted está tratando de hacer debido a la latencia que necesite - usted dijo 1 segundo es aceptable, y de que supongo que más de 1 segundo no lo es.

Su latencia con TCP no está determinada con PING para el anfitrión. El problema con el TCP es que cuando se conecta, y usted acepta que vivir con cierta latencia, cualquier problema con una conexión se reducirá la ventana TCP, todos los datos que se recibieron se redujo y el protocolo subyacente tendrán que manejar la situación. En este momento, perderá su ventaja sobre 1seg en tiempo real y la corriente será dado de baja.

TCP es buena para la situación en la que grandes retrasos son aceptables (por ejemplo, 10 segundos o más) que permitirá que usted siempre tenga suficientes datos para comer y jugar antes de que se restablezca la conexión.

Si estuviera en sus zapatos, voy a tratar lo siguiente:

  • UDP para el transporte
  • alguna de bajo retardo de codificación - AAC-LD por ejemplo, pero también serían mp3 Aceptar
  • tener un poco de matemática sobrecarga de puesta a punto sobre el protocolo UDP por lo que si se pierde un paquete, flujo de audio se puede recuperar.

Por cierto, en los marcos de mp3 son 40msec larga. Con un poco de 'magia' que podría enmascarar algunas pérdida de fotogramas.

SHOUTCast + SAM Transmisor o Winamp. Hará el truco fácilmente.

Si usted está buscando para iniciar su propia estación de radio por Internet usando icecast2 se puede:

  • instalar icecast en su VPS
    #sudo apt-get install icecast
  • instalar ezstream también de que VPS
    #sudo apt-get install ezstream
  • crear un archivo de lista de reproducción con sus archivos

playlist.m3u (se puede leer más forma Wikipedia )

    #EXTM3U

    #EXTINF:123, Sample artist - Sample title
    Sample.mp3

    #EXTINF:321,Example Artist - Example title
    Example.ogg
  • crear un archivo de configuración XML ezstream

config.xml

<ezstream>
    <url>http://localhost:8000/stream</url>
    <!--
      If a different user name than "source" should be used, set it in
      <sourceuser/>:
     -->
    <!-- <sourceuser>mr_stream</sourceuser> -->
    <sourcepassword>hackme</sourcepassword>
    <format>MP3</format>
    <filename>playlist.m3u</filename>
    <stream_once>1</stream_once>
    <svrinfoname>My Stream</svrinfoname>
    <svrinfourl>http://www.oddsock.org</svrinfourl>
    <svrinfogenre>RockNRoll</svrinfogenre>
    <svrinfodescription>This is a stream description</svrinfodescription>
    <svrinfobitrate>128</svrinfobitrate>
    <svrinfochannels>2</svrinfochannels>
    <svrinfosamplerate>44100</svrinfosamplerate>
    <svrinfopublic>0</svrinfopublic>
</ezstream>

O puede probar esto: nodejs aplicación

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top