Diffusion radiophonique sur Internet avec SHOUTcast
1.
Mise en place du serveur SHOUTcast
Installation des fichiers
Le serveur SHOUTcast est situé dans media-sound/SHOUTcast-server-bin. Vous
pouvez l'installer avec la commande suivante :
Exemple de code 1.1 : Installer SHOUTcast |
# emerge shoutcast-server-bin
|
Le serveur SHOUTcast est désormais installé. La prochaine étape consiste à
configurer votre nouveau serveur SHOUTcast.
Configurer votre serveur SHOUTcast
Maintenant que le serveur SHOUTcast est installé, il doit être configuré. Le
fichier de configuration se trouve dans
/etc/shoutcast/sc_serv.conf. Passons maintenant à la configuration
en soi. Assurez-vous d'être connecté en root et ouvrez le fichier de
configuration avec votre éditeur favori. Pour l'exemple, nous choisirons vi.
Nous allons maintenant ouvrir le fichier avec vi :
Exemple de code 1.2 : Ouvrir le fichier de configuration |
# vi /etc/shoutcast/sc_serv.conf
|
Nous pouvons maintenant voir le fichier de configuration. À partir de là, vous
verrez le fichier de configuration et les différentes options que vous pouvez
configurer. Jetons un coup d'œil sur comment les configurer.
Options obligatoires
Note :
N.D.T. : nous garderons les commentaires en anglais pour coller le
plus possible au fichier de configuration. Des explications en français suivent
chaque paramètre.
|
Exemple de code 1.3 : Choisir la limite d'utilisateurs |
MaxUser=10
|
C'est ici que nous indiquons le nombre maximum d'utilisateurs. Comme l'indique
le commentaire, il est stupide de mettre 100 utilisateurs lorsqu'on ne dispose
que de 256 Kb/s d'upload (c'est pourquoi nous avons choisi de mettre 10,
dans la mesure où la connexion utilisée pour l'exemple est effectivement de
256 Kb/s en upload). Si vous utilisez le serveur SHOUTcast pour une radio
sur un réseau local, vous pouvez mettre un nombre bien plus important
(facilement 100).
Souvenez-vous qu'il ne faut pas abuser non plus de la bande passante dont vous
disposez. La bande passante coûte cher aux fournisseurs d'accès Internet et
certains d'entre eux pourraient couper votre compte par exemple, car vous
abuseriez d'eux, dans un sens.
Exemple de code 1.4 : Configurer le mot de passe |
Password=un_mot_de_passe_solide
|
C'est ici que vous indiquerez votre mot de passe pour le serveur. Le mot de
passe apparaît en clair dans le texte. Pour des raisons de sécurité, nous vous
recommandons FORTEMENT de ne pas utiliser des mots de passe que vous utilisez
pour d'autres composants importants de votre système ou qui puisse protéger
l'accès à des données sensibles. Choisissez-en un le plus aléatoire possible,
avec une combinaison de lettres, chiffres et caractères spéciaux. Ce mot de
passe sera utilisé par SHOUTcast Trans (ou tout autre fournisseur de contenu)
pour se connecter et diffuser du contenu.
Exemple de code 1.5 : Choisir le port d'écoute |
PortBase=8000
|
Nous configurons ici le port sur lequel les utilisateurs se connecteront au
serveur SHOUTcast. La valeur par défaut, 8000, est celle utilisée par défaut
par la plupart des programmes permettant de se connecter à des serveurs de ce
type (Audacious, winamp, etc.). Comme indiqué en commentaire, si vous voulez
utiliser un port inférieur à 1024, vous devrez être root. Cependant, nous vous
recommandons très fortement de ne pas utiliser de port inférieur à 1024 pour
votre serveur SHOUTcast.
Exemple de code 1.6 : Mettre en place le système de journalisation |
LogFile=/var/log/SHOUTcast.log
|
Nous indiquons ici la destination du fichier de journalisation du serveur
SHOUTcast. Par défaut, l'ebuild l'initialise à /dev/null. Vous
devrez donc probablement le changer pour avoir une journalisation correcte.
Ici, nous avons choisi comme répertoire de destination l'habituel
/var/log. Cela dit, vous pouvez mettre votre fichier de
journalisation où bon vous semble.
Exemple de code 1.7 : Activer les informations en temps réel |
RealTime=0
|
Cela affiche des informations sur le fichier diffusé en cours dans la sortie
standard toutes les secondes. L'ebuild désactive cela pour que le démon
SHOUTcast puisse fonctionner le plus silencieusement possible. Mettez la valeur
de la variable à 1 si vous souhaitez obtenir ces informations toutes les
secondes. Cependant, nous vous recommandons d'utiliser la page de statut à la
place.
Exemple de code 1.8 : Activer la journalisation en temps réel |
ScreenLog=0
|
Par défaut, l'ebuild désactive encore cette variable pour avoir un démon qui
s'exécute le plus silencieusement possible. L'activer aurait pour effet de
journaliser tous les événements (connexions, déconnexions, etc.) sur la sortie
standard, en temps réel. Cependant, comme le fichier de journalisation fait la
même chose, nous vous recommandons d'utiliser ce fichier à la place de
l'affichage sur la sortie standard.
Exemple de code 1.9 : Choisir le nombre de dernières chansons affichées |
ShowLastSongs=10
|
Comme son nom l'indique, cette valeur correspond au nombre de chansons qui ont
été récemment jouées et ces chansons seront indiquées dans /played.html. Si
vous mettez une valeur de plus de 20, vous rencontrerez probablement des
problèmes.
Exemple de code 1.10 : Activation de la journalisation des modifications dans le système de fichiers |
|
Cet élément permet d'activer ou non la journalisation pour les événements
concernant les modifications de répertoire par le DNAS (le serveur audio
distribué). Il est recommandé pour ceux qui souhaitent avoir une journalisation
la plus sûre possible. Ceux qui font usage de ce serveur pour une utilisation
en Intranet ou occasionnelle n'auront probablement pas besoin de cet élément.
Exemple de code 1.11 : Activation de la journalisation des requêtes HTTP |
|
Cette option permet d'indiquer si vous voulez ou non journaliser les requêtes
faites sur le serveur HTTP fourni par SHOUTcast. Encore une fois, elle est
recommandée pour ceux qui souhaitent une journalisation complète, mais pas
pour la plupart des utilisateurs.
Exemple de code 1.12 : Activer la journalisation W3C |
W3CEnable=Yes
W3CLog=/dev/null
|
La première option active la journalisation W3C. Il est plus simple d'extraire
des informations de la journalisation si on l'active, notamment si on utilise
l'un des programmes cités dans les commentaires (Analog, WebTrends...).
Nous le recommandons grandement pour ceux qui souhaitent avoir des statistiques
les plus complètes possible.
La seconde option indique l'endroit où doit être gardé le fichier de
journalisation W3C. Par défaut, l'ebuild met cette option à
/dev/null.
Configuration réseau
Exemple de code 1.13 : Configurer l'adresse IP source |
SrcIP=ANY
|
La variable SrcIP indique de quelle adresse IP le contenu de diffusion provient.
Cela peut venir d'autres serveurs (relais), de localhost (cas général) ou de
toute autre adresse IP que votre interface peut supporter. L'initialiser à
localhost empêche les autres serveurs d'utiliser votre serveur SHOUTcast comme
une source de diffusion. Par défaut, la variable est mise à ANY, ce qui fait que
votre serveur SHOUTcast pourra diffuser le contenu depuis d'autres serveurs.
Pour des raisons de sécurité, il est préférable de choisir une valeur plus
précise.
Exemple de code 1.14 : Configurer l'adresse IP de destination |
DestIP=ANY
|
Cette variable détermine sur quelle adresse IP de votre interface réseau vous
autoriserez les utilisateurs à se connecter. Cela peut être localhost (si vous
êtes antisocial et ne voulez diffuser du contenu que pour vous-même), une
adresse IP privée (de type 192.168.0.101, si vous hébergez un serveur SHOUTcast
pour un réseau local) ou une adresse IP publique (de type 209.204.249.201, pour
faire de la diffusion sur WAN et non sur LAN). Dans la plupart des cas, vous
pourrez accéder au contenu diffusé en utilisant 127.0.0.1. ANY permet à votre
serveur SHOUTcast de recevoir les requêtes clientes sur toutes les adresses IP
venant de toutes les interfaces disponibles.
Exemple de code 1.15 : Configurer le port proxy/yp.SHOUTcast.com |
Yport=80
|
Cette variable permet deux choses. Tout d'abord, elle spécifie le port avec
lequel le serveur peut se connecter à yp.SHOUTcast.com. yp.SHOUTcast.com est une
page de Nullsoft pour les serveurs publics qui permet aux utilisateurs d'avoir
accès à une liste de serveurs sur lesquels ils peuvent écouter du contenu. Les
utilisateurs peuvent accéder à votre serveur depuis cette page. L'autre
utilisation est pour les proxy Web. Il faut alors mettre cette valeur au numéro
du port utilisé pour les connexions proxy et mettre à DestIP le nom du proxy
pour la diffusion.
Exemple de code 1.16 : Configurer le DNS inversé |
NameLookups=0
|
Cette option permet d'indiquer si oui ou non vous voulez activer l'utilisation
du DNS inversé pour les clients. Cela permet de récupérer leur nom à partir de
leur IP. À utiliser essentiellement pour créer des rapports de journalisation
plus détaillés.
Exemple de code 1.17 : Activer le relais |
|
Permet d'indiquer que vous agissez comme serveur relais. Les serveurs relais
sont souvent utilisés pour récupérer le contenu d'une connexion à faible débit
et le diffuser à un plus grand nombre d'utilisateurs, avec une connexion
supérieure. RelayPort et RelayServer indiquent le port et l'adresse IP du
serveur SHOUTcast pour lequel vous voulez agir comme relais. Laissez ces lignes
commentées si vous ne souhaitez pas servir de relais.
Configuration du serveur
Exemple de code 1.18 : Indiquer le mot de passe administrateur |
|
L'initialisation de cette variable va créer un administrateur et un diffuseur
(broadcaster et administrator). Le diffuseur peut se connecter avec un mot de
passe et voir les connexions actuelles. Cependant, pour pouvoir déconnecter,
bannir des clients ou administrer le serveur, vous devez avoir le mot de passe
administrateur. Cette option crée des rôles précis pour votre serveur. Son usage
est recommandé quand l'administrateur système n'est pas la même personne que le
diffuseur.
Exemple de code 1.19 : Configurer la déconnexion automatique des clients |
AutoDumpUsers=0
|
Cette variable permet de décider si oui ou non les utilisateurs seront
déconnectés si la diffusion se déconnecte pour une raison quelconque. On la met
à 0 pour que les clients se mettent eux-même en dépassement de temps de
connexion ou pour qu'ils puissent continuer d'essayer de mettre en tampon un
contenu diffusé.
À utiliser si vous pensez avoir de courtes interruptions de temps à autre.
Exemple de code 1.20 : Configurer le temps de connexion limite pour la source |
AutoDumpSourceTime=30
|
Cette variable indique quand le serveur SHOUTcast abandonnera la tentative de
connexion à une source (en général un serveur relais) pour diffuser son contenu.
Une valeur entre 30 et 60 secondes devrait être raisonnable ici.
Exemple de code 1.21 : Configurer le répertoire de contenu |
ContentDir=/opt/SHOUTcast/content/
|
La variable ContentDir indique où doit être mis le contenu à la demande. Par
exemple, si vous souhaitez diffuser une annonce à vos employés, vous pouvez
utiliser cette fonctionnalité. L'ebuild du serveur SHOUTcast l'initialise à
/opt/SHOUTcast/content pour vous. Pour l'utiliser, mettez un MP3
dans le répertoire de contenu, puis mettez un lien vers
http://exemple.com:[port]/content/nomDump3.pls. Le serveur SHOUTcast
créera automatiquement une liste de diffusion pour le MP3 et le diffusera à la
demande. À utiliser comme alternative à SHOUTcast Trans pour diffuser une source
audio.
Exemple de code 1.22 : Configurer un fichier d'introduction |
|
Cela permet d'ajouter un fichier d'introduction. À chaque fois qu'un utilisateur
se connecte, il entendra ce fichier. Comme indiqué, le débit de diffusion et
celui du morceau d'introduction doivent coïncider, sinon cela peut créer des
problèmes. Vous pouvez cependant mettre des fichiers comme intro128.mp3 et
intro64.mp3 et il jouera alors intro128.mp3 pour les utilisateurs qui utilisent
une diffusion 128 Kb/s et intro64.mp3 pour ceux qui utilisent une
connexion 64 Kb/s.
Exemple de code 1.23 : Configurer un fichier son d'attente |
|
Cette variable a le même effet que la précédente, mais le fichier sera joué
quand la source de diffusion est finie, au lieu de déconnecter les utilisateurs.
Ne fonctionne que si AutoDumpUsers est mis à 0.
Exemple de code 1.24 : Configurer le format de titre |
TitleFormat=Chris Gentoo Beats: %s
|
Cette variable permet de spécifier un titre fixe pour votre serveur SHOUTcast.
Utilisez-la si votre source de diffusion diffère du nom de votre serveur. Cela
ne fonctionnera pas pour les serveurs relais.
Exemple de code 1.25 : Configurer le format d'URL |
|
Cette variable permet de faire la même chose que TitleFormat, mais pour les
URL : l'URL précisée ici est utilisée à la place de l'URL de la source de
diffusion.
Exemple de code 1.26 : Configurer le statut public d'une source de diffusion |
PublicServer=default
|
On peut préciser si oui ou non on veut être listé comme un serveur public, même
si votre source/serveur relais est listé comme tel ou non.
Exemple de code 1.27 : Permettre les relais |
AllowRelay=Yes
|
AllowRelay permet de choisir si d'autres serveurs peuvent relayer votre contenu.
Si vous ne pensez pas que vous serez relayé, mettez « No ».
Exemple de code 1.28 : Permettre aux relais d'afficher publiquement la source |
AllowPublicRelay=Yes
|
On peut préciser grâce à AllowPublicRelay si l'on veut permettre aux serveurs
qui vous relaient de vous lister dans le répertoire SHOUTcastpublic. Remarquez
que PublicServer a priorité sur cette fonctionnalité.
Exemple de code 1.29 : Configurer la variable MetaInterval |
MetaInterval=32768
|
Laissez-le tel quel, tout simplement.
Configuration des accès
Exemple de code 1.30 : Configurer le temps maximum d'écoute |
|
Je ne suis pas sûr de voir l'utilité que cette fonctionnalité pourrait avoir
pour vous. Tout ce qu'elle fait, c'est de déconnecter les utilisateurs qui
sont sur le serveur depuis trop longtemps. La seule utilité que je lui vois est
de permettre de déconnecter les personnes qui se connectent pour rien ou si
vous estimez que les utilisateurs devraient avoir autre chose à faire qu'écouter
votre diffusion. La valeur est à mettre en minutes.
Exemple de code 1.31 : Indiquer le fichier de bannissement |
|
C'est le fichier contenant la liste des clients qui sont bannis de votre
serveur. Par défaut, c'est le fichier sc_serv.ban, mais vous pouvez
utiliser le fichier que vous voulez.
Exemple de code 1.32 : Indiquer le fichier de liste blanche |
|
Autrement nommé RipFile, pour « Reserved IP », ce fichier est utilisé
pour préciser la liste des utilisateurs amis ou des personnes que vous
considérez comme plus importantes que les utilisateurs lambda. Si vous êtes
actuellement en train de diffuser du contenu à un nombre d'utilisateurs égal à
votre maximum et qu'un membre de la liste blanche essaye de se connecter, le
serveur déconnectera la personne qui aura le temps d'écoute maximum pour laisser
place à l'utilisateur privilégié.
Exemple de code 1.33 : Configurer si seuls les utilisateurs Rip peuvent accéder au serveur |
|
Avec cette option, vous ne pouvez permettre l'accès à votre serveur SHOUTcast
qu'aux membres Rip (de la liste blanche). Vous pouvez au choix l'utiliser pour
faire de la diffusion radio privée ou faire en sorte que seuls certains relais
puissent accéder à votre contenu.
Configuration de masse
Exemple de code 1.34 : Configurer la variable Unique |
|
Pour faire simple, si vous disposez de nombreux serveurs SHOUTcast, cela serait
une vraie plaie de devoir modifier tous les fichiers de journalisation,
bannissement, etc. pour chaque serveur, alors que leur contenu est identique
pour tous les serveurs. À la place, vous pouvez mettre une valeur pour Unique et
$ sera remplacé par le contenu de Unique. Par exemple, si un fichier contient
Unique=Jazz et qu'un autre contient Unique=Rock, alors Log=/var/log/$.log
produira un fichier /var/log/Jazz.log pour l'un des fichiers de configuration et
/var/log/Rock.log pour l'autre. Cela permet de simplifier le fonctionnement
de plusieurs serveurs SHOUTcast disposant de configurations similaires.
Exemple de code 1.35 : Configurer des variables de configuration communes |
|
Si vous disposez de plusieurs serveurs SHOUTcast et si vous souhaitez
utiliser des variables de configuration similaires, sans les configurer dans
chaque fichier de configuration, vous pouvez utiliser cette variable pour
pointer vers un fichier contenant des configurations qui seront communes pour
vos différents serveurs.
Configuration d'optimisation
Exemple de code 1.36 : Configurer le nombre de processeurs utilisés |
|
Sur les systèmes qui disposent de plusieurs processeurs, vous pouvez utiliser
cette variable pour forcer le serveur SHOUTcast à utiliser un certain nombre
CpuCount de processeurs. Par défaut, il assignera un fil d'exécution pour chaque
processeur et les clients seront distribués entre les fils d'exécution. Si vous
utilisez une valeur inférieure au nombre de vos processeurs, cela vous laissera
des processeurs libres pour d'autres tâches.
Exemple de code 1.37 : Configuration de l'intervalle de soumission de données |
|
Le serveur SHOUTcast utilisera la valeur de « Sleep » pour déterminer
l'intervalle entre chaque envoi de données. Plus la valeur est grande, plus
l'intervalle est grand. Plus la valeur est petite, plus l'intervalle sera petit
et le serveur SHOUTcast utilisera plus de capacité de calcul du processeur pour
arriver à ses fins. Sur des systèmes limités, vous devrez probablement diminuer
la valeur pour que les serveurs SHOUTcast puissent envoyer des données de plus
en plus fréquemment aux utilisateurs. Le mieux est de laisser la valeur par
défaut.
Exemple de code 1.38 : Configurer la sortie XML |
|
Nous n'avez probablement pas à vous préoccuper de cette variable, sauf si vous
utilisez un parseur XML personnalisé pour créer des statistiques adaptées à
vos besoins pour votre serveur. Si le parseur XML ne peut pas gérer les espaces
et les sauts de lignes des flux XML, mettez cette valeur à « Yes » et
tout devrait fonctionner correctement.
Conclusion à propos de la configuration
Votre serveur SHOUTcast devrait être maintenant bien configuré. Je recommande
l'utilisation de la journalisation W3C, car on en extrait plus facilement les
données et elle est recommandée pour créer des statistiques personnalisées.
Vous pouvez également activer la variable AdministratorPassword. Vous aurez
peut-être également besoin de quelques options de configuration de masse si vous
configurez plusieurs serveurs SHOUTcast.
Maintenant que la configuration a été mise en place, nous allons mettre le
serveur SHOUTcast en production. Nous le lancerons avec une diffusion simple à
la demande, pour commencer, puis nous utiliserons SHOUTcast Trans (qui est
plus complet et complexe à mettre en œuvre).
2.
Faire fonctionner le serveur SHOUTcast
Mettre en place une diffusion à la demande
Une diffusion à la demande, comme vue dans le chapitre sur la configuration,
met automatiquement à disposition des listes de lecture pour les fichiers MP3
du répertoire courant. L'ebuild du serveur SHOUTcast configure ce répertoire à
/opt/SHOUTcast/content pour tous les MP3 de diffusion à la demande.
Commençons par créer une diffusion simple de MP3 à la demande.
Tout d'abord, nous devons récupérer un MP3 et le mettre dans le répertoire de
contenu. Nous utiliserons le fichier exemple.mp3 récupéré dans le répertoire
/Mp3 que j'avais créé.
Exemple de code 2.1 : Copier un fichier MP3 dans le répertoire de contenu |
# cp /Mp3/exemple.mp3 /opt/SHOUTcast/content/
# cd /opt/SHOUTcast/content/
# ls
exemple.mp3
|
Bon, le fichier a été copié. Maintenant, nous devons lancer le serveur
SHOUTcast pour donner un accès à ce fichier.
Exemple de code 2.2 : Lancer le serveur SHOUTcast |
# /etc/init.d/shoutcast start
* Starting Shoutcast Server...
*******************************************************************************
** SHOUTcast Distributed Network Audio Server
** Copyright (C) 1998-2004 Nullsoft, Inc. All Rights Reserved.
** Use "sc_serv filename.ini" to specify an ini file.
*******************************************************************************
[ ok ]
|
La bannière est là pour s'assurer qu'il n'y a eu aucun plantage (c'est-à-dire
que le serveur fonctionne effectivement). Votre serveur SHOUTcast est maintenant
lancé ! De par la nature du contenu « à la demande », vous ne
pourrez y accéder que depuis un navigateur. MPlayer ou autres ne pourront pas
le lire comme tel. J'utilise personnellement kmplayer pour pouvoir accéder au
contenu diffusé directement depuis mon navigateur. Vous pouvez voir le résultat
sur l'image suivante.
Figure 2.1 : Contenu à la demande |
 |
