{{>toc}}

h1. StreamingAudio

<tth> C'est une idée qui m'est venu trois semaines avant le [[THSF2014]], et dans laquelle je me suis lancé sans savoir que ce n'est pas si simple que ça, le streaming audio, quand on n'y connait rien. J'ai donc choisi un truc simple et précis : 3 canaux audio sur le LAN [[Myrys]], éventuellement relayables vers le Ternet.

# /blabla - mono/22050 - un micro directement branché sur le serveur.

# /zik - stéréo/44100 - injecté depuis le LAN par un laptop "michu compliant".

# /waves - stéréo/44100 - une playlist random stockée sur le serveur.

Le tout encodé en .ogg, avec une qualité qui reste à déterminer expérimentalement, en direct-live, courageusement,pendant ces quatre jours de folie qui nous attendent.

_5 juin 2014, petit bilan post thsf :_ globalement, ça a bien fonctionné, mais toujours avec une charge trop faible pour que ce soit significatif. Le plus gros souci a été avec le laptop source en wifi, qui ne tient pas bien avec un flux 44100/stéréo/ogg. Je n'ai pas encore assez d'expérience pour comprendre d'où ça vient et si ce n'est pas juste un réglage de taille de buffer. Coté utilisation, il y a eu quelques morceaux de l'évènement qui ont été envoyés d'un recoin de la halle au bar de la bulle. Si la source est en ethernet, ça marche. 

h2. Icecast, maitre des bits

Il existe probablement d'autres solutions, mais celle-ci est un grand classique, et à mon age, vous savez...

* http://www.icecast.org/docs/icecast-latest/

h2. Source Clients

Un @source client@ est un logiciel qui se connecte au serveur icecast pour lui envoyer le son. Ce son peut provenir de différentes sources.

h3. Real OSes

* http://www.icecast.org/docs/ices-latest/faq.html il peut envoyer depuis ALSA ou depuis une playlist de fichiers

** http://www.6809.org.uk/media/ices2-howto.shtml

* http://www.icecast.org/ezstream.php

* http://code.google.com/p/darkice/

* http://mixxx.org/wiki/doku.php/internet_broadcasting

h3. Android

Des expérimentations sont programmables : http://lists.tetaneutral.net/pipermail/technique/2014-July/001433.html

h3. Others

<tth> MacOSX et windows me sont totalement étranger, please help me ! 

h2. Players

h3. Sal^Wwindows

* http://www.foobar2000.org/

h2. libshout

_libshout is a library for communicating with and sending data to an icecast server. It handles the socket connection, the timing of the data, and prevents bad data from getting to the icecast server._ http://www.aelius.com/njh/libshout-doc/libshout.html

h2. Exemples de mise en œuvre :

h3. Place Belfort

28 juin 2014, repas de quartier de la place Belfort. Contact local : +Progeas+.

Streaming d'un micro-trottoir à partir d'un ordinateur portable avec le wifi et un microphone stéréo. Nous comptons utiliser un serveur icecast dans une VM à Myrys avec une IPv4 publique et, coté source, un _source client_ ices2 sur un petit netbook avec sa carte son intégrée. Le lien source -> icecast sera fait par l'ADSL d'un résident de la place Belfort. Il est problable que nous ayons besoin d'un point d'accès dédié accroché sur une façade. 

h3. Interface avec Mumble.

D'après http://en.wikipedia.org/wiki/Mumble_%28software%29 : « Mumble est un logiciel libre de voix sur IP (VoIP), son principal usage étant la communication pendant les parties de jeux en réseau. » donc un truc qui permet de faire en temps réel des audio-conférences, ou de répéter une scène de théatre. Et quand on fait un _état de fabrique_, on peut avoir envie d'en faire profiter ses amis lointains. D'où l'idée d'une *passerelle mumble -> icecast*. Que nous allons devoir inventer.

h2. Conclusion

Je me demande même, avec un objectif comme celui-ci, on ne pourrait pas aboutir à un live-cd spécialisé ou une carte genre Raspi qui ne fasse que ça, ce que les cravateux appellent une "appliance". À condition que PG n'envisage même pas en rêve de rajouter un gazillion de fritures. Je vais continuer à explorer les voies possibles.

*tTh.*