StreamingAudio » Historique » Version 12
Version 11 (Thierry Boudet, 15/07/2014 20:05) → Version 12/19 (Mehdi Abaakouk, 16/07/2014 09:58)
{{>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
Peut être celui la: https://play.google.com/store/apps/details?id=com.itechnepal.net.mylivecast
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.*
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
Peut être celui la: https://play.google.com/store/apps/details?id=com.itechnepal.net.mylivecast
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.*