Bon c'est pas tout à fait un cacadavre exquis vu que c'est une collab à distance, mais y'a une progression à tour de rôle avec les éléments que chacun ont conçu au préalable, alors …
Si vous avez des envies folles, stimulez vos connexions neuronales (avec ou sans drogues) et complétez.
Quelqu'un a pu récupérer l'enregistrement de notre joyeux plantage au CCL? fab> mince non j'ai pas demandé mais le pote est en plein déménagement et son ordi risque de rester au placard tout l'été, j'redemanderai à tout hasard.
Cross FM synthesis : L'article de François Pinot @ Csound journal
Tour d'horizon…
PD Vanilla ne contient aucun outil pour envoyer du son par le réseau. Il peut par contre envoyer des données (avec netsend).
Différents plugins ont été conçus:
puredata-dev
pour compiler.udpreceive~: got incomplete header tag
quand on s'envoie des données par UDP (sur des architectures d'ordi différentes: 32 et 64bits).This is a fork of martin peach's “net” library, that allows low-level interaction with networks on OSI-layer 5 (transport layer).
Conclusion ⇒ le netsend intégré à puredata, c'est mieux.
Une solution de streaming généraliste. Sert pour des radios web. Le hic: de façon interne, le logiciel induit un décalage (temps d'encodage, tampon…) entre la source sonore et le moment auquel elle est émise. N'est pas prévu pour un truc qui se joue à la seconde près.
La latence est de l'ordre de 15 secondes d'après mon expé et témoignages internet, en règlant les buffers certains disent qu'on peut la descendre mais ça a l'air inexploitable.
Darkice peut servir à récolter le flux sur la machine du “DJ”. Tandis que Icecast sert à diffuser le son vers le “public”.
butt semble s'être popularisé comme interface simple de diffusion destinée aux artistes/diffuseurs.
Développement actif.
Opensource + Codec Opus + Windows/Mac/Linux (jack).
Pas de binaire distribué pour plateformes Linux, nécessite d'être compilé.
Développement actif, au point sous Mac OS X mais pas trop sous Linux.
Permet de pallier à la latence en faisant jouer les séquences avec un retard prédéfini pour synchroniser les sons. Vieil outil mais pourrait encore marcher aujourd'hui. → N'est plus maintenu depuis 2005.
Un client libre, JamTaba2, est encore entretenu code sur GitHub. Problème, libqt5multimedia ne gère pas JACK, et le projet ne semble pas maitriser la situation.
Un tuyau réseau pour le système audio JACK. Fonctionnerait, mais JACK n'est pas dispo sous Windows… quoique: http://www.jackaudio.org/netjack, le site indique que c'est aussi dispo sous Windows. Jack.trip ne l'est pas. Netjack2 ne semble pas passer par un WAN (uniquement LAN). Netjack1 semble tolérer les pertes de données, donc fonctionne par WAN.
zita-njbridge est packagé dans Debian, semble le plus cool !
Tiré de : https://ikiwiki.laglab.org/SoundNet/
Mumble est une solution de VoIP, comme Skype/Teamspeak, utilisée surtout par les joueurs de jeux vidéos. L'outil gère désormais JACK en plus de ALSA et Pulseaudio. Cependant, un seul bus (mono ou stereo) est utilisé pour faire transiter l'ensemble des voix des intervenants : on ne peut donc pas séparer les flux réseau en sortie.
Mumble essaie d'ouvrir son architecture, notamment via ICE. Voir le wiki : https://wiki.mumble.info/wiki/Main_Page
Malheureusement, ICE est surtout utilisé pour script le client, et je n'ai pas trouvé d'outil qui permettrait de manipuler les routes des flux audio.
Mentionné sur le forum Hydrogenaudio en 2013.
Il faut s'inscrire pour télécharger le truc, aucune idée de si le projet est encore actif.
Ils sont tarés ils veulent que ça fonctionne en P2P.
Flux audio faible latence qui possède une implémentation libre.
Il faut compiler… pas essayé.
Un nouveau codec standardisé, libre, faible latence et de bonne qualité.
Applications listées peu pertinentes. On y trouve webrtc (c'est à dire une boite noire dans le navigateur et mal gérée par Firefox). Eventuellement, un serveur WebRTC pourrait faire le job.
Et Jitsi, retiré de Debian en 2017.
Semble ne pas évoluer mais est entretenu.
Directement avec JACK, fonctionne sur un modèle Master/Slave.
J'avais testé en réseau local, il fallait une latence un peu réhaussée, et il a tout de même tendance aux xruns.
Un autre problème est que l'ordi en Slave ne récupère pas son propre canal audio transmis par le réseau, et qu'il n'a aucun retour de la part de Master.
C'est donc conçu pour des ordis qui diffusent depuis une même pièce, avec un unique dispositif de reproduction sonore.
Note: pas grand chose d'entretenu par ici: http://wiki.linuxaudio.org/apps/other_apps#network_audio
Pas de conclusion !