Logiciel Panik

From Bubble

Contents

[edit]

Base

La base installée est une Debian Sarge

[edit]

Packages installés

En plus de l'installation de base de Sarge, les packages suivants sont installés:
Pour faciliter la maintenance, on vise une installation minimale...

[edit]

Installation typique d'un noeud

  • Système
    • bzip2
    • (gawk)
    • less
    • iptraf
    • modconf
    • nmap
    • tcpdump
    • traceroute
    • ssh
  • Wifi
    • kismet n'est pas installé car les dépendances sont trop nombreuses ( @) il semble que dans Sarge kismet dépende de X)
    • iperf
    • wavemon
    • wireless-tools
  • NTP
    • ntp
    • ntp-server
    • ntp-simple
    • ntpdate
  • Divers
    • links
[edit]

Besoins particuliers

Les paquets suivants ne sont installés que si nécessaire:

  • Supervision de processus
    • daemontools
    • svtools
  • Audio
    • aumix
    • cdtool
    • sox
    • vorbis-tools
  • Portables Toshiba
    • toshset (permet d'activer le ventilateur, etc, ....)
[edit]

Noyeau

Nous utiliserons un noyeau 2.4.27 qui est actuellement la dernière version stable de la série 2.4.

Particularités:

  • Compilé pour une architecture i386 de manière a tourner su n'importe quel hardware
  • Patches Debian
  • Patch Orinoco pour le support du mode moniteur (kismet)
  • Drivers HostAP 0.2.4
  • Utilisation des drivers PCMCIA du noyeau
[edit]

AODV

On utilise RC:AodvUu dans sa dernière version: 0.8.1 Le démarrage d'AODV se fait via les scripts ifupdown (voir RC:InstallerAodvUu / Binaires pour Debian)

[edit]

Streaming

Nous avons donc 3 machines en jeu:

  • Studio qui fournit le stream
  • Panik ne sert que de passerelle entre le RC:ReseauCitoyen et Studio
  • Josaphat machine client

La suite logicielle utilisée est Ices 2 / IceCast / OggVorbis

[edit]

Configuration des Systèmes

[edit]

Généralités

Le fichier RC:FichierHostsPointsBleus est utilisé
Les requetes DNS sont désactivées dans /etc/nsswitch.conf afin d'éviter des requètes DNS non désirées.

[edit]

Studio

[edit]

Configuration

Pour réaliser les tests, j'ai configuré une machine en serveur IceCast:

  • Ices 2 lit l'entrée ligne de la carte son, fait le rééchantillonage, l'encodage OGG et fournit l'entrée à IceCast
  • IceCast 2.0.1 diffuse le stream

On utilise aumix pour sélectionner la source et régler le volume. Points importants:

  • La source à diffuser est celle qui est marquée comme 'R' (Record) dans aumix
  • La seule façon de régler le volume pour Ices est le curseur IGain. Les autre curseur n'influencent que la sortie son 'locale'.
    Le son au départ était trop fort, il a fallu diminuer pour éviter de saturer (curseur IGain sur 50/60%)

L'encodage Ices prend environ 6% du cpu du serveur (AMD 1GHz), l'impact de IceCast est négligeable.
Par contre sur un Pentium 133MHz, Ices utilises 60 à 70% des resources!

La machine utilise Panik comme gateway vers le RC:ReseauCitoyen: 

route add -net 10.0.0.0/8 gw 192.<panik>
[edit]

Maintenance

Pas de maintenance particulière -- s'assurer que la route vers le RC:ReseauCitoyen est toujours définie. Le plus simple est de l'ajouter dans /etc/network/interfaces; par exemple: 

auto eth0
iface eth0 inet dhcp
    up route add -net 10.0.0.0/8 gw 192.<panik>
[edit]

Panik

[edit]

Configuration

La configuration du noeud est assez simple. Le seul point particulier est la configuration de la passerelle vers Studio.
Comme on ne peux pas faire simplement une passerelle avec RC:AodvUu, Panik fait du DNAT pour donner acces au stream: 

iptables -t nat -I PREROUTING -i wlan0 -s 10.<josaphat> -p tcp --dport 8000 -j DNAT --to 192.<studio>:8000

et Masquerade le sous-réseau privé: 

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o wlan0 -j SNAT --to 10.<panik>

La machine est configurée avec une adresse IP fixe du coté filaire (192.168.1.128).
Coté wifi, l'adresse est attribuée sur base de la MAC-Address de la carte (10.154.69.107)

[edit]

Maintenance

Aucune opération nécessaire au boot.

Toute la configuration réseau est centralisé dans /etc/network/interfaces.

[edit]

Josaphat

[edit]

Configuration

On utilise le décodeur ogg123 de OggVorbis pour la lecture du stream (voir ci-dessous pour les détails).
L'adresse du serveur est celle de Panik qui relaie vers Studio 

ogg123 -v http://10.<Panik>:8000/ReseauCitoyen.ogg

Le niveau sonore est ici aussi ajusté via aumix. c'est l'entrée PCM qu'il faut ici ajuster.

Le délais entre l'émission et la réception est d'environ 10 secondes.
Même avec un bit rate relativement faible (qualité 0, débit d'environ 35 kbps, en mono) la qualité du son est impecable.

Ogg123 utilise environ 5% du CPU de la machine (Pentium 200 MHz)

La machine est configurée avec une adresse IP fixe du coté filaire (192.168.1.129) -- Non utilisé.
Coté wifi, l'adresse est attribuée sur base de la MAC-Address de la carte (10.8.39.138)

[edit]

Maintenance

Aucune opération nécessaire au boot.

Toute la configuration réseau est centralisé dans /etc/network/interfaces.

Pour s'assurer que ogg123 tourne en permanence, il est supervisé par les DaemonTools et est rédémaré en cas de problème.
Quelques pointeurs utiles:

  • La ligne de commande exacte pour démarrer ogg123 se trouve dans le fichier /etc/sv/Stream Panik/run.
    Pour des raisons pratiques ce script ne contient que l'appel de /usr/local/sbin/stream-panik. Ce dernier devra être adapté:
    • en fonction de la fréquence de l'échantillonage de la source Ices2 (initialement configuré pour 22050 Hz);
    • si l'adresse de Panik change
  • Le service est redémarré tous les jours à 3:30 du matin, de manière à rafraichir ogg123. Cela est configuré dans le cron, fichier: /etc/cron.d/stream-panik
  • Arrêt / Démarrage / Re-demarage:
    /etc/init.d/stream-panik {start|stop|restart}
  • Activation / Désactivation (lorsque le service est désactivé, il n'est plus démarré au boot, ni redémarré la nuit. Si on ne se sert pas du streaming, il faut le désactiver sinon il va tenter de le démarrer indéfiniment):
    /etc/init.d/stream-panik {enable|disable}
  • Voire les logs:
    mltail Stream Panik

/!\ En cas de problème de streaming: pour le redemarrer il faut:

  • Soit tuer le client dans IceCast, le stream sera redémarré automatiquement
  • Soit executer la commande suivant sur josaphat:
    /etc/init.d/stream-panik restart
[edit]

Problèmes rencontrés et Solutions

[edit]

Décalage dans le stream

Après environ 12 heures de streaming, les buffers (Input et Output) de ogg123 se sont retrouvés proches de 0%, avec pour conséquence de légères coupures dans la restransmition.
Si le problème se résoud facilement par un re-démarrage de ogg123, cela pose un problème pour une utilisation 24h/24h.

D'où vient le problème? Ce n'est pas un problème de bande passante, la demande su stream est faible. Pour s'en convaincre, on peux réduire la vitesse du lien (`iwconfig rate 2M`) et démarrer un second ogg123 sans affecter la performance.

Une interprétation est que Josaphat joue légèrement plus vite que Studio ne produit: en effet, Josaphat ne peut lire plus vite que ce qui est disponible et au fil des heures on voit le buffer d'entée diminuer; lorsque le buffer d'entrée atteint 0, la vitesse de conversion ogg diminue puisque le convertisseur doit attendre des données; on voit alors le buffer de sortie qui n'est plus approvisionné au même rythme qu'il est vidé et il commence lui aussi à se vider. Lorsque les 2 buffers sont vides il n'y a plus rien à diffuser et donc on a des microcoupures dans le son...
Une autre interprétation est qu'un décalage est introduit par Studio lors du re-sampling entre l'entrée et la sortie dans Ices2 (48k vers 24K ici). Si la carte son n'est pas exactement sur 48k, on va générer un décalage.
Dans notre cas, la première option est à priviligier -- le décalage étant pratiquement inexistant avec ogg123 tournat sur un autre PC.

Pour être complet, cela n'a pas l'air d'être lié à l'horloge du PC: j'ai synchronisé les 2 machines avec NTP et cela ne change rien.

Comment y remédier? Je présume qu'il est pratiquement impossible d'avoir des systèmes parfaitements synchronisés. On pourrait envisager une amélioration de ogg123 qui dans ce cas de figure recharge ses buffers plutôt que de continuer à travailler à la limite. Sans toucher au software on peut:

  • Augmenter la taille des buffers.
    Cela ne fait que de reporter le problème et augmente légèrement le décalage du stream, mais c'est toujours ça de gagné!
  • Augmenter le pre-buffering de manière a mieux utiliser le buffer d'input.
    Attention toutefois à ne pas avoir le phénomène inverse au cas où, en changeant de hardware, le lecteur serait plus lent...
  • Redémarrer ogg123 toutes les nuits.
    Avec une interruption de retransmission de quelques secondes. Ce n'est pas l'idéal mais je ne vois pas d'alternative dans l'immédiat.

Concernant la taille des buffers, la lecture des sources nous révèle que:

  • La taille par défaut buffer d'entrée est de 64k
  • La taille par défaut buffer de sortie est de 128k
  • Le pre-buffering par défaut est de 50%

Comme nous ne sommes pas trop limités en mémoire sur Josaphat, j'ai effectué un test avec 256k pour l'entrée, 512k pour la sortie avec un pre-buffering de 75% (comme le buffer d'entrée remplit en une fois le buffer de sortie, il se vide de 25% pratiquement en une fois et se stabilise aux alentours de 50-55%).
Ce test de 24 heures confirme les premières observation: avec le hardware utilisé, le lecteur (Josaphat) lit une seconde plus vite par heure que le serveur de stream (Studio), donc de manière régulière: 12 secondes après 12 heures et 24 en 24 heures. Le buffer d'entrée lui a perdu 30-35% de sa capacité, soit 80-90 kB, ce qui est consistant avec le débit: 24 s à 30 kbps = 90 kB.
Donc un buffer d'entrée de 256k rempli à 50% au départ permet sans problème une déviation de +/- une seconde par heure sur 24 heures.
La grande taille du buffer de sortie n'apporte rien ici, si ce n'est un décalage excessif entre le direct et la diffusion (47 secondes au départ avec les paramètres ci-dessus).
Les parametres recommandés pour ce bit rate sont donc: 

ogg123 --verbose \
        --buffer 256 --prebuffer 60 --audio-buffer 128 \
        --device oss \
        http://10.51.110.172:8000/ReseauCitoyen.ogg

Pour gérer tout cela, pas la peine de réinventer l'eau chaude, on utilise les DaemonTools de D.J. Bernstein.

[edit]

Corruption du Stream

Les tests de longue durée ont révélé une corruption du stream -- probablement un bug dans la gestion des buffers de ogg123...

Après un certain temps, un bruit parasite (un toc) est introduit dans le stream. Le bruit se répète à intervalle régulier (à chaque tour dans le buffer).

J'ai effectué plusieurs tests, et ce problème est tout a fait reproductible: le stream est parfait jusqu'à un certain point, et une fois la corruption introduite, elle reste présente at garde le même cycle que la latence du stream (c'est-à-dire de plus en plus fréquent puisque le latence diminue avec la diminution de l'occupation du buffer du au problème précédent.
La corruption se produit après environ 12:30 d'écoute (à affiner)

Ici aussi, une solution possible serait de redémarrer le stream toutes les 12 heures, mais cela implique une interruption en journée.

Cause du problème: Nous avons un streaming à 24 kHz en 16 bits mono (1 canal). Cela nous fait 384 kbps; on atteind donc 2 GB en 12h 25m 39s!
La cause est plus que probablement un dépassement d'entier signé sur 32 bits. Reste à trouver où!

Quelques observation:

  • XMMS n'a pas ce problème -- j'ai joué plus de 39 heures parfaitement.
  • Bien que la grande majorité drivers OSS comptent les bytes joués dans un int (count_info.bytes), cette information n'est disponible que via un ioctl que ogg123 n'utilise pas
  • Un output via aRts au lieu de OSS en direct génère le même problème
  • Un output via raw | sox au lieu de OSS en direct génère le même problème

(!) Nouveau (27-Sep-04): le by-pass du buffer de sortie de ogg123 semble résoudre le problème: 

ogg123 --verbose \
    --buffer 256 --prebuffer 60 --audio-buffer 0 \
    --device raw -f - \
    http://10.51.110.172:8000/ReseauCitoyen.ogg | 
    sox -t raw -r 24000 -w -s - -t ossdsp -r 48000 /dev/dsp

C'est un point important, car cela:

  • précise où se situe le problème (ce n'est donc pas un problème de pilote OSS ou de décodage ogg)
  • offre un workaround

Le noeud est maintenant configuré de cette façon.

[edit]

test avec mplayer

le 07-12-2008 un stream est lancé entre le brusilia et le serveur de domaine public. une carte son est relié a l'émetteur.et ca marche! mais on a rencontré le même prôbleme avec ogg123 , un test avec mplayer est en route avec la commande suivante 

 while true ; do mplayer -cache 2048 -cache-min 5 http://streaming.domainepublic.net:8000/radiopanik.ogg -loop 0; done
Retrieved from "http://www.e-bulles.be/bubble/Logiciel_Panik"