Certaines personnes ont configuré Audacious pour récupérer toutes les données
de type audio, donc votre navigateur devrait appeler Audacious pour jouer le
contenu diffusé. Maintenant que vous pouvez faire fonctionner le serveur avec
un contenu à la demande, nous allons le faire fonctionner en utilisant
SHOUTcast Trans pour créer un vrai serveur de diffusion radio.
3.
Mise en place de SHOUTcast Trans
Introduction à SHOUTcast Trans
SHOUTcast Trans signifie SHOUTcast Trans(coder), dans la mesure où il est
capable de réencoder des MP3 à des débits inférieurs ou supérieurs. SHOUTcast
Trans fonctionne en diffusant les MP3 de la liste de lecture spécifiée dans le
fichier de configuration. Nous allons tout d'abord configurer SHOUTcast Trans,
afin d'avoir un serveur qui ressemble à quelque chose. Tout d'abord, ouvrons
le fichier de configuration de SHOUTcast Trans qui est situé dans
/etc/shoutcast/sc_trans.conf.
Exemple de code 3.1 : Ouvrir le fichier de configuration de SHOUTcast Trans |
# emerge shoutcast-trans-bin
# vi /etc/shoutcast/sc_trans.conf
|
Maintenant, nous allons commencer la configuration de la source de diffusion.
Configurer SHOUTcast Trans
Exemple de code 3.2 : Configurer la liste de lecture |
PlaylistFile=/opt/SHOUTcast/playlists/playlist.lst
|
Cet élément indique à SHOUTcast où trouver le contenu audio de diffusion.
Il nécessite un fichier existant, donc nous allons créer une liste de lecture.
Allons au plus court en utilisant les MP3 contenus dans notre répertoire /Mp3.
Exemple de code 3.3 : Créer la liste de lecture |
# find /Mp3 -type f -name "*.mp3" > /opt/SHOUTcast/playlists/playlist.lst
|
Maintenant que la liste de lecture a été créée, nous l'indiquons dans le
fichier de configuration et SHOUTcast Trans sait maintenant quels fichiers
diffuser.
Exemple de code 3.4 : Configurer l'adresse IP et le port du serveur |
Serverip=127.0.0.1
ServerPort=8000
|
Ces variables indiquent où envoyer le contenu de diffusion. Dans ce guide, nous
utilisons l'adresse IP et le port du serveur SHOUTcast que nous avons configurés
auparavant (DestIP et PortBase).
Exemple de code 3.5 : Configurer le mot de passe du serveur SHOUTcast |
Password=password_you_setup_in_sc_serv.conf
|
C'est le mot de passe que vous avez mis dans la configuration du serveur
SHOUTcast.
Exemple de code 3.6 : Configurer vos informations de diffusion |
StreamTitle=Chris Gentoo Beats
StreamURL=http://www.gentoo.org
Genre=JPOP Electronica And More!
|
Nous définissons ici le titre de votre diffusion, l'URL et le genre.
Exemple de code 3.7 : Configurer votre fichier de journalisation |
LogFile=/var/log/sc_Trans.log
|
Cette variable contient le nom du fichier de journalisation pour SHOUTcast
Trans. Toutes les informations journalisées iront ici.
Exemple de code 3.8 : Configurer le mélange des morceaux |
Shuffle=1
|
Décide si oui ou non votre liste de lecture sera lue dans un ordre aléatoire à
chaque fois ou non. La plupart l'utilisent. Si vous voulez par la suite accepter
les requêtes de lecture, mettez cette variable à 0 et je vous expliquerai
comment faire plus loin.
Exemple de code 3.9 : Configurer la diffusion |
Bitrate=128000
SampleRate=44100
Channels=2
Quality=1
|
La variable Bitrate indique le débit de votre diffusion et peut aller de 8000
(8 Kb/s) à 128000 (128 Kb/s). La variable SampleRate indique la
fréquence d'échantillonage et peut aller de 11025 (11 KHz) à 44100
(44.1 KHz). La variable Channels indique le nombre de canaux diffusés et
peut valoir 1 (mono) ou 2 (stéréo). La variable Quality indique la qualité de la
diffusion, même si elle reste contrôlée d'une certaine manière par les trois
valeurs précédentes. C'est ici que vous indiquerez la compression de votre
diffusion. 1 donne une meilleure qualité et 10 donne une vitesse supérieure.
Souvenez-vous que votre connexion est limitée quand vous configurez ces valeurs.
Utilisez les valeurs proposées pour avoir une idée des valeurs à utiliser.
Exemple de code 3.10 : Configurer la lecture en fondu |
CrossfadeMode=1
CrossfadeLength=8000
|
Cet élément permet de configurer la lecture en fondu. Mettre une valeur de 0
désactive le fondu. Une valeur de 1 fait que la chanson 1 diminue et la 2
augmente de volume. Si vous mettez 2, la chanson 1 augmente et la 2 diminue. La
durée du fondu est à spécifier en millisecondes.
Exemple de code 3.11 : Permettre l'utilisation des ID3 |
UseID3=1
|
Cette variable permet ou non l'utilisation des informations ID3 contenues dans
les MP3.
Exemple de code 3.12 : Configurer le statut public |
Public=0
|
Cette variable permet de décider si oui ou non les diffusions seront listées
publiquement lors du relais à un serveur. Souvenez-vous que PublicServer, dans
sc_serv.conf, peut écraser cette configuration.
Exemple de code 3.13 : Configurer l'interaction avec les utilisateurs |
AIM=AIMHandle
ICQ=
IRC=SHOUTcast
|
Ces variables permettent de donner des informations sur comment vous joindre.
Vous pouvez configurer des canaux ICQ ou AIM pour les requêtes de lecture ou
pour tout autre usage. Vous pouvez configurer votre propre canal IRC, afin
de pouvoir interagir avec plusieurs utilisateurs à la fois.
Conclusion à propos de la configuration de SHOUTcast Trans
SHOUTcast Trans est maintenant prêt à diffuser du contenu pour votre serveur
SHOUTcast. Nous allons maintenant permettre la diffusion de vos MP3.
4.
Utiliser SHOUTcast Trans
Lancer SHOUTcast Trans
Comme j'utilise généralement SHOUTcast Trans avec le serveur SHOUTcast, j'ai
tendance à lancer SHOUTcast Trans, qui s'occupera de lancer le serveur SHOUTcast
pour vous (c'est plus simple). Donc, allons-y !
Exemple de code 4.1 : Lancer Shoutcast Trans et le serveur Shoutcast |
# /etc/init.d/shoutcast_trans start
* Starting Shoutcast Server...
*******************************************************************************
** SHOUTcast Distributed Network Audio Server
** Copyright (C) 1998-2004 Nullsoft, Inc. All Rights Reserved.
** Use "sc_serv filename.ini" to specify an ini file.
*******************************************************************************
[ ok ]
* Starting Shoutcast Trans... [ ok ]
|
Écouter le contenu diffusé par SHOUTcast Trans
Maintenant que SHOUTcast Trans est lancé, nous allons pouvoir commencer à
écouter notre contenu diffusé. J'utilise MPlayer dans cet exemple pour lire le
contenu.
Exemple de code 4.2 : Écouter notre contenu |
# mplayer -cache 1024 http://127.0.0.1:8000/
...
Playing http://127.0.0.1:8000/.
Connecting to server 127.0.0.1[127.0.0.1]:8000 ...
Name : Chris Gentoo Beats
Genre : JPOP Electronica And More!
Website: http://www.gentoo.org
Public : no
Bitrate: 128kbit/s
Cache size set to 1024 KBytes
Connected to server: 127.0.0.1
Cache fill: 9.38% (98304 bytes) Audio file detected.
==========================================================================
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
MP3lib: init layer2 and 3 finished, tables done
mpg123: Can't rewind stream by 156 bits!
AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 16000->176400 (128.0 kbit)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
Checking audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
AF_pre: af format: 2 bps, 2 ch, 44100 hz, little endian signed int
AF_pre: 44100Hz 2ch Signed 16-bit (Little-Endian)
AO: [oss] 44100Hz 2ch Signed 16-bit (Little-Endian) (2 bps)
Building audio filter chain for 44100Hz/2ch/16bit -> 44100Hz/2ch/16bit...
Video: no video
Starting playback...
|
La variable -cache a été mise pour ne pas utiliser mes configurations de
mise en cache un peu excessive pour cette utilisation. Vous écoutez désormais
votre diffusion audio ! Dans le prochain chapitre, nous allons voir un peu
plus en détail certains points du serveur SHOUTcast.
5.
Utilisation avancée de SHOUTcast
Utilisation professionnelle
On peut utiliser SHOUTcast dans le cadre professionnel dans de nombreux
cas :
-
Utiliser un contenu à la demande pour diffuser des annonces journalières.
-
En disposant d'un système de diffusion public d'annonces, vous pouvez
permettre à vos clients de se tenir au courant de tout ce qui se passe.
Puis, vous pouvez les archiver comme contenu de diffusion à la demande, pour
permettre d'y faire des références plus tard.
-
Faire des entretiens audio et les archiver dans un contenu à la demande.
Il y a bien d'autres cadres pour utiliser un serveur SHOUTcast dans un
environnement professionnel. Utilisez une diffusion audio à la place de ces
vieilles paperasses !
Jouer au DJ avec SHOUTcast
Le serveur SHOUTcast est l'un des serveurs de diffusion les plus populaires chez
les apprentis DJ sur Internet, comme les anciens. Pour ceux qui débutent, il y
a quelques trucs permettant de donner aux utilisateurs une idée de la qualité de
votre serveur SHOUTcast. Disposer d'un morceau d'introduction est la clef. Il
donne aux utilisateurs une idée de ce qu'ils peuvent entendre sur votre station.
N'oubliez pas d'en mettre un ! Signalez votre serveur sur yp.SHOUTcast.com
(décrit dans la configuration du serveur SHOUTcast) pour que tout le monde
puisse vous trouver. Une fonctionnalité intéressante est de permettre aux
utilisateurs de faire leur propre liste de lecture. Pour faire cela, désactivez
la lecture aléatoire dans sc_Trans.conf (Shuffle=off). Disposez d'une dizaine
de morceaux prêts à être écoutés. Puis, lancez une procédure de requête de
lectures au milieu. Quand une personne demande un morceau, ajoutez-le simplement
à la fin de votre liste de lecture et vous pourrez alors utiliser le script
suivant pour contrôler ce que doit faire SHOUTcast Trans avec votre liste de
lecture :
Exemple de code 5.1 : djcontrol |
case "$1" in
"reload")
kill -s USR1 `cat /var/run/SHOUTcast_Trans.pid`
;;
"next")
kill -s WINCH `cat /var/run/SHOUTcast_Trans.pid`
;;
*)
echo "Invalid command"
;;
esac
|
Une fois que vous avez ajouté un morceau à votre liste de lecture, vous devrez
indiquer à SHOUTcast Trans que la liste de lecture a changé.
Exemple de code 5.2 : Recharger la liste de lecture |
# djcontrol next
|
Vous devez maintenant permettre aux utilisateurs de savoir quelle chanson
sera lancée. Ou, si vous le souhaitez, vous pouvez continuer à passer les
morceaux en faisant :
Exemple de code 5.3 : Aller au morceau suivant |
# djcontrol next
|
Faites attention à ne pas sauter trop de morceaux, parce qu'il n'y a aucune
commande possible pour revenir en arrière. Une fois que vous arrivez à la
chanson demandée, la requête commence. Vous devez avoir environ cinq requêtes
avant de commencer à lancer de nouvelles demandes. De cette manière, vous ne
retournerez pas constamment au début de la liste. Si vous commencez à manquer de
demandes et que vous pensez que les choses ne changeront pas à moyen terme,
copiez simplement votre prochaine liste de diffusion à la place de la liste des
demandes et rechargez la liste d'écoute. Une fois que le morceau en cours sera
fini, il passera à la nouvelle liste.
Conclusion
C'est la fin du manuel sur le serveur SHOUTcast et sur SHOUTcast Trans. J'espère
que vous aurez apprécié sa lecture et que les informations ici vous auront été
utiles. Vous pouvez envoyer un mail à l'auteur si vous avez des commentaires ou
des suggestions à propos de cette page. Et maintenant, faites-vous plaisir avec
votre nouveau serveur de diffusion audio SHOUTcast !
Ce document est protégé par la licence Creative
Commons : Paternité - Partage des Conditions Initiales à
l'Identique 2.5.
|