Digital Fashion - bidouille

Relayer un stream audio avec icecast2

Geoffrey — Fri, 20 Oct 2006 22:05:00 +0200

Pour économiser la bande passante au boulot, j'ai décidé de relayer le stream Club ! de 1.fm sur le LAN. Après avoir vainement tenté d'utiliser streamripper (on verra plus tard pourquoi vainement), j'ai sorti l'artillerie lourde: icecast2:

sudo apt-get install icecast2

Si on sait un peu lire, le script de post-configuration nous incite à aller fourrer notre nez dans /etc/default/icecast2, où l'on apprend (vers la fin) que icecast est désactivé par défaut à cause de la directive ENABLED=false. C'est en fait une feinte pour nous pousser à configurer le bousin (de toute façon si on le configure pas, il marchera pas). Direction /etc/icecast2/icecast.xml donc, pour un brin de configuration (les explications qui suivent se basent sur le fichier par défaut d'une installation sur une ubuntu).

La première partie qui nous interresse s'intitule authentication (vers la ligne 23). Elle contient les informations d'authentification pour les clients qui se connectent en tant que source (source-password), les serveurs qui se connectent en tant que slave (relay-password, en fait je ne suis pas sur à 100%, c'est une déduction) et pour l'interface d'administration (admin-user et admin-password). Une fois ces informations modifiées, direction la directive hostname, qu'on remplira avec au choix, le nom de la machine, son ip, etc. J'ai personellement mis l'ip privée de ma machine (172.16.x.y), pour que ça correspondent à la prochaine directive qui nous interresse: listen-socket. Ici on définit le port et l'ip sur laquelle icecast va écouter. En gros, si vous spécifier 127.0.0.1, votre serveur de streaming ne sera accessible qu'en local. On y met donc en général la même chose que dans hostname (172.16.x.y par exemple), avec un port qui va bien, libre de préférence (8000 par défaut).

Maintenant on passe a la partie qui nous interresse vraiment, la section relay. Rien de bien compliqué ici. Le stream que je souhaite relayer se trouve là: http://64.62.253.223:8060/, or icecast nous demande un server, un port, un point de montage (mount) et un point de montage local (local-mount). Vous avez déjà compris qu'on arrive a cette configuration:

   <relay>
       <server>64.62.253.223</server>
       <port>8060</port>
       <mount>/</mount>
       <local-mount>/1.fm</local-mount>
       <on-demand>0</on-demand>
       <relay-shoutcast-metadata>1</relay-shoutcast-metadata>
   </relay>

Ainsi parés, il ne nous reste plus qu'a lancer modifier la directive ENABLED=false en ENABLED=true dans /etc/default/icecast2 et à lancer icecast:

sudo /etc/init.d/icecast2 start

Si vous avez bien tout fait, vous devriez pouvoir streamer depuis http://172.16.x.y:8000/1.fm, et vos collègues également ! Vous pouvez avoir une vue d'ensemble du serveur ainsi que quelques options d'administration en vous rendant sur l'interface d'admin: http://172.16.x.y:8000/ et en utilisant admin-user et admin-password pour vous authentifier.

A cela on peut ajouter un petit streamripper:

streamripper http://172.16.x.y:8000/1.fm -d ~/streamripped

Pour enregistrer. En parlant de streamripper, j'avais tenté au début de relayer avec streamripper -r, mais malgrès les apparences du netstat -pl (*:8000 LISTEN), il ne bind qu'en local, donc impossible d'en faire profiter les collègues :-)

Polymorphisme et PHP

Geoffrey — Fri, 13 Oct 2006 12:51:00 +0200

Ou presque ! Je vois déjà vos têtes ahuries devant un tel titre, et pourtant je ne suis pas fou non, j'ai juste décidé d'avoir un titre qui ment par ommission :-) Bref, pour ceux qui ne savent pas ce qu'est le polymorphisme, c'est tout simplement le fait d'avoir plusieurs fonctions qui portent le même nom, mais dont les arguments différent, et pour ceux qui ne comprennet pas pourquoi Polymorphisme et PHP est un drole de titre, et bien sachez que le PHP est un langage non typé (ou faiblement typé selon la personne a qui vous parlez), et qu'il n'est donc pas possible de faire usage du Type Hinting dans la définition d'une fonction (pas sur les types de base en tout cas, mais PHP5.x introduit le type hinting sur les objets, ce qui ne change rien a notre histoire), ce qui fait que PHP ne peut pas gérer le polymorphisme brut.

Cela dit, il est toujours possible de feinter, et on peut simuler le polymorphisme en PHP. Sans plus attendre, voilà un exemple:

function doSomething($arg) {
	switch(gettype($arg)) {
		case 'integer':
			return _doSometing_Integer($arg);
		break;
		case 'array':
			return _doSomething_Array($arg);
		break;
		default:
			return _doSometing_String((string) $arg);
		break;
	}
}

Voilà. C'est très basique, mais l'idée est là. Un petit tour sur le manuel PHP nous indique qu'utiliser gettype n'est pas très recommandé, nous allons donc procéder autrement (et passer en objet par la même occasion):

class Polymorph {
	public function doSometing($arg) {
		switch(true) {
			case is_array($arg):
				return $this->_doSomething_Array($arg);
			break;
		}
	}

	private function _doSomething_Array($arg) {

	}
}

On aurait également pu faire, pour plus de souplesse (mais avec gettype):

class Polymorph {
	public function doSomething($arg) {
		$method = '_doSomething_.'.ucfirst(gettype($arg));
		if (method_exists($this, $method)) {
			call_user_func(array($this, $method), $arg);
		} else {
			// default comportement
		}
	}
}

Submit par défaut dans un formulaire HTML

Geoffrey — Tue, 03 Oct 2006 02:08:00 +0200

Qu'on se le dise, dans un formulaire comprenant plusieurs input de type submit, il n'est pas possible de spécifier le bouton à actionner quand on appuie sur la touche entrée. Si l'on considère que les HIG de Gnome imposent d'avoir un bouton ok à droite du bouton annuler, on se retrouve avec une incompatibilité fondamentale, puisque l'action par défaut est rarement celle d'annuler la saisie que l'on vient de faire. Plusieurs solutions s'offrent dès lors à nous:

Ignorer les HIG, solution non acceptable dans mon cas (sous peine de lynchage généralisé)
Supprimer purement et simplement les boutons annuler, ce qui représente une perte de fonctionnalitées trop importante dans certains cas
Utiliser du JS, solution non acceptable vis à vis de mon challenge personnel (ne pas utiliser de JS avant que l'appli ne soit complètement fonctionnelle)
Tricher.

J'ai donc opté pour la 4ème solution, j'ai triché. J'ai placé mes input comme le souhaitait le navigateur (ok, puis cancel), et utilisé la directive CSS direction pour réorienter le tout, ce qui donne, pour le HTML:

<fieldset class="submit">
	<input type="submit" name="submit" id="ok" value="Ok" />
	<input type="submit" name="submit" id="cancel" value="Cancel" />
</fieldset>

Et pour la CSS:

fieldset.submit {
	direction: rtl;
}

Et le rendu final.

Problèmes connus:

~~Impossible d'utiliser de ponctuation dans les boutons (un point d'exclamation à la fin d'un bouton par exemple se retrouvera au début)~~ Un fieldset.submit input { direction: ltr; } est nécessaire pour bénéficier des ponctuations au bon endroit (merci Matt.Rixx)
Surement d'autres conséquences facheuses qui ne me sont pas encore tombées dessus :-)

Mais bon pour l'instant ça marche.