javascript - play - web audio api 2018

Web Audio API para transmisión en vivo? (3)

Necesitamos transmitir audio en vivo (desde un dispositivo médico) a navegadores web con no más de 3-5 segundos de retraso de extremo a extremo (supongamos 200 ms o menos de latencia de red). Hoy usamos un complemento de navegador (NPAPI) para decodificar , filtrar (alto, bajo, banda) y reproducir la secuencia de audio (entregada a través de Web Sockets).

Queremos reemplazar el complemento.

Estaba viendo varias demostraciones de Web Audio API y parece que la mayor parte de nuestra funcionalidad requerida (reproducción, control de ganancia, filtrado) está disponible en Web Audio API . Sin embargo, no me queda claro si Web Audio API se puede usar para fuentes transmitidas, ya que la mayoría de la API de Web Audio hace uso de sonidos cortos y / o clips de audio.

¿Se puede usar Web Audio API para reproducir audio transmitido en vivo?

Actualización (11-feb-2015):

Después de un poco más de investigación y prototipos locales, no estoy seguro de que la transmisión de audio en vivo con Web Audio API sea posible. Como DecodeAudioData de la API de Web Audio no está diseñado para manejar fragmentos aleatorios de datos de audio (en nuestro caso, entregados a través de WebSockets). Parece necesitar todo el ''archivo'' para procesarlo correctamente.

Ver stackoverflow:

Ahora es posible con createMediaElementSource conectar un elemento <audio> a Web Audio API, pero mi experiencia es que el elemento <audio> induce una gran cantidad de retardo de extremo a extremo (15-30 s) y no lo hace. Parece que hay algún medio para reducir la demora por debajo de 3-5 segundos.

Creo que la única solución es usar WebRTC con Web Aduio API. Esperaba evitar WebRTC, ya que requerirá cambios significativos en nuestra implementación en el servidor.

Actualización (12-feb-2015) Parte I :

No eliminé completamente la etiqueta <audio> (necesito terminar mi prototipo). Una vez que lo he descartado, sospecho que createScriptProcessor (obsoleto pero aún compatible) será una buena opción para nuestro entorno, ya que podría ''transmitir'' (a través de WebSockets) nuestros datos ADPCM al navegador y luego (en JavaScript) convertirlo a PCM Similar a lo que a la biblioteca de Scott (ver abajo) lo hace usando el createScriptProcessor. Este método no requiere que los datos estén en "trozos" del tamaño adecuado y el tiempo crítico como el enfoque DecodeAudioData.

Actualización (12-feb-2015) Parte II :

Después de más pruebas, eliminé la interfaz de <audio> a Web Audio API porque, dependiendo del tipo de fuente, la compresión y el navegador, la demora de extremo a extremo puede ser de 3 a 30 segundos. Eso deja el método createScriptProcessor (ver la publicación de Scott a continuación) o WebRTC. Después de conversar con nuestros tomadores de decisiones, se decidió que adoptaremos el enfoque de WebRTC. Supongo que funcionará. Pero requerirá cambios en nuestro código del lado del servidor.

Voy a marcar la primera respuesta, solo para que la ''pregunta'' esté cerrada.

Gracias por su atención. Siéntase libre de agregar comentarios según sea necesario.

Escribí un sistema de API de Web Audio en tiempo real donde utilicé a los trabajadores web para hacer toda la administración de sockets web para comunicarme con node.js de modo que el hilo del navegador simplemente reproduzca audio ... funciona bien en las computadoras portátiles, ya que los dispositivos móviles están retrasados en su implementación de sockets web dentro de los trabajadores web, necesitas nada menos que lollipop para que se ejecute como codificado ... Publiqué el código fuente completo aquí

Para profundizar en los comentarios sobre cómo jugar un montón de almacenamientos intermedios separados almacenados en una matriz cambiando el último cada vez:

Si crea un búfer a través de createBufferSource() entonces tiene un evento onended al que puede adjuntar una devolución de llamada, que se activará cuando el búfer haya llegado a su fin. Puede hacer algo como esto para reproducir los diversos fragmentos de la matriz uno tras otro:

function play() { //end of stream has been reached if (audiobuffer.length === 0) { return; } let source = context.createBufferSource(); //get the latest buffer that should play next source.buffer = audiobuffer.shift(); source.connect(context.destination); //add this function as a callback to play next buffer //when current buffer has reached its end source.onended = play; source.start(); }

Espero que ayude. Todavía estoy experimentando sobre cómo hacer que todo esto se suavice y se solucione, pero este es un buen comienzo y falta en muchas publicaciones en línea.

Sí, la API de Web Audio (junto con AJAX o Websockets) se puede usar para la transmisión.

Básicamente, tiras hacia abajo (o envías, en el caso de Websockets) algunos fragmentos de n longitud. Luego los decodifica con Web Audio API y los pone en cola para que se reproduzcan, uno después del otro.

Debido a que Web Audio API tiene un tiempo de alta precisión, no escuchará ninguna "brecha" entre la reproducción de cada búfer si realiza la programación correctamente.