Web Audio API pour la diffusion en direct?

Nous avons besoin de diffuser de l'audio en direct (d'un périphérique médical) vers des navigateurs Web avec pas plus de 3 à 5 de retard de bout en bout (supposons une latence de 200 mS ou moins de réseau). Aujourd'hui, nous utilisons un plugin de navigateur (NPAPI) pour le décodage , le filtrage (haut, bas, bande) et la lecture du flux audio (livré via les Sockets Web).

Nous voulons remplacer le plugin.

Je regardais diverses démonstrations de Web Audio API et la plupart de nos fonctionnalités requises (lecture, contrôle de gain, filtrage) semblent être disponibles dans Web Audio API . Cependant, il n'est pas clair pour moi si l'API Web Audio peut être utilisée pour les sources diffusées puisque la plupart des API Web Audio utilisent des sons courts et / ou des clips audio.

L'API Web Web peut-elle être utilisée pour diffuser de l'audio en direct?

Mise à jour (11-février-2015):

Après un peu plus de recherche et de prototypage local, je ne suis pas sûr que la diffusion audio en direct avec Web Audio API soit possible. Comme le décodeAudioData de Web Audio API n'est pas vraiment conçu pour gérer des blocs aléatoires de données audio (dans notre cas livré via WebSockets). Il semble avoir besoin de tout le «fichier» pour le traiter correctement.

Voir stackoverflow:

  • Comment diffuser des données MP3 via WebSockets avec node.js et socket.io?
  • Définir 'morceau mp3 valide' pour decodeAudioData (API WebAudio)

Maintenant, il est possible avec createMediaElementSource de connecter un élément <audio> à l'API Web Audio, mais il a été mon expérience que l'élément <audio> induit une énorme quantité de délai de bout en bout (15-30s) et qu'il n'y a pas de " T semble être un moyen de réduire le délai en dessous de 3 à 5 secondes.

Je pense que la seule solution consiste à utiliser WebRTC avec Web Aduio API. J'espérais éviter WebRTC car il faudra des changements importants dans notre implémentation côté serveur.

Mise à jour (12-février-2015) Partie I :

Je n'ai pas complètement éliminé la <audio> (j'ai besoin de terminer mon prototype). Une fois que je l'ai écarté, je pense que le createScriptProcessor (déconseillé mais toujours pris en charge) sera un bon choix pour notre environnement car je pourrais «diffuser» (via WebSockets) nos données ADPCM vers le navigateur et ensuite (en JavaScript) le convertir en PCM. Comme pour la bibliothèque de Scott (voir ci-dessous), utilisez le createScriptProcessor. Cette méthode ne nécessite pas que les données soient dans des "morceaux" de taille appropriée et une synchronisation critique comme approche decodeAudioData.

Mise à jour (12-février-2015) Partie II :

Après plus de tests, j'ai éliminé l'interface de l'interface <audio> pour Web Audio car, selon le type de source, la compression et le navigateur, le délai de bout en bout peut être de 3 à 30s. Cela laisse la méthode createScriptProcessor (voir la publication de Scott ci-dessous) ou WebRTC. Après avoir discuté avec nos décideurs, il a été décidé que nous adopterons l'approche WebRTC. Je suppose que cela fonctionnera. Mais il faudra des modifications sur notre code côté serveur.

Je vais marquer la première réponse, alors la «question» est fermée.

Merci d'avoir écouté. N'hésitez pas à ajouter des commentaires au besoin.

Oui, l'API Web Audio (avec AJAX ou Websockets) peut être utilisée pour le streaming.

Fondamentalement, vous abaissez (ou envoie, dans le cas de Websockets), des morceaux de n longueur. Ensuite, vous les décodez avec l'API Web Audio et faites-les en attente pour être lues l'une après l'autre.

Parce que l'API Web Audio dispose d'un chronométrage de haute précision, vous n'entendrez aucune "couture" entre la lecture de chaque tampon si vous faites correctement la planification.

J'ai écrit un système de streaming Web Audio API où j'ai utilisé les web-workers pour faire toute la gestion du socket Web pour communiquer avec node.js de sorte que le thread du navigateur rend l'audio … fonctionne très bien sur les ordinateurs portables, car les mobiles sont en retard sur leur mise en œuvre Des sockets web dans les web-workers, vous n'avez besoin que d'un lollipop pour qu'il fonctionne comme codé … J'ai publié un code source complet ici

Pour élaborer les commentaires sur la façon de jouer un ensemble de tampons distincts stockés dans un tableau en décalant le dernier en tous les temps:

Si vous créez un tampon via createBufferSource() il dispose d'un événement sur lequel vous pouvez joindre un rappel, qui déclenchera lorsque le buffer aura atteint sa fin. Vous pouvez faire quelque chose comme ça pour jouer les différents morceaux dans le tableau l'un après l'autre:

 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(); } 

J'espère que cela pourra aider. Je suis toujours en train d'expérimenter sur la façon d'obtenir ce tout doux et repassé, mais c'est un bon début et manque dans beaucoup de publications en ligne.