Aller au contenu

[Tuto] Liaison studio > émetteur avec des raspberryPi


casa36

Messages recommandés

Quand on a besoin de faire la liaison entre le studio et l’émetteur FM de la radio que ce soit en local (via un pont wifi par exemple) ou via ADSL/SDSL/fibre si c'est vraiment éloigné, on a souvent recours à des boitiers type barix pour transporter l'audio et ils sont pour le moins onéreux (400€ pour l'instreamer, 200€ pour l'exstreamer pour les moins chers).

 

Je vous propose donc de remplacer ces boitiers par des RaspberryPi et vous propose deux solutions avec deux logiciels libres OpenOB et le couteau suisse de l'audio/vidéo, j'ai nommé VLC.

 

Coté matériel :

 

- 2 raspberryPi 2 : 40€ l'unité (on peut prendre le modèle B+ pour économiser quelques euros)

- 2 alimentations micro USB : 9€ l'unité

- 2 cartes micro sd 8 Go : 5€ l'unité

- 2 cartes son USB : 13€ l'unité Remarque : il n'y en a besoin dans l'absolu que pour l'encodeur, on peut utiliser la sortie jack du Rpi côté récepteur. On ne trouve cette carte que sur amazon UK (pas trouvé en France), mais a priori toutes les carte son qui fonctionne avec alsa peuvent être utilisées.

- Un boitier : 6€ l'unité

 

Total : 73€ x 2  = 146€

 

Côté logiciel  :

-image raspbian jessie Téléchagerable ici

- Win32 Disk Imager Téléchargeable ici Pour mettre l'image sur la microSD. Sous Linux on peut utiliser la commande dd.

 

 

Je ne détaillerais pas l'installation de raspbian, le net grouille de tutos expliquant comment faire.

 

Avec openOB

 

Solution basée sur RTP et donc avec une faible latence, sur le réseau local c'est presque instantané (inférieur à la seconde). Mais qui ne supporte pas le NAT (voir Attention, plus bas).

 

Prérequis :

 

Installation de python et gstreamer :

sudo apt-get install python-gst0.10 python-setuptools gstreamer0.10-plugins-base gstreamer0.10-plugins-bad gstreamer0.10-plugins-good gstreamer0.10-plugins-ugly gstreamer0.10-tools python-gobject python-gobject-2 gstreamer0.10-alsa libpython2.7-stdlib

Remarque : Dans le tuto original (fait avec la verison whezzy de debian) il est dit d'installer le paquet gstreamer0.10-ffmpeg, hors dans la version jessie ce paquet n’existe plus mais  il n'est apparemment pas indispensable vu que ça fonctionne quand même avec la configuration par défaut.

 

Passons à la suite. Il faut installer également le serveur redis :

sudo apt-get install redis-server

Nous avons besoin de communiquer avec ce serveur pour initialiser la connexion entre émetteur et récepteur pour ça il faut lui indiquer d'écouter sur toutes les adresses IP, pour ça modifier le fichier  : 

sudo nano /etc/redis/redis.conf768

Chercher la ligne "bind" et mette à la place de 127.0.0.1 : 0.0.0.0 (ce qui veut dire toutes les adresses).

 

Pour enregistrer faire Ctrl + o (la lettre, pas zéro) puis pour quitter Ctrl + x

 

Puis pour prendre en compte les modifications :

sudo service redis-server restart

Installation d'openOB :

sudo esay_install OpenOB

Une fois terminé et la procédure répétée sur les 2 raspberry (on peut cloner la carte SD pour aller plus vite) il est temps de transmettre le flux :

 

Sur le récepteur :

openob ip-emetteur nom-node nom-link rx

Où :

-ip-emmeteur : l'ip de l’émetteur (ex : 192.168.1.10)

-nom-node : c'est le nom de la machine, on peut mettre ce qu'on veut (ex : reception)

-nom-link : le nom du lien, doit être identique sur l’émetteur et le récepteur (ex : lien)

-rx : on lui dit d'être récepteur

 

 

Sur l’émetteur :

openob ip-emetteur nom-node nom-lien tx ip-recepteur

Où :

-ip-emmeteur : l'ip de l’émetteur (ex : 192.168.1.10)

-nom-node : c'est le nom de la machine, on peut mettre ce qu'on veut (ex : emission)

-nom-link : le nom du lien, doit être identique sur l’émetteur et le récepteur (ex : lien)

-ip-recepteur : l'ip du récepteur (ex : 192.168.1.20)

-tx : on lui dit d'être émetteur

 

Puis on fait entrée de chaque côté, la magie s'opère et on récupère notre flux à l'autre bout !

 

 

Autres options utiles, à ajouter à la commande de l’émetteur :

-b : spécifier le débit : 192, 256, 320... (par défaut, sans rien renseigner c'est 96 kb/s) l'encodage se fait avec Opus.

-d : pour changer de carte son (sans doute nécessaire sur l’émetteur avec la carte son supplémentaire) par défaut, c'est hw:0,0 (première carte) la carte USB sera surement notée 1 il faudra donc ajouter à la fin de la commande : -d hw:1,0 Le 2nd zéro correspond à une entrée/sortie de la carte, donc ne pas hésiter à tester les autres possibilités pour tomber sur l'entrée ligne si ça ne fonctionne pas.

Pour savoir exactement ce qu'il en est taper : arecord -l qui va renvoyer un résultat du type :
 

pi@raspberrypi ~/openob $ arecord -l**** List of CAPTURE Hardware Devices ****card 1: Device [USB Sound Device], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0

Ici on voit que la carte 1, subdevice 0 est responsable de la capture, mais il se peut si la carte a une entrée micro et une entrée ligne  que ça affiche une autre ligne subdevice #1, ce qui n'est pas le cas ici. Ce qui donnerait -d hw:1,1

Bref, je pense que vous avez compris le principe.

Pour ceux qui maitrisent l'anglais, voici le tuto original : https://jamesharrison.github.io/openob/tutorial.html

Bien évidemment on peut installer le tout sur des PC classiques (en plus là on aura pas besoin de carte son supplémentaire), c'est juste que le Rpi ça prend pas de place.

PS : Malheureusement je n'ai pas pu réellement tester tout ça car je n'ai qu'un seul raspberryPi, mais il n'y a pas de raison que ça ne fonctionne pas. Pour mon test, j'ai utilisé une machine virtuelle debian comme émetteur et le Rpi comme récepteur.

 

 

Attention : Cette solution ne fonctionne pas s'il y'a du NAT (transformation des ip privées en ip publique, ce que font toutes les box des FAI ou les modem/routeur du commerce). Pour s'en servir avec une connexion ADSL, il faut que chaque raspberry soit connecté directement à un modem ethernet (ip publique) de part et d'autre ce qui suppose d'avoir côté studio, une seconde ligne ADSL qui ne s'occupe que de ça. Idem du côté émetteur. Une IP fixe est obligatoire.

 

Il existe bien des méthodes de contournement pour le NAT mais elles sont compliquées à mettre en place.

 

Pour le coup il y a avantage au barix avec son protocole BRTP qui fonctionne à travers un NAT. Il y a juste besoin de rediriger le port RTP sur le routeur du côté instreamer, comme on le ferait avec un autre protocole TCP (http, ftp...)

 

 

Avec VLC

 

Cette solution est beaucoup plus souple, elle permet de traverser les NAT et fonctionne avec presque n'importe quelle connexion, elle repose sur http, comme dans le cas d'un serveur shoutcast/icecast. Par contre les latences sont bien meilleurs (5 sec de décalage, mesuré avec une connexion 3G) alors qu'avec Shoutcast, c'est facile 10s voir plus.

 

Je suppose que raspbian est déjà installé.

 

Installation de VLC

sudo apt-get install vlc libav-tools

Il ne reste plus qu'a taper côté émetteur :

cvlc alsa://hw:0,0 --sout '#transcode{acodec=vorb,ab=128,channels=2,samplerate=44100}:http{mux=ogg,dst=192.168.1.30:8080/radio}' 

-cvlc : lance vlc en ligne de commande

-alsa://hw:0,0 : indique la carte son

-transcode : encode l'entrée ligne au format désiré

-acodec : on choisit le codec, ici j'ai pris le codec libre vorbis

-ab : le débit en kb/s, ici 128

-channels : les canaux, 1 (mono) ou 2 (stéréo)

 

-samplerate : fréquence d’échantillonnage

-http : protocole

-mux : multiplexe le vorbis dans un conteneur ogg

-dst : l'ip locale du Rpi

-8080, le port (on peut mettre ce qu'on veut)

-/radio, indique l'adresse, mais on peut seulement mettre l'ip ça marche aussi

 

Et côté récepteur :

cvlc http://ip-publique-studio:8080/radio

Et on récupère notre flux.

 

Important : Après vérification, pour VLC dans le cas où l’émetteur coupe la connexion (reboot, changement d'ip...) la reconnexion côté récepteur ne se fait pas, et même en ajoutant l'argument --http-reconnect, ça ne fonctionne pas. Il faut obligatoirement rebooter le récepteur ou relancer la commande. Je cherche une solution de contournement.

 

EDIT : Solution finalement trouvé en se servant de mplayer :

sudo apt-get install mplayer2

Il ne reste plus à taper :

mplayer -loop 0 -cache 400  http://ip-publique-studio:8080/radio

-loop 0 : répéter à l'infini

-cache 400 : règle le cache à 400 ko

 

 

Remarque : il vaut mieux avoir une IP fixe côté studio, sinon il faudra mettre en place un service de DNS dynamique (Dtdns, no-ip...) Surtout que quand le changement d'ip se fait, la correspondance avec la nouvelle adresse n'est pas instantanée, il faut compter au moins 30min et pendant ce temps le flux est coupé. Par contre côté émetteur l'ip peut-être dynamique ce n'est pas gênant, et là la coupure ne dure que quelques secondes voir 1 minute le temps du changement. Pour connaitre cette ip visitez http://monip.org

 

Pour accéder au flux de l’extérieur de la radio il faut rediriger la connexion vers le Rpi émetteur, pour ça chercher dans la box (en général 192.168.1.1) la mention NAT/PAT ou redirection de ports.

 

-service : flux (ou le nom qu'on veut)

-port externe : 8080

-port interne : 8080

-protocole : TCP

-ip du Rpi : 192.168.1.30 (exemple)

 

Sauvegarder le tout, et ça devrait fonctionner. Un exemple en image sur une livebox pro V2 :

 

1449524618.png

 

 

 

On va maintenant automatiser le démarrage, en cas de reboot imprévu par exemple pour que ça reparte automatiquement :

 

Créer selon le logiciel choisi :

 

Pour l'emetteur : (on crée un fichier vierge, toujours pareil ctrl + o pour sauvegarder puis crtl + x pour quitter)

sudo nano /etc/init.d/vlc-txsudo nano /etc/init.d/openob-tx

Pour VLC :

#!/bin/sh#/etc/init.d/vlc-txcvlc alsa://hw:0,0 --sout '#transcode{acodec=vorb,ab=128,channels=2,samplerate=44100}:http{mux=ogg,dst=192.168.1.30:8080/radio}' exit 0

Pour pouvoir lancer VLC en tant que root, taper la commande (par défaut il est impossible de le lancer) :

sed -i 's/geteuid/getppid/' /usr/bin/vlc

Pour OpenOB :

#! /bin/sh# /etc/init.d/openob-txopenob 192.168.1.30 emetteur lien tx 192.168.1.10exit 0

Rendre exécutable les scripts :

sudo chmod 755 /etc/init.d/vlc-txsudo chmod 755 /etc/init.d/openob-tx

Ajouter les scripts au démarrage  :

sudo update-rc.d vlc-tx defaultssudo update-rc.d openob-tx defaults

Pour le récepteur :

sudo nano /etc/init.d/mplayer-rxsudo nano /etc/init.d/openob-rx

Pour Mplayer :

#!/bin/sh#/etc/init.d/mplayer-rxmplayer -loop 0 -cache 400 http://ip-publique-studio:8080/radioexit 0

Pour OpenOB :

#!/bin/sh#/etc/init.d/openob-rxopenob ip-emetteur nom-node nom-link rxexit 0

Répéter les autres commandes (vlc, démarrage, exécution).

 

 

Voilà c'est terminé, j'espère que j'ai été assez clair, et si y'a un soucis vous pouvez me poser la question ;)

Lien vers le commentaire
Partager sur d’autres sites

Content de voir que je ne l'ai pas écrit pour rien ! J'ai essayé d'être le plus complet possible, et surtout que ça soit compréhensible pour les débutants ou ceux qui n'ont pas l'habitude de manipuler les fichiers de config linux, etc... mais en principe je m'adresse à des personnes qui ont déjà au moins monté une fois ce type de liaison que ce soit avec des barix ou similaire. Donc les notions d'ip, rtp, soutcast... devraient leur parler un minimum.

Lien vers le commentaire
Partager sur d’autres sites

Chapeau !

 

Faut il un PC sur site pour VLC ?

 

 

Il va falloir que je regarde ça et me paye une paire de rapsberry

 

Au passage si quelqu'un veut des Arduino, j'en ai à vendre moitié prix du neuf avec un tas d'accessoires.

Faites moi un MP, si cela vous intéresse.

Lien vers le commentaire
Partager sur d’autres sites

La franboise étant sous un dérivé de debian (une distribution linux), VLC étant bien évidemment dispo sous debian (et plein d'autres os d'ailleur https://www.videolan.org/vlc/#download ) c'est possible de mettre vlc sur un raspberry, de plus la dernière version du raspberry est dispo sous windows (même si je ne sais pas vraiment ce que ça vaut)

Lien vers le commentaire
Partager sur d’autres sites

Ne connaissant que windows, je vais me documenter sur la framboise à la sauce Gates.

Cela pourrait me donner des idées.

J'utilise parfois des PC sur site pour prise en main à distance de systèmes comme Barix, RDS , traitement de son, etc, je cherche une solution moins volumineuse qu'un PC.

J'ai récupéré des terminaux Wise ou compaq I5000, mais ils sont avec Win CE, et il semble que l'OS soit en ROM donc non modifiable.

 

Si quelqu'un a des idées, il est bienvenu.

Lien vers le commentaire
Partager sur d’autres sites

Et ce matériel est vraiment fantastique. J'en ai qui tournent depuis des années sans aucun problème.

J'ai réalisé des liaisons en deux bonds, le plus que j'ai fait c'est 18km avec des antennes planes.

De plus le pointage est très facile et ne nécessite aucun matériel spécifique comme un analyseur de spectre ou mesureur de champ pour le 8.5Ghz.

Lien vers le commentaire
Partager sur d’autres sites

 

 

Important : Après vérification, pour VLC dans le cas où l’émetteur coupe la connexion (reboot, changement d'ip...) la reconnexion côté récepteur ne se fait pas, et même en ajoutant l'argument --http-reconnect, ça ne fonctionne pas. Il faut obligatoirement rebooter le récepteur ou relancer la commande. Je cherche une solution de contournement.

AS-tu regardé du côté de mplayer pour la reconnexion automatique. Je crois (à vérifier) qu'il gère ça bien mieux que VLC.

Il faut saluer ici le travail de James Harrisson, un passionné de radio outre-manche. Son blog est une source intéressante pour le DIY radio.

Lien vers le commentaire
Partager sur d’autres sites

@balvenie : Pour la prise en main à distance du traitement de son et autre, le Rpi fonctionne très bien on peut aussi utiliser n'importe quel PC sous linux. C'est valable aussi pour ce tuto qui peut-être réalisé avec des PC de récup par exemple, c'est juste que les Rpi c'est tout petit et ils ont une consommation très faible (moins de 5 w) et surtout ils ne coutent que 40€.

 

Donc pour la prise en main a distance, il suffit d'ouvrir une connexion ssh et de réaliser une redirection de ports via la commande sous Linux :

ssh user@ip-publique-de-l'emmeteur -D 127.0.0.1:1234

Ensuite avec firefox par exemple, il faut renseigner un proxy socks avec 127.0.0.1 comme ip et 1234  comme port, et à partir de là il suffit de taper l'ip local des équipements dans le navigateur et on y accède comme si on était branché sur le réseau local de l'émetteur (qui je suppose ici est derrière un routeur). La connexion est totalement sécurisée.

 

On peut faire la même chose sous windows avec putty pour se connecter au Rpi.

 

+1 également pour les ubiquiti, je m'en suis acheté une paire pour remplacer une liaison CPL qui était désastreuse et là je tourne à 100mbps en permanence depuis plusieurs mois sans soucis. Ça fonctionne très bien en intérieur avec des cloisons au milieu.

 

 

@palma : Merci pour le tuyau, je vais examiner ça de plus près.

 

@Sam : ah j'y ai pas pensé, faudra que je test, mais en fait le problème c'est que j'ai l’impression qu'il ne détecte pas qu'il a perdu la connexion car le temps arrête de défiler, mais il n’affiche pas de message d'erreur (et dans ce cas il essaie de s'y connecter jusqu’à ce qu'il y arrive).

 

@ : Peut-être je sais pas trop ça dépendra si j'ai un peu de temps, pour celui-ci entre la rédaction, la mise en forme les copier/coller et les test divers et variés, j'ai mis 2 jours.

Lien vers le commentaire
Partager sur d’autres sites

Avec l'aide de palma et de sam, j'ai trouvé la solution pour reconnecter le flux :

mplayer -loop 0 -cache 400  http://ip-publique-studio:8080/radio

Et voilà le travail !

 

Avec mplayer juste en lisant le flux, quand ça coupe, il s'en rend compte et arrête la commande. Donc il suffit de rajouter l'option loop (boucle) et 0 pour lui dire de répéter à l'infini et hop ça se reconnecte tout seul ! Par contre j'ai quelques problème de micro-coupures, j'ai du augmenter le cache, ici à 400 ko à part ça c'est nickel. Avec 400 ko de cache, la latence est toujours de 5 sec donc c'est bon.

 

Je vais donc modifier le tuto en conséquence.

Lien vers le commentaire
Partager sur d’autres sites

@casa 36, ce que tu dis est sans aucun doute très intéressant, mais hélas je n'y comprends rien.

 

De mon temps l'informatique c'était sur cartes perforée et lecteur magnétiques.

Le premier ordinateur (industriel) que j'ai croisé en 1973, disposait d'une mémoire à tores de 64K et servait à tracer sur une bande carol des graphiques à partir de données entrées sur un telex.

Ceci a eu une très grande répercussion sur ma vie............ j'ai épousé l'opératrice qui tapait sur le télescripteur.

Le graphique ne consistait qu'en une succession de X imprimés sur la bande carol...

L'ordinateurs se programmait par des clés sur la face avant, il tenait dans une baie 19" de 2m de haut il y avait alors deux informaticiens qui le programmaient.

 

 

Tout cela pour dire que je me suis mis à l'informatique en 81 en achetant justement un ZX81, 8K de ram et programmation en basic (de base)

Depuis tout y est passé en passant par les ORIC, la gamme quasi complète Sinclair, les Amstrad, et d'autres pour arriver en 1984 à un PC 8080 avec disquette 5"1/4, sans disque dur et sous  DOS (super les tableurs et traitements de texte sur écran monochrome vert ou orange).

A ce stade les Amstrad et apple étaient bien plus performants que les PC.

Il aura fallu qu'un boutonneux américain s'y mettre pour arriver à un interface plus convivial que le DOS.

 

Mais je n'ai jamais dépassé le stade programmation, faute de temps et de volonté sans doute. Et maintenant c'est un peu tard.

Lien vers le commentaire
Partager sur d’autres sites

Bonsoir

 

je me souviens de mon premier pc sous Dos je l'avais installe et désinstalle je ne sais combien de fois

j'ai souvenir des disquettes 5"1/4 et le bruit des lecteurs, put* de souvenir on faisait des petits programmes

avec je ne me souviens plus le nom du logiciel, on touchait l'autoexec.bat pour le démarrage on avait l'architecture

du disque sous pc Tools, puis après est venu Windows 3.11 avec les premières souris, tu réveille de sacrée souvenir

chez moi, a nostalgie quand tu nous tiens.

 

Philippe

Lien vers le commentaire
Partager sur d’autres sites

@baliverne : Moi non plus je comprenais rien au début, je vais t'expliquer un peu mieux. Ce que je t'ai indiqué c'est en fait pour créer un tunnel comme un VPN entre ton réseau local (ou celui du studio) et celui de l'émetteur, sauf que ça passe par une connexion SSH (la version sécurisée du telnet si ça te parle mieux) qui permet de commander un système à distance, comme VNC ou teamviewer mais en ligne de commande, et qui permet de faire de la redirection de ports ce qui crée une sorte de tunnel entre les deux. Du coup tu peux avoir accès aux équipements comme si tu étais connecté sur le réseau local de l’émetteur.

 

Une doc plus complète Ici

Lien vers le commentaire
Partager sur d’autres sites

  • 7 months later...

Salut casa36, je reviens vers toi pour une petite question "pratique". J'ai mis en place le système sur un Rasp et ça fonction à merveille. Maintenant en cas de coupure du signal internet, il est possible selon toi d'intégrer un système de fichier aléatoire avec de la musique qui viendrait combler le blanc ? Donc le flux une fois déconnecté, Mxplayer passe à un fichier musical (tiré d'un dossier de musiques) et après avoir joué une chanson, tente de se reconnecter au stream ? 

Lien vers le commentaire
Partager sur d’autres sites

  • 2 weeks later...

@mrmazure Salut, (désolé pour la réponse tardive)

 

ça doit être possible en faisant une liste de lecture voir un script bash, mais je ne suis pas assez calé pour l'écrire.

 

Pour la liste de lecture si on considère que le morceau est fixe je pense qu'il suffit de mettre le flux http puis une musique, puis le flux, etc... dans un m3u. Je testerais pour confirmer.

 

Sinon la commande mplayer pour lire en aléatoire c'est

mplayer -shuffle ~/dossier_musique/*
Lien vers le commentaire
Partager sur d’autres sites

Archivé

Ce sujet est désormais archivé et ne peut plus recevoir de nouvelles réponses.

×
×
  • Créer...